From ghc-devs at haskell.org Tue Nov 1 00:04:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 00:04:55 -0000 Subject: [GHC] #9010: TemplateHaskell leads to an "unknown symbol" error In-Reply-To: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> References: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> Message-ID: <063.b3acec955a7f81a3ad8b8c8c2d69099c@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): This is definitely not the same issue. Can you file a new issue please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 00:25:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 00:25:32 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.da54c5db650dc1a8bc04ff13402508be@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+-------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by George): * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 00:34:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 00:34:31 -0000 Subject: [GHC] #5466: Documentation for Chan could be better In-Reply-To: <046.e46c035a91971e631614cfca8496f79e@haskell.org> References: <046.e46c035a91971e631614cfca8496f79e@haskell.org> Message-ID: <061.0d720121d04c7f35b7b4b752ed7b6a76@haskell.org> #5466: Documentation for Chan could be better -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Core Libraries | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * cc: ekmett (added) * failure: None/Unknown => Documentation bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 00:41:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 00:41:32 -0000 Subject: [GHC] #7275: Give more detailed information about PINNED data in a heap profile In-Reply-To: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> References: <044.d45534e5aeae0f0c324c2676fe16cc7e@haskell.org> Message-ID: <059.9aebd63cd858e9b64219bcac87ce31fa@haskell.org> #7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * failure: None/Unknown => Other Comment: The current behaviour is not very informative. This would be nice to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 01:07:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 01:07:00 -0000 Subject: [GHC] #10221: LLVM backend does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.25765ace413e554d66bd78a077d03e9f@haskell.org> #10221: LLVM backend does not work on OSX ------------------------------------+-------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by George): * status: infoneeded => closed * resolution: => fixed * architecture: Unknown/Multiple => x86_64 (amd64) Comment: has worked for me for a couple of years now. Currenlty works on ghc 8.0.1 and XCode 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 01:28:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 01:28:10 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.6b9e2686bfbdf0e8a5714840be43de29@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I found that explanation slightly more complicated than necessary. Consider this example: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleContexts #-} module G where class Num a => C a b where m :: a -> b f :: C Int b => b -> Int -> Int f _ x = x + 1 }}} In `f`, there is a `Num Int` instance available from the passed-in `C Int b` instance. So, GHC generates this code for `f`: {{{ G.f = \ (@ b_aLy) ($dC_aLz :: G.C GHC.Types.Int b_aLy) _ [Occ=Dead] (eta1_B1 :: GHC.Types.Int) -> GHC.Num.+ @ GHC.Types.Int (G.$p1C @ GHC.Types.Int @ b_aLy $dC_aLz) eta1_B1 G.f1 }}} which is obviously terrible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 01:31:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 01:31:45 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.09ff158bb8c46edc8cd7db8030ca2736@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't know exactly what changed in GHC here, but the current monad- logger code is utterly wrong and the "workaround" is actually just replacing the code with what the author doubtless meant to write in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 05:44:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 05:44:50 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.e846f2d8d816adf8f99693005547d4ae@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Info after further investigation. The following both work fine. {{{ > :set -XTypeInType > class C a where f :: a b > :t f f ∷ ∀ {k} {b ∷ k} {a ∷ k → ★}. C k a ⇒ a b > class C a where f :: b a > :t f f ∷ ∀ {k} {a ∷ k} {b ∷ k → ★}. C k a ⇒ b a }}} However at 3 variables every combination fails (I've used +v here to prevent deep instantiation, which is where the failure occurs). {{{ > class C a where f :: a b c > :t +v f f ∷ ∀ {k1} {k2} (a ∷ k1 → k2 → ★). C k1 k2 a ⇒ ∀ (b ∷ k1) (c ∷ k2). a b c > class C a where f :: b a c > :t +v f f ∷ ∀ {k} (a ∷ k). C k a ⇒ ∀ {k1} (b ∷ k → k1 → ★) (c ∷ k1). b a c > class C a where f :: b c a > :t +v f f ∷ ∀ {k} (a ∷ k). C k a ⇒ ∀ {k1} (b ∷ k1 → k → ★) (c ∷ k1). b c a }}} All three of these panic without the +v. Note that with no TypeInType everything is fine {{{ > class C a where f :: a b c > :t f f ∷ ∀ {b} {a ∷ ★ → ★ → ★} {c}. C a ⇒ a b c }}} The problem seems to be that in the TypeInType case with 3 variables, the quantification of some variables is moving to the right of the class constraint. Variables are instantiated in independent groups, with separate groups before and after the constraint, and here the types after the constraint are referring to kinds defined before the constraint, causing the panic. I will investigate further -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 07:56:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 07:56:09 -0000 Subject: [GHC] #11834: GHC master, not compiling on Archlinux In-Reply-To: <045.4e01e4471eaa123aed65b47cf92d5739@haskell.org> References: <045.4e01e4471eaa123aed65b47cf92d5739@haskell.org> Message-ID: <060.dbdbfc662bdd472cbfea84b0dfd9e95e@haskell.org> #11834: GHC master, not compiling on Archlinux -------------------------------------+------------------------------------- Reporter: nitrix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #12759 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * related: => #12759 Comment: There's some more comments in #12759 . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 08:08:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 08:08:50 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.7f3b548890fbaab0c8ca92fcd2f21661@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Thanks Reid. That is a clear description of the problem I had in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 09:42:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 09:42:12 -0000 Subject: [GHC] #12793: Performs unaligned access on SPARC64 Message-ID: <045.277aa62543fcaf29d772ecd6df09e89f@haskell.org> #12793: Performs unaligned access on SPARC64 --------------------------------+---------------------------------------- Reporter: jrtc27 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: sparc | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+---------------------------------------- (Filed under Architecture: sparc, since there's no sparc64 in the dropdown...) Trying to build GHC on sparc64 currently crashes with a SIGBUS (unaligned access). This is because sparc64 uses the C backend (only 32-bit sparc has native code gen), but is unaware that it can't perform unaligned accesses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 09:47:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 09:47:53 -0000 Subject: [GHC] #9010: TemplateHaskell leads to an "unknown symbol" error In-Reply-To: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> References: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> Message-ID: <063.993261e303e5982126db32ab3f656db9@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Darwin226): No problem but why do you think this is a separate issue? It's again a C binding combined with TH causing unknown symbol errors -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 10:02:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 10:02:40 -0000 Subject: [GHC] #12793: Performs unaligned access on SPARC64 In-Reply-To: <045.277aa62543fcaf29d772ecd6df09e89f@haskell.org> References: <045.277aa62543fcaf29d772ecd6df09e89f@haskell.org> Message-ID: <060.de54311a1981b598c62dda6165e2950e@haskell.org> #12793: Performs unaligned access on SPARC64 ----------------------------------------+---------------------------------- Reporter: jrtc27 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: sparc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2661 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by erikd): * differential: => phab:D2661 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 10:22:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 10:22:02 -0000 Subject: [GHC] #12590: GHC panics, -XTypeInType, possibly "cobox" related In-Reply-To: <048.b37f6d40857c85af86f441819f65a204@haskell.org> References: <048.b37f6d40857c85af86f441819f65a204@haskell.org> Message-ID: <063.932c178de4b21d5187bc53e4cc06820e@haskell.org> #12590: GHC panics, -XTypeInType, possibly "cobox" related -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12785 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * status: new => closed * resolution: => duplicate * related: => #12785 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 10:24:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 10:24:16 -0000 Subject: [GHC] #12785: GHC panic, TypeFamily in equality constraint In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.844f0279c63c23be3871c90c689a9b7d@haskell.org> #12785: GHC panic, TypeFamily in equality constraint -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: yes Blocked By: | Blocking: Related Tickets: #12590 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * testcase: => yes * related: => #12590 Comment: Another test case is available in #12590 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 10:26:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 10:26:24 -0000 Subject: [GHC] #12785: GHC panic, `tcTyVarDetails` is missing a case (was: GHC panic, TypeFamily in equality constraint) In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.350cb8c69fcc6b2f2247bfb6977bd617@haskell.org> #12785: GHC panic, `tcTyVarDetails` is missing a case -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: yes Blocked By: | Blocking: Related Tickets: #12590 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * failure: None/Unknown => Compile-time crash or panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 10:27:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 10:27:00 -0000 Subject: [GHC] #12590: GHC panics, -XTypeInType, possibly "cobox" related In-Reply-To: <048.b37f6d40857c85af86f441819f65a204@haskell.org> References: <048.b37f6d40857c85af86f441819f65a204@haskell.org> Message-ID: <063.65f3bbea896df7e304383500932afc3e@haskell.org> #12590: GHC panics, -XTypeInType, possibly "cobox" related -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: yes Blocked By: | Blocking: Related Tickets: #12785 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * testcase: => yes * failure: None/Unknown => Compile-time crash or panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 12:24:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 12:24:35 -0000 Subject: [GHC] #11834: GHC master, not compiling on Archlinux In-Reply-To: <045.4e01e4471eaa123aed65b47cf92d5739@haskell.org> References: <045.4e01e4471eaa123aed65b47cf92d5739@haskell.org> Message-ID: <060.c1ab6e6d23926a6514ca4023e0a2f01f@haskell.org> #11834: GHC master, not compiling on Archlinux -------------------------------------+------------------------------------- Reporter: nitrix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #12759 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akfp): Also Ubuntu 16.10 breaks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 12:57:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 12:57:14 -0000 Subject: [GHC] #12787: Weird type constraint with undecidable instances In-Reply-To: <043.fe9ea22ee0cc8d7eb5d0c1342d0d790e@haskell.org> References: <043.fe9ea22ee0cc8d7eb5d0c1342d0d790e@haskell.org> Message-ID: <058.5269a9529bcb181ff5c70431c188dd2c@haskell.org> #12787: Weird type constraint with undecidable instances -------------------------------------+------------------------------------- Reporter: nome | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: invalid | UndecidableInstances Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No worries about the noise -- and sorry if my initial response was a bit curt. This is confusing territory to be sure! For me, the key that unlocked all of this was to realize that instance selection always ignores contexts. So GHC will choose an instance based only on the instance head (that is, the bit to the right of `=>`). Only then will it try to satisfy the context. More elaborate instance selection control is possible with type families, but I'm afraid I can't find a decent, introductory example of how to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 13:40:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 13:40:08 -0000 Subject: [GHC] #12794: Out of scope error not reported Message-ID: <046.500f74be41362996be42758d4a2128d8@haskell.org> #12794: Out of scope error not reported -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE TypeApplications #-} {-# OPTIONS -fdefer-type-errors #-} f = bar @Int }}} where `bar` is not in scope. We get {{{ T12768.hs:8:7: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Int’ • In the expression: bar @Int }}} Confusingly, the "`bar` is not in scope`" error (the true error) has been suppressed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 14:00:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 14:00:10 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.53f7c2cf6b19ea33ce1b579282faffef@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There is a real difficulty here, if I'm not mistaken. Consider {{{ class C a where op :: D a => a -> a instance C [a] where op = opList opList :: D [a] => [a] -> [a] opList = ... }}} Now suppose we try GND: {{{ newtype N a = MkN [a] deriving( C ) }}} The GND is expecting to get an implementation of `op` for `N` from that for `opList`, something like {{{ instance C [a] => C (N a) where op = opN opN :: D (N a) => N a -> N a opN = ...opList... -- Uses coerce }}} But the call to `opList` in the definition of `opN` needs `(D [a])` whereas what we are given is `D (N a)`. **And these are not inter-coercible**. For example we might have manually written instances {{{ instance D [a] where ... instance D (N a) where ... }}} and there is no relation between them. So in this case, the code for `opN` is **not** representationally the same as the code for `opList`, so GND (which is all about representational equivalence) doesn't really apply. In the actual example, `D` is just `C` again, but I don't think we should treat it any differently. The actual error is generated by an attempt to coerce {{{ coerce @(C m => m ()) @(C (N m) => N m ()) }}} which rightly fails. So I think GND just doesn't work here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 14:11:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 14:11:45 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.110159ae2f4d25bc5fbc1e51fba2c851@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 11698 | Blocking: Related Tickets: | Differential Rev(s): Phab:D2104, Wiki Page: | Phab:D2655 -------------------------------------+------------------------------------- Comment (by Facundo Domínguez ): In [changeset:"0b70ec0c3b72a7f87776743e64b47b65ef0ca4a5/ghc" 0b70ec0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0b70ec0c3b72a7f87776743e64b47b65ef0ca4a5" Have static pointers work with -fno-full-laziness. Summary: Before this patch, static pointers wouldn't be floated to the top-level. Test Plan: ./validate Reviewers: simonpj, bgamari, austin Subscribers: mboes, thomie Differential Revision: https://phabricator.haskell.org/D2662 GHC Trac Issues: #11656 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 14:28:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 14:28:21 -0000 Subject: [GHC] #12793: Performs unaligned access on SPARC64 In-Reply-To: <045.277aa62543fcaf29d772ecd6df09e89f@haskell.org> References: <045.277aa62543fcaf29d772ecd6df09e89f@haskell.org> Message-ID: <060.0652452c5c840c6837de52cc9a7ca110@haskell.org> #12793: Performs unaligned access on SPARC64 ----------------------------------------+---------------------------------- Reporter: jrtc27 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: sparc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2661 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by Phyx-): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 15:07:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 15:07:54 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.8e5d6bef5a135e824ed87900dc5cfec6@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by goldfire): Looks to me that you're hot on the case. Let me know if I can be of help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 15:18:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 15:18:00 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.274e590dcd7550e6f75d470d444bc945@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Replying to [comment:9 goldfire]: > Looks to me that you're hot on the case. Let me know if I can be of help. If you have any insight as to why some of the universally quantified variables are moved past the class constraint in 8.1 that would be very helpful. Was this on purpose to fix some bug (it's not clear to me if the semantics are different or not), or might it just have been an unintended side-effect of some other change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 15:18:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 15:18:43 -0000 Subject: [GHC] #12794: Out of scope error not reported In-Reply-To: <046.500f74be41362996be42758d4a2128d8@haskell.org> References: <046.500f74be41362996be42758d4a2128d8@haskell.org> Message-ID: <061.95fb791e98df3a6f9fe02c82109dfe05@haskell.org> #12794: Out of scope error not reported -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is a variant of #12092, perhaps made worse by `-fdefer-type-errors`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 15:35:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 15:35:39 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.9dcf1fda216b3deb892a0e3ee820db7b@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by goldfire): The types you report (with `+v`) look the way I would expect them to be in GHC 8.0, as well. Suppose we have {{{ class where :: }}} Then the type of `` is `forall . => `. Note that if a method type mentions fresh type variables (that is, those not introduced in the class head), then the method type will be quantified over those variables. So {{{ class C a where f :: a b c }}} is equivalent to {{{ class C a where f :: forall b c. a b c }}} There's clearly something wrong with instantiation here, but the types for the class methods should be the same in 8.0 as in 8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 15:48:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 15:48:33 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.e949655ae4e0024172093b907de9b19e@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Replying to [comment:11 goldfire]: > There's clearly something wrong with instantiation here, but the types for the class methods should be the same in 8.0 as in 8.1. Actually as noted above they are in fact different. In 8.0.1: {{{ > class C a where f :: b a c > :t f f ∷ ∀ {k} {k1} {a ∷ k} {b ∷ k → k1 → ★} {c ∷ k1}. C k a ⇒ b a c }}} In 8.1: {{{ > class C a where f :: b a c > :t +v f f ∷ ∀ {k} (a ∷ k). C k a ⇒ ∀ {k1} (b ∷ k → k1 → ★) (c ∷ k1). b a c }}} The bug is then that in 8.1 the `k` referred to by `b` tries to reference the kind defined before the class constraint, which is not in scope at that point, causing the panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 15:50:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 15:50:59 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.7b8f3437181a971e9fad0323b70f316c@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ryantrinkle): Just wanted to note that fixing this seems likely to help dramatically with monad transformer and reflex performance in my company's codebases. We see a ton of this in our dump-simpl outputs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 16:15:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 16:15:08 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.91ab80c407b3f05887ddb11dd2e33298@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is nothing to do with specialisation. It has to do with how the constraint solver solves constraints. But it's not easy to fix you problem. GHC's constraint solver uses the "given" constraint (here `Num Int` via a superclass of `C Int b`) where possible. You may say "If there is an instance declaration, use that instead of the given constraint. But no {{{ f :: Ord [a] => ... f x = ..Need Eq [a]... }}} There is a top-level instance for `Eq [a]`, but if we use it we'll need `Eq a` and we haven't got that. So we must satisfy the `Eq [a]` from the superclass of `Ord [a]`. I suppose we could make a special case when the instance declaration does not generate any new constraints, as is the case for `Num Int`. Would that deal with your "ton of cases"? Can you give more concrete examples? I worry that it might not be long before someone complains that GHC is bypassing the dictionary they have passed in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 16:39:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 16:39:59 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.505389899c0a2469e8e342919d5bed11@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ryantrinkle): Hmm, that makes a lot of sense. I think we probably would run into that sometimes, although I'm not entirely sure how often. We may be able to factor out these superclasses - in the cases I know of, they're for convenience, not out of necessity. There's a lot I don't understand here, but I do suspect that in our real- world cases, extremely aggressive inlining (like I'm hoping to get working, see https://mail.haskell.org/pipermail/ghc- devs/2016-October/013142.html) may result in enough inlining that this issue doesn't matter. Ideally, I'd like both the subclass and the superclass to be inlined. I'm just worried that sometimes the subclass won't be inlinable, and if that also prevents the superclass from being inlined, that'll make the optimization very brittle. With regard to having the wrong dictionary being passed in, I suppose changing this behavior would lean very heavily on the canonicity of instances - and perhaps would interfere with uses of incoherent instances and such? I'm fairly certain it wouldn't be a problem in any of our code, but I wouldn't want to cause problems for others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 16:47:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 16:47:24 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.2b640504cb2a592f541a2f4e2e0c853b@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by goldfire): But you don't have `+v` in 8.0. The type that you're seeing has been instantiated and then regeneralized, so all the variable ordering has been forgotten. I still claim that the internal types assigned to `f` are the same. You just can't ask GHCi for this type in 8.0. You could, though do a `pprTrace` or `traceTc` from `TcExpr.tcInferId` which can print out the uninstantiated type. In your last sentence: that `k` really ought to be in scope throughout the type. If it's not, there's your bug! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 16:56:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 16:56:03 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.790bc6e5282b8d5be3dfc2f5e8b6ac4e@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): To look at this from another perspective, if you write a function using methods from `Num` at a known type then GHC will specialise this code to the specific (+) defined for `Int`. If there is no instance then the definition will fail to type check. {{{#!hs foo :: Int -> Int -> Int foo = (+) }}} another valid choice would be to infer a constraint as there could be an instance for `Num` defined in another module which could then use this function. {{{#!hs foo1 :: Num Int => Int -> Int -> Int foo1 = (+) }}} This seems analogous to the worry that "it might not be long before someone complains that GHC is bypassing the dictionary they have passed in.". We already assume coherence so using it again here seems more consistent and will produce much better code! Secondly, these super classes exist mainly for convenience so that users do not have to type out many constraints. It currently seems that in order to write code which will definitely specialise then you have to write out each constraint individually and avoid using super classes. Constraint kinds are also not an option as you end up with exactly the same problem. It seems a shame that there are no free methods for abstracting a bunch of different constraints and still getting guarantees about performance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 17:17:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 17:17:09 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.76b4b2c6f6e15a2a3de267c39d2b6428@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Replying to [comment:13 goldfire]: > But you don't have `+v` in 8.0. The type that you're seeing has been instantiated and then regeneralized, so all the variable ordering has been forgotten. I still claim that the internal types assigned to `f` are the same. You just can't ask GHCi for this type in 8.0. You could, though do a `pprTrace` or `traceTc` from `TcExpr.tcInferId` which can print out the uninstantiated type. > > In your last sentence: that `k` really ought to be in scope throughout the type. If it's not, there's your bug! OK, I understand. Perhaps it is a bug in 8.0 as well then. The code seems to be instantiating variables in independent groups, in this case the group before the class constraint and then separately the group after the class constraint. If you know a reason for this let me know. Options for fixing it would include doing all the variables together whether they are before or after the constraint, or saving variables from early groups to be in scope for later groups (perhaps the two are essentially equivalent). I'll explore further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 17:21:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 17:21:10 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.8919be1edd043e0227f13ee9687dba4a@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by goldfire): Instantiating variables in groups should be OK... but you should also keep track properly of what's in scope and what should be substituted during the instantiation. In other words, once the `k` has been instantiated, then you should apply the instantiating substitution to the entire body of `k`, including in the kinds of other bound variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 17:39:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 17:39:17 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.b0a361d9264efe54f14ce67dde3153d5@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Like I say, I could imagine a special case for the situation where the constraint is `C t1 .. tn` and it can be solved by a top-level instance that has no context. It'd be ad-hoc but probably useful, and I agree that the "might use the wrong dictionary" thing is probably an edge case. Beyond that, as I show above, I don't think we can use top-level instances. What I don't know is whether this special case would solve the "ton of cases" that you have seen in your code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 17:43:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 17:43:51 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.c36666e68dad55c48bd2642d56430c5e@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It would certainly help in some places. How hard do you think this would be to implement? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 17:50:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 17:50:48 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.caa92587a6e3aa074184c97c05984227@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Not hard; but it'd be encouraging if there were some "from the field" use cases to motivate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 17:54:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 17:54:51 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.b52c676b0ce092d545c30412a702b68e@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Here is one example, https://github.com/reflex-frp/reflex- dom/blob/c51a5585860db17ce63601524340f09cb75f0129/src/Reflex/Dom/Builder/Class.hs#L68 `DomBuilder` has two type parameters `m` and `t`, `Reflex t` is used as a super class constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 1 19:32:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 01 Nov 2016 19:32:13 -0000 Subject: [GHC] #12793: Performs unaligned access on SPARC64 In-Reply-To: <045.277aa62543fcaf29d772ecd6df09e89f@haskell.org> References: <045.277aa62543fcaf29d772ecd6df09e89f@haskell.org> Message-ID: <060.2fd6ba2eae01039c397ab4efdb628459@haskell.org> #12793: Performs unaligned access on SPARC64 ----------------------------------------+---------------------------------- Reporter: jrtc27 | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: sparc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2661 Wiki Page: | ----------------------------------------+---------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"19ce8a53e8074a7e56fd462e43750386e67edcd4/ghc" 19ce8a53/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="19ce8a53e8074a7e56fd462e43750386e67edcd4" Sparc*: Prevent GHC from doing unaligned accesses This is specifically for the C backend on Sparc64 (which has no native backend) but is also required for Sparc when building un-registerised. Bug reported via Debian (patch included): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842780 Test Plan: validate Reviewers: hvr, Phyx, bgamari, austin, simonmar Reviewed By: Phyx Subscribers: jrtc27, thomie Differential Revision: https://phabricator.haskell.org/D2661 GHC Trac Issues: #12793 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 01:58:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 01:58:10 -0000 Subject: [GHC] #12795: Add more types to System.Posix.Types Message-ID: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> #12795: Add more types to System.Posix.Types -------------------------------------+------------------------------------- Reporter: DanielG | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A whole lot of types are still missing from `System.Posix.Types` as noted in a TODO comment in the code: {{{ --- ToDo: blksize_t, clockid_t, blkcnt_t, fsblkcnt_t, fsfilcnt_t, id_t, key_t --- suseconds_t, timer_t, useconds_t }}} Specifically the lack of wrappers for blkcnt_t is causing trouble because it's forcing HFuse to re-implement `unix`'s `FileStatus` type to include the missing `st_blocks` field. See [https://hackage.haskell.org/package/HFuse/docs/System- Fuse.html#t:FileStat FileStat docs on Hackage]. I have patches for `base` and `unix` ready to add wrappers for all the types the comment mentions, let's see if I can figure out how to use Phab ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 01:59:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 01:59:19 -0000 Subject: [GHC] #12795: Add more types to System.Posix.Types In-Reply-To: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> References: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> Message-ID: <061.b5b39029780f8839ff8acc2dfeb73e61@haskell.org> #12795: Add more types to System.Posix.Types -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by DanielG): * owner: => DanielG @@ -10,3 +10,3 @@ - Specifically the lack of wrappers for blkcnt_t is causing trouble because - it's forcing HFuse to re-implement `unix`'s `FileStatus` type to include - the missing `st_blocks` field. See + Specifically the lack of a wrapper for `blkcnt_t` is causing trouble + because it's forcing HFuse to re-implement `unix`'s `FileStatus` type to + include the missing `st_blocks` field. See New description: A whole lot of types are still missing from `System.Posix.Types` as noted in a TODO comment in the code: {{{ --- ToDo: blksize_t, clockid_t, blkcnt_t, fsblkcnt_t, fsfilcnt_t, id_t, key_t --- suseconds_t, timer_t, useconds_t }}} Specifically the lack of a wrapper for `blkcnt_t` is causing trouble because it's forcing HFuse to re-implement `unix`'s `FileStatus` type to include the missing `st_blocks` field. See [https://hackage.haskell.org/package/HFuse/docs/System- Fuse.html#t:FileStat FileStat docs on Hackage]. I have patches for `base` and `unix` ready to add wrappers for all the types the comment mentions, let's see if I can figure out how to use Phab ;) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 02:33:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 02:33:30 -0000 Subject: [GHC] #12795: Add more types to System.Posix.Types In-Reply-To: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> References: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> Message-ID: <061.619b83fadca81706be33968bf52eae13@haskell.org> #12795: Add more types to System.Posix.Types -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2664 Wiki Page: | -------------------------------------+------------------------------------- Changes (by DanielG): * differential: => Phab:D2664 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 02:45:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 02:45:05 -0000 Subject: [GHC] #12796: hschooks.c #include path is incorrect Message-ID: <046.be652681697ce65090aa6a04158d2f64@haskell.org> #12796: hschooks.c #include path is incorrect -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When replacing `rtsBool` with the C99 `bool` type I noticed (I think) that `ghc/hschooks.c` seems to be compiled with an incorrect include path. Namely, the `#include "Rts.h"` ends up including the `Rts.h` from the bootstrap compiler, not the stage1 compiler that we are compiling. I'm still not entirely certain that this is the case since it seems something like this should have blown up long ago, but it's late so I'm just leaving this here for now. Relevant command line: {{{ "/opt/exp/ghc/roots/8.0.1/bin/ghc" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Ighc/stage1/build/ghc/autogen -optc-I'/opt/exp/ghc/ghc- linker/compiler/.' -optc-I'/opt/exp/ghc/ghc-linker/compiler/parser' -optc-I'/opt/exp/ghc/ghc-linker/compiler/utils' -optc-I'/opt/exp/ghc/ghc- linker/compiler/stage1' -optc-I'/opt/exp/ghc/roots/8.0.1/lib/ghc-8.0.1/process-1.4.2.0/include' -optc-I'/opt/exp/ghc/roots/8.0.1/lib/ghc-8.0.1/directory-1.2.6.2/include' -optc-I'/opt/exp/ghc/roots/8.0.1/lib/ghc-8.0.1/unix-2.7.2.0/include' -optc-I'/opt/exp/ghc/roots/8.0.1/lib/ghc-8.0.1/time-1.6.0.1/include' -optc-I'/opt/exp/ghc/roots/8.0.1/lib/ghc-8.0.1/bytestring-0.10.8.1/include' -optc-I'/opt/exp/ghc/roots/8.0.1/lib/ghc-8.0.1/base-4.9.0.0/include' -optc-I'/opt/exp/ghc/roots/8.0.1/lib/ghc-8.0.1/integer- gmp-1.0.0.1/include' -optc-I'/opt/exp/ghc/roots/8.0.1/lib/ghc-8.0.1/include' -optc-Werror =unused-but-set-variable -optc-Wno-error=inline -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -ighc/. -ighc/stage1/build -Ighc/stage1/build -ighc/stage1/build/ghc/autogen -Ighc/stage1/build/ghc/autogen -optP-include -optPghc/stage1/build/ghc/autogen/cabal_macros.h -package-id array-0.5.1.1 -package-id base-4.9.0.0 -package-id bytestring-0.10.8.1 -package-id directory-1.2.6.2 -package-id filepath-1.4.1.0 -package-id ghc-8.1 -package-id ghc-boot-8.1 -package-id process-1.4.2.0 -package-id unix-2.7.2.0 -Wall -XHaskell2010 -O -DDEBUG -no-hs-main -no-user-package- db -rtsopts -c ghc/hschooks.c -o ghc/stage1/build/hschooks.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 02:47:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 02:47:17 -0000 Subject: [GHC] #12797: Default Rules stop working when providing some constraints Message-ID: <046.3e265c62039d77b084607215464a4e41@haskell.org> #12797: Default Rules stop working when providing some constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've just found a very strange behavior. Let's consider following program: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ExtendedDefaultRules #-} {-# LANGUAGE OverloadedStrings #-} module Main where import Prelude import Control.Monad.IO.Class type family FuncArg m where FuncArg ((->) t) = 'Just t FuncArg m = 'Nothing test1 :: (MonadIO m) => m () test1 = do liftIO $ print "tst" test2 :: (MonadIO m, FuncArg m ~ 'Nothing) => m () test2 = do liftIO $ print "tst" main :: IO () main = return () }}} The function `tst1` compiles fine, while `tst2` fails: {{{ exe/Main.hs:21:14: error: • Could not deduce (Show a0) arising from a use of ‘print’ from the context: (MonadIO m, FuncArg m ~ 'Nothing) bound by the type signature for: tst2 :: (MonadIO m, FuncArg m ~ 'Nothing) => m () at exe/Main.hs:19:1-49 The type variable ‘a0’ is ambiguous These potential instances exist: instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ instance Show a => Show (Maybe a) -- Defined in ‘GHC.Show’ ...plus 22 others ...plus 7 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the second argument of ‘($)’, namely ‘print "tst"’ In a stmt of a 'do' block: liftIO $ print "tst" In the expression: do { liftIO $ print "tst" } exe/Main.hs:21:20: error: • Could not deduce (Data.String.IsString a0) arising from the literal ‘"tst"’ from the context: (MonadIO m, FuncArg m ~ 'Nothing) bound by the type signature for: tst2 :: (MonadIO m, FuncArg m ~ 'Nothing) => m () at exe/Main.hs:19:1-49 The type variable ‘a0’ is ambiguous These potential instances exist: instance a ~ Char => Data.String.IsString [a] -- Defined in ‘Data.String’ ...plus one instance involving out-of-scope types (use -fprint-potential-instances to see them all) • In the first argument of ‘print’, namely ‘"tst"’ In the second argument of ‘($)’, namely ‘print "tst"’ In a stmt of a 'do' block: liftIO $ print "tst" }}} Giving explicit types to String literals fixes the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 02:49:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 02:49:02 -0000 Subject: [GHC] #12797: Default Rules stop working when providing some constraints In-Reply-To: <046.3e265c62039d77b084607215464a4e41@haskell.org> References: <046.3e265c62039d77b084607215464a4e41@haskell.org> Message-ID: <061.874641426eb33ee5b437d146bdfdb543@haskell.org> #12797: Default Rules stop working when providing some constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by danilo2: @@ -7,1 +7,0 @@ - {-# LANGUAGE OverloadedStrings #-} @@ -21,1 +20,1 @@ - liftIO $ print "tst" + liftIO $ print 6 @@ -25,1 +24,1 @@ - liftIO $ print "tst" + liftIO $ print 6 @@ -34,0 +33,1 @@ + @@ -46,1 +46,1 @@ - ...plus 7 instances involving out-of-scope types + ...plus six instances involving out-of-scope types @@ -48,3 +48,3 @@ - • In the second argument of ‘($)’, namely ‘print "tst"’ - In a stmt of a 'do' block: liftIO $ print "tst" - In the expression: do { liftIO $ print "tst" } + • In the second argument of ‘($)’, namely ‘print 6’ + In a stmt of a 'do' block: liftIO $ print 6 + In the expression: do { liftIO $ print 6 } @@ -53,2 +53,1 @@ - • Could not deduce (Data.String.IsString a0) - arising from the literal ‘"tst"’ + • Could not deduce (Num a0) arising from the literal ‘6’ @@ -61,3 +60,4 @@ - instance a ~ Char => Data.String.IsString [a] - -- Defined in ‘Data.String’ - ...plus one instance involving out-of-scope types + instance Num Integer -- Defined in ‘GHC.Num’ + instance Num Double -- Defined in ‘GHC.Float’ + instance Num Float -- Defined in ‘GHC.Float’ + ...plus two others @@ -65,3 +65,3 @@ - • In the first argument of ‘print’, namely ‘"tst"’ - In the second argument of ‘($)’, namely ‘print "tst"’ - In a stmt of a 'do' block: liftIO $ print "tst" + • In the first argument of ‘print’, namely ‘6’ + In the second argument of ‘($)’, namely ‘print 6’ + In a stmt of a 'do' block: liftIO $ print 6 @@ -71,1 +71,1 @@ - Giving explicit types to String literals fixes the problem. + Giving explicit types to literals fixes the problem. New description: I've just found a very strange behavior. Let's consider following program: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ExtendedDefaultRules #-} module Main where import Prelude import Control.Monad.IO.Class type family FuncArg m where FuncArg ((->) t) = 'Just t FuncArg m = 'Nothing test1 :: (MonadIO m) => m () test1 = do liftIO $ print 6 test2 :: (MonadIO m, FuncArg m ~ 'Nothing) => m () test2 = do liftIO $ print 6 main :: IO () main = return () }}} The function `tst1` compiles fine, while `tst2` fails: {{{ exe/Main.hs:21:14: error: • Could not deduce (Show a0) arising from a use of ‘print’ from the context: (MonadIO m, FuncArg m ~ 'Nothing) bound by the type signature for: tst2 :: (MonadIO m, FuncArg m ~ 'Nothing) => m () at exe/Main.hs:19:1-49 The type variable ‘a0’ is ambiguous These potential instances exist: instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ instance Show a => Show (Maybe a) -- Defined in ‘GHC.Show’ ...plus 22 others ...plus six instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the second argument of ‘($)’, namely ‘print 6’ In a stmt of a 'do' block: liftIO $ print 6 In the expression: do { liftIO $ print 6 } exe/Main.hs:21:20: error: • Could not deduce (Num a0) arising from the literal ‘6’ from the context: (MonadIO m, FuncArg m ~ 'Nothing) bound by the type signature for: tst2 :: (MonadIO m, FuncArg m ~ 'Nothing) => m () at exe/Main.hs:19:1-49 The type variable ‘a0’ is ambiguous These potential instances exist: instance Num Integer -- Defined in ‘GHC.Num’ instance Num Double -- Defined in ‘GHC.Float’ instance Num Float -- Defined in ‘GHC.Float’ ...plus two others (use -fprint-potential-instances to see them all) • In the first argument of ‘print’, namely ‘6’ In the second argument of ‘($)’, namely ‘print 6’ In a stmt of a 'do' block: liftIO $ print 6 }}} Giving explicit types to literals fixes the problem. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 04:22:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 04:22:21 -0000 Subject: [GHC] #12798: LLVM seeming to over optimize, producing inefficient assembly code... Message-ID: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> #12798: LLVM seeming to over optimize, producing inefficient assembly code... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since in many cases, the use of the LLVM backend is the only way to avoid the NCG's poor register allocation (ticket #8971), this is a concern that using "-fllvm" is producing overly complex code through a (seeming) failed attempt to optimize. The following code uses a very simple "odds-only" implementation of the Sieve of Eratosthenes with a very tight inner culling loop limited to using a 16 Kilobyte buffer (<= the size of most modern CPU L1 data cache size) to reproduce the problem; it uses a "twos" Look Up Table (LUT) for better speed than using a variable shift left operation for setting the composite bits in the buffer array as it (should) take the same number of registers and the array look-up instruction is easier for the CPU to fuse than a variable shift left: {{{#!hs -- GHC_EfficiencyBug.hs {-# LANGUAGE FlexibleContexts #-} {-# OPTIONS_GHC -O3 -fllvm -rtsopts -keep-s-files #-} -- or -O2 import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base numLOOPS = 10000 :: Int twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soe :: () -> [Word32] soe() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfLmt = (256 * 1024) `div` 2 - 1 -- to 2^18 + 2 is 128 KBits - 1 = 16 KBytes cmpstsb <- newArray (0, bfLmt) False :: ST s (STUArray s Int Bool) cmpstsw <- (castSTUArray :: STUArray s Int Bool -> ST s (STUArray s Int Word32)) cmpstsb let loop n = -- cull a number of times to test timing if n <= 0 then return cmpstsb else let cullp i = let p = i + i + 3 in let s = (p * p - 3) `div` 2 in if s > bfLmt then loop (n - 1) else do isCmpst <- unsafeRead cmpstsb i if isCmpst then cullp (i + 1) else -- is Prime let cull j = -- very tight inner loop where all the time is spent if j > bfLmt then cullp (i + 1) else do let sh = unsafeAt twos (j .&. 31) -- (1 `shiftL` (j .&. 31))) let w = j `shiftR` 5 ov <- unsafeRead cmpstsw w unsafeWrite cmpstsw w (ov .|. sh) cull (j + p) in cull s in cullp 0 loop numLOOPS main = print $ length $ soe() }}} The main culling is repeated "numLOOPS" times to get a reasonable execution time for accurate timing and to make the time required to use the List comprehension to determine the number of found primes (the answer) a negligible part of the execution time. Timing results can be produced by running "./GHC_EfficiencyBug +RTS -s". The desired assembly code result for the tight inner loop is as for the Rust/LLVM compiler, in this case for x86_64 64-bit code: {{{ .p2align 4, 0x90 .LBB10_27: movq %rcx, %rdx shrq $5, %rdx movl %ecx, %esi andl $31, %esi movl (%rbp,%rsi,4), %esi orl %esi, (%r14,%rdx,4) addq %rax, %rcx .LBB10_26: cmpq %r13, %rcx jb .LBB10_27 }}} The above code is extremely efficient on a CPU that is not cache bottle necked (such as the AMD Bulldozer series are) and takes just about three clock cycles per inner composite culling loop on Intel Sky Lake; it is just as efficient for x86 code since there are only seven registers used in this inner loop. Due to this attempt at "over-optimization", the GHC/LLVM backend produces the following x86_64 64-bit code: {{{ .align 16, 0x90 .LBB34_2: # %c8T2 # =>This Inner Loop Header: Depth=1 movq %rcx, %rsi sarq $5, %rsi movl %r8d, %edi andl $124, %edi movl 16(%rax,%rdi), %edi orl %edi, 16(%r11,%rsi,4) addq %r14, %rcx addq %rdx, %r8 cmpq %r10, %rcx jle .LBB34_2 }}} As can be seen, instead of just masking the "twos" index register by 31 (0x1F), the code is using two extra separate registers to contain "(j * 4)" increment and the accumulated index, which increment is added to the "twos" index register per loop and masked by 124 (0x7C or 0x1F times 4), requiring an extra two registers and an extra instruction for the extra addition. This isn't a problem as to the number of registers for x86_64 code which has more than enough, but it adds the extra instruction execution time of one third of a CPU clock cycle (I know, only one ninth extra time). However, for 32-bit x86 code with barely enough registers previously, the use of the extra registers triggers a chain of three register reloads as can be seen in the following assembly code: {{{ .align 16, 0x90 LBB33_2: # %c8Wb # =>This Inner Loop Header: Depth=1 movl %ebx, %ebp sarl $5, %ebp movl %edi, %ecx andl $124, %ecx movl %esi, %edx movl %eax, %esi movl 36(%esp), %eax # 4-byte Reload movl 8(%eax,%ecx), %ecx movl %esi, %eax movl %edx, %esi orl %ecx, 8(%esi,%ebp,4) addl 32(%esp), %ebx # 4-byte Folded Reload addl 28(%esp), %edi # 4-byte Folded Reload cmpl %eax, %ebx jle LBB33_2 }}} '''The above code runs about 25% slower than it should on Intel Sky Lake for this 32-bit code.''' This was tested for GHC version 8.0.1 under both Windows and Linux for both 32-bit and 64-bit code with identical results for each native code width. The code was also tested for 32 and 64 bit code produced by the NCG; for this specific problem, NCG takes the simple approach and does not waste the extra register. However, due to the inefficient allocation of registers as per ticket #8971, not moving the loop completion check to the end of the loop and thus requiring an extra jump instruction, and not combining the read/modify/write into a single instruction, it is still slower (much slower for 32-bit code) than the LLVM produced code. As its problems are known, I have not documented the NCG code. Conclusion: This may seem like a nit picky type of bug as in some use cases the execution time cost is very small, but it may be an indication of problems in other use cases that cause more serious effects on execution speed. It is my feeling that for such low level somewhat imperative types of code, GHC should really produce code that is as fast as C/C++/Rust. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 04:28:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 04:28:49 -0000 Subject: [GHC] #8971: Native Code Generator for 8.0.1 is not as optimized as 7.6.3... (was: Native Code Generator for 7.8 is not as optimized as 7.6.3...) In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.05d55bc14f0446651f37075cfce7f570@haskell.org> #8971: Native Code Generator for 8.0.1 is not as optimized as 7.6.3... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by GordonBGood): * milestone: => 8.2.1 * version: 7.8.1-rc2 => 8.0.1 @@ -2,1 +2,1 @@ - version 7.8.1 RC2 compiler as the Windows 7.6.3 compiler (32-bit) when the + version 8.0.1 compiler as the Windows 7.6.3 compiler (32-bit) when the New description: The output assembly code is not as optimized for the Windows 32-bit version 8.0.1 compiler as the Windows 7.6.3 compiler (32-bit) when the option switches are exactly the same although it may not be limited to only the Windows platform; this has a negative impact on execution time for tight loops of about a factor of two times slower. The following code will reproduce the problem: {{{#!haskell -- GHC_NCG_OptimizationBug.hs -- it seems the Haskell GHC 7.8.1 NCG Native Code Generator (NCG) doesn't -- optimize as well for (at least) the x86 target as version 7.6.3 {-# OPTIONS_GHC -O3 -rtsopts -v -dcore-lint -ddump-asm -ddump-to-file -dumpdir . #-} -- or O2 import Data.Bits import Control.Monad.ST (runST,ST(..)) import Data.Array.Base -- Uses a very simple Sieve of Eratosthenes to 2 ^ 18 to prove it. accNumPrimes :: Int -> Int accNumPrimes acc = acc `seq` runST $ do let bfSz = (256 * 1024 - 3) `div` 2 bfLmtWrds = (bfSz + 1) `div` 32 bufw <- newArray (0, bfLmtWrds) (-1) :: ST s (STUArray s Int Int) -- to clear the last "uneven" bit(s) unsafeWrite bufw bfLmtWrds (complement ((-2) `shiftL` (bfSz .&. 31))) bufb <- (castSTUArray :: STUArray s Int Int -> ST s (STUArray s Int Bool)) bufw let cullp i = let p = i + i + 3 in let s = (p * p - 3) `div` 2 in if s > bfSz then let count i sm = do sm `seq` if i > bfLmtWrds then return (acc + sm) else do wd <- unsafeRead bufw i count (i + 1) (sm + (popCount wd)) in count 0 1 -- use '1' for the '2' prime not in the array else do v <- unsafeRead bufb i if v then let cull j = do -- very tight inner loop if j > bfSz then cullp (i + 1) else do unsafeWrite bufb j False cull (j + p) in cull s else cullp (i + 1) cullp 0 main = -- run the program a number of times to get a reasonable time... let numloops = 2000 in let loop n acc = acc `seq` if n <= 0 then acc else loop (n - 1) (accNumPrimes acc) in print $ loop numloops 0 }}} The above code takes almost twice as long to run when compiled under 7.8.1 RC2 for Windows (32-bit) as it does for the version 7.6.3 compiler (both 32-bit compilers). The -ddump-simpl Core dump is almost identical between the two, which is also evidenced by that using the -fllvm LLVM compiler back end switch for each results in code that runs at about the same speed for each compiler run (which would use the same Core output as used for NCG, right?). Under Windows, the compilation and run for 7.8.1 RC2 goes like this: {{{ *Main> :! E:\ghc-7.8.0.20140228_32\bin\ghc --make -pgmlo "E:\llvm32\build\Release\bin\opt" -pgmlc "E:\llvm32\build\Release\bin\llc" "GHC_NCG_OptimizationBug.hs" compile: input file WindowsVsLinuxNCG.hs Created temporary directory: C:\Users\Gordon\AppData\Local\Temp\ghc15460_0 *** Checking old interface for main:Main: *** Parser: *** Renamer/typechecker: [1 of 1] Compiling Main ( GHC_NCG_OptimizationBug.hs, GHC_NCG_OptimizationBug.o ) *** Desugar: Result size of Desugar (after optimization) = {terms: 260, types: 212, coercions: 0} *** Core Linted result of Desugar (after optimization): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 213, types: 136, coercions: 52} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 215, types: 148, coercions: 67} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 209, types: 135, coercions: 51} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 209, types: 135, coercions: 42} *** Core Linted result of Simplifier: *** Specialise: Result size of Specialise = {terms: 209, types: 135, coercions: 42} *** Core Linted result of Specialise: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 286, types: 185, coercions: 42} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): *** Float inwards: Result size of Float inwards = {terms: 286, types: 185, coercions: 42} *** Core Linted result of Float inwards: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 502, types: 393, coercions: 103} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 428, types: 326, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 420, types: 321, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 420, types: 321, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 418, types: 318, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 418, types: 318, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 475, types: 383, coercions: 32} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 444, types: 336, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 444, types: 336, coercions: 9} *** Core Linted result of Simplifier: *** Demand analysis: Result size of Demand analysis = {terms: 444, types: 336, coercions: 9} *** Core Linted result of Demand analysis: *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 579, types: 457, coercions: 9} *** Core Linted result of Worker Wrapper binds: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 510, types: 415, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 420, types: 322, coercions: 9} *** Core Linted result of Simplifier: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}) = {terms: 426, types: 326, coercions: 9} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): *** Common sub-expression: Result size of Common sub-expression = {terms: 424, types: 326, coercions: 9} *** Core Linted result of Common sub-expression: *** Float inwards: Result size of Float inwards = {terms: 424, types: 326, coercions: 9} *** Core Linted result of Float inwards: *** Liberate case: Result size of Liberate case = {terms: 1,824, types: 1,259, coercions: 9} *** Core Linted result of Liberate case: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 608, types: 422, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 604, types: 413, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 604, types: 413, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 604, types: 413, coercions: 9} *** Core Linted result of Simplifier: *** SpecConstr: Result size of SpecConstr = {terms: 708, types: 505, coercions: 9} *** Core Linted result of SpecConstr: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 702, types: 499, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 608, types: 405, coercions: 9} *** Core Linted result of Simplifier: *** Tidy Core: Result size of Tidy Core = {terms: 608, types: 405, coercions: 9} *** Core Linted result of Tidy Core: *** CorePrep: Result size of CorePrep = {terms: 825, types: 489, coercions: 9} *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** Assembler: "E:\ghc-7.8.0.20140228_32\lib/../mingw/bin/gcc.exe" "-U__i686" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-I." "-x" "assembler-with-cpp" "-c" "C:\Users\Gordon\AppData\Local\Temp\ghc15460_0\ghc15460_2.s" "-o" "GHC_NCG_OptimizationBug.o" Linking GHC_NCG_OptimizationBug.exe ... *Main> :! GHC_NCG_OptimizationBug +RTS -s 46000000 32,965,096 bytes allocated in the heap 7,032 bytes copied during GC 41,756 bytes maximum residency (2 sample(s)) 19,684 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 61 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 2 colls, 0 par 0.00s 0.00s 0.0001s 0.0001s INIT time 0.00s ( 0.00s elapsed) MUT time 1.73s ( 1.73s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 1.73s ( 1.73s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 19,006,902 bytes per MUT second Productivity 100.0% of total user, 100.2% of total elapsed }}} whereas under version 7.6.3 goes like this: {{{ *Main> :! E:\ghc-7.6.3_32\bin\ghc --make -pgmlo "E:\llvm32\build\Release\bin\opt" -pgmlc "E:\llvm32\build\Release\bin\llc" "GHC_NCG_OptimizationBug.hs" compile: input file GHC_NCG_OptimizationBug.hs Created temporary directory: C:\Users\Gordon\AppData\Local\Temp\ghc28200_0 *** Checking old interface for main:Main: *** Parser: *** Renamer/typechecker: [1 of 1] Compiling Main ( GHC_NCG_OptimizationBug.hs, GHC_NCG_OptimizationBug.o ) *** Desugar: Result size of Desugar (after optimization) = {terms: 247, types: 212, coercions: 0} *** Core Linted result of Desugar (after optimization): *** Simplifier: Result size of Simplifier iteration=1 = {terms: 198, types: 132, coercions: 35} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 200, types: 144, coercions: 43} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 194, types: 131, coercions: 57} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 194, types: 131, coercions: 39} *** Core Linted result of Simplifier: *** Specialise: Result size of Specialise = {terms: 194, types: 131, coercions: 39} *** Core Linted result of Specialise: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}) = {terms: 277, types: 191, coercions: 39} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): *** Float inwards: Result size of Float inwards = {terms: 277, types: 191, coercions: 39} *** Core Linted result of Float inwards: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 514, types: 403, coercions: 103} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 420, types: 317, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 412, types: 312, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 412, types: 312, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 410, types: 309, coercions: 29} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 410, types: 309, coercions: 29} *** Core Linted result of Simplifier: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 455, types: 364, coercions: 32} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 422, types: 317, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 422, types: 317, coercions: 9} *** Core Linted result of Simplifier: *** Demand analysis: Result size of Demand analysis = {terms: 422, types: 317, coercions: 9} *** Core Linted result of Demand analysis: *** Worker Wrapper binds: Result size of Worker Wrapper binds = {terms: 536, types: 427, coercions: 9} *** Core Linted result of Worker Wrapper binds: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 480, types: 391, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 400, types: 306, coercions: 9} *** Core Linted result of Simplifier: *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): Result size of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}) = {terms: 408, types: 311, coercions: 9} *** Core Linted result of Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): *** Common sub-expression: Result size of Common sub-expression = {terms: 406, types: 311, coercions: 9} *** Core Linted result of Common sub-expression: *** Float inwards: Result size of Float inwards = {terms: 406, types: 311, coercions: 9} *** Core Linted result of Float inwards: *** Liberate case: Result size of Liberate case = {terms: 1,186, types: 824, coercions: 9} *** Core Linted result of Liberate case: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 585, types: 411, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 569, types: 392, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=3 = {terms: 569, types: 392, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 569, types: 392, coercions: 9} *** Core Linted result of Simplifier: *** SpecConstr: Result size of SpecConstr = {terms: 746, types: 566, coercions: 9} *** Core Linted result of SpecConstr: *** Simplifier: Result size of Simplifier iteration=1 = {terms: 739, types: 560, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier iteration=2 = {terms: 762, types: 546, coercions: 9} *** Core Linted result of Simplifier: Result size of Simplifier = {terms: 642, types: 402, coercions: 9} *** Core Linted result of Simplifier: *** Tidy Core: Result size of Tidy Core = {terms: 642, types: 402, coercions: 9} *** Core Linted result of Tidy Core: writeBinIface: 10 Names writeBinIface: 34 dict entries *** CorePrep: Result size of CorePrep = {terms: 779, types: 483, coercions: 9} *** Core Linted result of CorePrep: *** Stg2Stg: *** CodeOutput: *** CodeGen: *** Assembler: "E:\ghc-7.6.3_32\lib/../mingw/bin/gcc.exe" "-fno-stack-protector" "-Wl ,--hash-size=31" "-Wl,--reduce-memory-overheads" "-I." "-c" "C:\Users\Gordon\AppData\Local\Temp\ghc28200_0\ghc28200_0.s" "-o" "GHC_NCG_OptimizationBug.o" Linking GHC_NCG_OptimizationBug.exe ... *Main> :! GHC_NCG_OptimizationBug +RTS -s 46000000 32,989,396 bytes allocated in the heap 4,976 bytes copied during GC 41,860 bytes maximum residency (2 sample(s)) 19,580 bytes maximum slop 2 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 61 colls, 0 par 0.00s 0.00s 0.0000s 0.0000s Gen 1 2 colls, 0 par 0.00s 0.00s 0.0001s 0.0001s INIT time 0.00s ( 0.00s elapsed) MUT time 0.64s ( 0.64s elapsed) GC time 0.00s ( 0.00s elapsed) EXIT time 0.00s ( 0.00s elapsed) Total time 0.66s ( 0.64s elapsed) %GC time 0.0% (0.1% elapsed) Alloc rate 51,495,642 bytes per MUT second Productivity 100.0% of total user, 102.3% of total elapsed }}} Looking at the ASM dump for the innermost tight culling loop reveals the problem, with 7.8.1 RC2 outputting as follow: {{{ _n3nx: movl 76(%esp),%ecx _c3gf: cmpl %ecx,%eax jg _c3jB _c3jC: movl %eax,%edx sarl $5,%edx movl %ecx,76(%esp) movl $1,%ecx movl %ecx,280(%esp) movl %eax,%ecx andl $31,%ecx movl %eax,292(%esp) movl 280(%esp),%eax shll %cl,%eax xorl $-1,%eax movl 64(%esp),%ecx addl $8,%ecx movl (%ecx,%edx,4),%ecx andl %eax,%ecx movl 64(%esp),%eax addl $8,%eax movl %ecx,(%eax,%edx,4) movl 292(%esp),%eax addl $3,%eax jmp _n3nx }}} and 7.6.3 outputting as follows: {{{ .text .align 4,0x90 .long 1894 .long 32 s1GZ_info: _c1YB: cmpl 16(%ebp),%esi jg _c1YE movl %esi,%edx sarl $5,%edx movl $1,%eax movl %esi,%ecx andl $31,%ecx shll %cl,%eax xorl $-1,%eax movl 12(%ebp),%ecx movl 8(%ecx,%edx,4),%ecx andl %eax,%ecx movl 12(%ebp),%eax movl %ecx,8(%eax,%edx,4) addl 4(%ebp),%esi jmp s1GZ_info _c1YE: movl 8(%ebp),%esi addl $8,%ebp jmp s1GB_info }}} The second code is clearly much more efficient, with the only memory access reading/writing the sieve buffer array and one register reload of the prime value to add to the current position index, whereas the first (7.8.1 RC2) code has three register spills and five register re-loads, almost as if debugging were still turned on. This bug was tested under Windows, but likely applies to other platforms, at least for 32-bit versions but also possibly to others. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 04:33:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 04:33:17 -0000 Subject: [GHC] #12797: Default Rules stop working when providing some constraints In-Reply-To: <046.3e265c62039d77b084607215464a4e41@haskell.org> References: <046.3e265c62039d77b084607215464a4e41@haskell.org> Message-ID: <061.4f6179c291f207d5c369d484f5da1bec@haskell.org> #12797: Default Rules stop working when providing some constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): Some notes from #ghc IRC: The error can be reproduced in GHC 7.10.3 (after adding `-XDataKinds`). It never even gets to the rewrites, apparently (compiling with -O0 so no RULES). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 09:14:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 09:14:06 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.d01d0b78a851cf70b5feb122b64a7515@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by erikd): With the above two patches, over 100 of the tests in the testsuie fail (mostly the TH related tests). Dropping those patches and configuring GHC as suggested by @hvr: {{{ ./configure \ CONF_CC_OPTS_STAGE2=-fno-PIE \ CONF_GCC_LINKER_OPTS_STAGE2=-no-pie \ CONF_LD_LINKER_OPTS_STAGE2=-no-pie }}} results in a GHC that passes all tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 09:21:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 09:21:28 -0000 Subject: [GHC] #12797: Default Rules stop working when providing some constraints In-Reply-To: <046.3e265c62039d77b084607215464a4e41@haskell.org> References: <046.3e265c62039d77b084607215464a4e41@haskell.org> Message-ID: <061.42ee4b02c26683ef5afd4d220d39a9f1@haskell.org> #12797: Default Rules stop working when providing some constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I took a quick look. It's because `TcSimplify.findDefaultableGroups` uses `TcSimplify.approximateWC`; and the latter is also used when inferring the most general type of a function that lacks a type signature. And `approximateWC` has the following note: {{{ Note [ApproximateWC] ~~~~~~~~~~~~~~~~~~~~ 1. We do *not* float anything out if the implication binds equality constraints, because that defeats the OutsideIn story. Consider data T a where TInt :: T Int MkT :: T a f TInt = 3::Int We get the implication (a ~ Int => res ~ Int), where so far we've decided f :: T a -> res We don't want to float (res~Int) out because then we'll infer f :: T a -> Int which is only on of the possible types. (GHC 7.6 accidentally *did* float out of such implications, which meant it would happily infer non-principal types.) }}} But in the case of ''defaulting'' we ''do'' want to infer a less-than- most-general type; and that's just what is happening here. The fix is easy: give a boolean flag to `approximateWC`. I'll do that soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 09:28:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 09:28:24 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.0e8fde50bafbe1eebdb5b8e8579d3bd8@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, so to complete the connection with comment:2, are there a ton of functions with user-written signatures like this? {{{ f :: (DomBuilder Int m) => blah }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 09:36:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 09:36:08 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.5ee39a7d56aaf12e4dcd9884df5a3cec@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Yes and here is another example from transformers. {{{#!hs class (Monoid w, Monad m) => MonadWriter w m | m -> w where }}} It is suggested to write functions of the form, {{{#!hs f :: (MonadWriter MyMonoid m) => m .... }}} which will have the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 10:41:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 10:41:25 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.25fca16944984c1b9ce23d206a7f3170@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => mpickering -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 12:33:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 12:33:57 -0000 Subject: [GHC] #12785: GHC panic, `tcTyVarDetails` is missing a case In-Reply-To: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> References: <048.2d34c9fb02ade423573bbc6df18bc11c@haskell.org> Message-ID: <063.ba967a4cb5e8fc18ae073f95f6a46d1c@haskell.org> #12785: GHC panic, `tcTyVarDetails` is missing a case -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: yes Blocked By: | Blocking: Related Tickets: #12590 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f4a14d6c535bdf52b19f441fe185ea13d62fdc24/ghc" f4a14d6c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f4a14d6c535bdf52b19f441fe185ea13d62fdc24" Use substTyUnchecked in TcMType.new_meta_tv_x Sadly, one of the indirect callers of this function doesn't yet enforce the in-scope set. It's in the TcHsType.tc_infer_args swamp, so I'm not going to wade in there today. The assertion tripped when investigating Trac #12785; but this patch does NOT fix the actual bug reported there. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 12:33:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 12:33:58 -0000 Subject: [GHC] #12797: Default Rules stop working when providing some constraints In-Reply-To: <046.3e265c62039d77b084607215464a4e41@haskell.org> References: <046.3e265c62039d77b084607215464a4e41@haskell.org> Message-ID: <061.514aeeb3920997e5d66685d1ef80d44d@haskell.org> #12797: Default Rules stop working when providing some constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"13508bad4810d4fa8581afbcb4f41c97fe4c92e2/ghc" 13508bad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13508bad4810d4fa8581afbcb4f41c97fe4c92e2" Fix Trac #12797: approximateWC This patch makes approximateWC a bit more gung-ho when called from the defaulting code. See Note [ApproximateWC], item (1). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 12:34:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 12:34:09 -0000 Subject: [GHC] #12795: Add more types to System.Posix.Types In-Reply-To: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> References: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> Message-ID: <061.28585c54615d1ecd3e97c106338ea74f@haskell.org> #12795: Add more types to System.Posix.Types -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2664 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bbaren): * cc: bbaren (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 12:52:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 12:52:21 -0000 Subject: [GHC] #12797: Default Rules stop working when providing some constraints In-Reply-To: <046.3e265c62039d77b084607215464a4e41@haskell.org> References: <046.3e265c62039d77b084607215464a4e41@haskell.org> Message-ID: <061.a9da7f9b57ac45cbb10e4947f6a444a2@haskell.org> #12797: Default Rules stop working when providing some constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12797 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T12797 Comment: Thanks for the example. Fixed! Merge if easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 13:38:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 13:38:02 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.fac20b7e29e1d50bdd0326fc5b1467f8@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ryantrinkle): simonpj: Yes. I've always encouraged the abstract style ( {{{ (MonadReader r m, MonadWriter w m) => m a }}} rather than {{{ ReaderT r (WriterT w m) a }}} ), so that the concrete monad transformer stack can be changed without modifying user code. It has worked really well to help keep code clean and organized (especially with GHC 8.0's warnings for unused constraints). So, in a typical reflex widget, there will be several constraints, e.g. DomBuilder t m, PerformEvent t m, PostBuild t m. Reflex is currently a superclass of all of these, since the 't' parameter is only meaningful for its Reflex instance. I haven't looked into whether it's possible to eliminate Reflex from all of these classes, but I'll certainly try to do that if it'll help with optimization. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 13:56:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 13:56:36 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.881ea6ca3a047b9865ec61511e48ecd8@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yesterday I start from a clean slate and started by again turning `cpe_ExprIsTrivial` calls into calls to `exprIsTrivial`. Recall that this essentially marks STG string and integer literals as non-trivial, ensuring that they are not duplicated in applications like .... After doing this I found that a `DEBUG` compiler build failed while building `GHC.Types` with an assertion failure in `CoreToStg`. Namely, the `consistentCafInfo` check failed as the `IdInfo` claimed `NoCafRefs` yet the binding itself was caffy. The binding in question is of the form, {{{#!hs $tcMode1 :: TrName [GblId, Caf=NoCafRefs, Str=m1] = \u [] case "Mode"# of sat_swgf { __DEFAULT -> TrNameS [sat_swgf]; }; }}} The reason `topStgBindHasCafRefs` considers this to be caffy is because the RHS is an updatable `StgRhsClosure`. It seems to me that the problem here is that we floated the string literal as an case analysis, meaning that we have turned what should be a `StgRhsCon` into a `StgRhsClosure`. I believe this is ultimately the same problem presented by #11312. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 14:06:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 14:06:18 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" In-Reply-To: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> References: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> Message-ID: <059.63b3c601f4b3e6cea14426664343c496@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a version which doesn't require installing `aeson`: {{{#!hs -- Bug2.hs module Bug2 where import Language.Haskell.TH data Options = Options { fieldLabelModifier :: String -> String , constructorTagModifier :: String -> String , allNullaryToStringTag :: Bool , omitNothingFields :: Bool , sumEncoding :: SumEncoding , unwrapUnaryRecords :: Bool } data SumEncoding = TaggedObject { tagFieldName :: String , contentsFieldName :: String } | ObjectWithSingleField | TwoElemArray deriveJSON :: Options -> Name -> Q [Dec] deriveJSON _ _ = return [] }}} {{{#!hs -- Bug.hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Bug2 import Language.Haskell.TH data Bad = Bad { _bad :: String } deriving (Eq, Ord, Show) $(deriveJSON defaultOptions{} ''Bad) }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 2] Compiling Bug2 ( Bug2.hs, Bug2.o ) [2 of 2] Compiling Bug ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161010 for x86_64-unknown-linux): compiler/typecheck/TcExpr.hs:820:15-35: Irrefutable pattern failed for pattern sel_id : _ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 14:22:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 14:22:45 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" In-Reply-To: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> References: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> Message-ID: <059.34f021c632c85d80223600cd06657411@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -3,1 +3,1 @@ - + {{{ @@ -15,0 +15,1 @@ + }}} New description: I got the following error compiling simple source file Bad.hs. The bug is likely related to TH as the crash vanishes without the TH line. {{{ $ stack ghc -- -c Bad.hs Run from outside a project, using implicit global project config Using resolver: lts-7.5 from implicit global project's config file: /home/jchia/.stack/global-project/stack.yaml ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): compiler/typecheck/TcExpr.hs:798:15-35: Irrefutable pattern failed for pattern sel_id : _ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Comment (by simonpj): Thank you Ryan! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 14:39:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 14:39:06 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.12c557326f5441991cfff39f086bd8b1@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: bgamari (added) Comment: That's a very good point about `D [a]` and `D (N a)` not being inter- coercible in general w.r.t the class `C`. It sound like in order to make this work for the special case of `D = C`, we'd have to equip GHC with some special knowledge that the `C (N a)` instance was generated through GND, which sounds quite gross. So now the question becomes: should we avoid backporting 96d451450923a80b043b5314c5eaaa9d0eab7c56 to 8.0.2 since it causes some programs which compile in 8.0.1 to fail in 8.0.2? Or should we simply add a section to the release notes explaining the scenario, and recommend the (admittedly simple) workaround? Ben, do you have any thoughts on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 14:42:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 14:42:33 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.c8e9938469f89e46ff17be5b8ea21fa8@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by clint): -fno-PIE causes things using hsc2hs to break horribly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 14:45:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 14:45:51 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.a6bdc655d0faed81d95917300a8bb858@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: bgamari (added) Comment: rwbarton, if I understand correctly, the issue here is that we're trying to equate `t m` with `m`? (It sort of looks like a variation of the occurs check, but I don't know if it's the same thing, given the nature of the error message.) It certainly seems like this program shouldn't have typechecked before, and that's fine. But the other issue is that we have a program which compiles on 8.0.1 but fails with 8.0.2, which seems a bit iffy. (See also https://ghc.haskell.org/trac/ghc/ticket/12768#comment:5 for another example.) Should we avoid backporting this fix to 8.0.2 to give users time to migrate their code that exhibits this bug before the next major release (8.2) lands? Or should we just pull the trigger and add a blurb to the 8.0.2 release notes explaining the situation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 14:58:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 14:58:00 -0000 Subject: [GHC] #11184: panic tcMonoExpr _ with bad indentation in TH code In-Reply-To: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> References: <051.283f70027949cd2be8a8ded24a70d3b3@haskell.org> Message-ID: <066.303fee903aab4d1e22f7c07ef1cf81a1@haskell.org> #11184: panic tcMonoExpr _ with bad indentation in TH code -------------------------------------+------------------------------------- Reporter: TeroLaitinen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 7.10.2 Resolution: duplicate | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #12584 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12584 * milestone: => 8.0.2 Comment: This was fixed by the solution for #12584. This fix has been applied to GHC 8.0.2 and HEAD. For reference, with GHC HEAD the reported error message for the original code is now: {{{ GHCi, version 8.1.20161023: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:8:26: error: Pattern syntax in expression context: \ x -> case x of { "type_" -> "type" (...) } -> x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 15:03:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 15:03:03 -0000 Subject: [GHC] #12594: DeriveAnyClass fails to derive some classes In-Reply-To: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> References: <044.95840279f26ea91b450f2ab8c7cf29b9@haskell.org> Message-ID: <059.9c774e6730f6e0a38afc8f2fee834153@haskell.org> #12594: DeriveAnyClass fails to derive some classes -------------------------------------+------------------------------------- Reporter: ivanm | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Generics Comment: Alternatively, if we fix https://ghc.haskell.org/trac/ghc/ticket/9821#comment:8, then the code above will Just Work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 15:48:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 15:48:50 -0000 Subject: [GHC] #10684: Error cascade when unrelated class derivation fails In-Reply-To: <045.c629d6ca48d10e5b203720966d06c869@haskell.org> References: <045.c629d6ca48d10e5b203720966d06c869@haskell.org> Message-ID: <060.cefcee98c402a39aae541f2f740baf33@haskell.org> #10684: Error cascade when unrelated class derivation fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: Since all datatypes now have `Typeable` derived implicitly, here's a modern version of this bug: {{{#!hs module A where import GHC.Generics data A = A deriving (Show, Generic) data B = B A deriving (Show) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 16:50:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 16:50:55 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.1b55aceffd91406002a52dafd7c5e497@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"623b8e44b1647083ff5d85ef40b7cf88870acef5/ghc" 623b8e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="623b8e44b1647083ff5d85ef40b7cf88870acef5" Renaming and comments in CorePrep In particular I renamed 'triv' to 'arg' CpeTriv to CpeArg in Note [CorePrep invariants], with knock on consequences. This is groundwork for the fix to Trac #11158 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 17:03:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 17:03:13 -0000 Subject: [GHC] #12797: Default Rules stop working when providing some constraints In-Reply-To: <046.3e265c62039d77b084607215464a4e41@haskell.org> References: <046.3e265c62039d77b084607215464a4e41@haskell.org> Message-ID: <061.c637b4c357c243269d7a81f52d9d9f00@haskell.org> #12797: Default Rules stop working when providing some constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12797 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): @Simon that was fast! Thank you! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 17:12:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 17:12:42 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.7f8c0625fe3c1f3cb2eb9b18479d01b1@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I just mean to say that `monad-logger` should just fix its code, since the fix will surely be needed anyway. RyanGlScott, it's more wrong than that. Let's charitably assume that `t m` refers to the instance we are deriving, like `IdentityT m`. Then how can the body of the default declaration type check? {{{#!hs askLoggerIO = Trans.lift askLoggerIO }}} `askLoggerIO` is a method of `MonadLoggerIO` and we need it at type `m`. But we only have the constraints `MonadLogger (t m), MonadIO (t m)`, which are insufficient (and useless). The only way GHC could think this type checks is if BOTH `t m` and `m` refer to the instance being derived, which is terribly wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 17:20:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 17:20:22 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.d24ec5a8a86eaf2dfb77a7e8f0c0124d@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I still hope you're not planning to implement `COMPLETE_PATTERNS` :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 17:52:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 17:52:01 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.d517efd207bfdd16c0ec18d4e8972cbb@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Changes (by bgamari): * cc: bgamari (added) Comment: I am also seeing this now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 19:24:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 19:24:14 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.1a48bcbbfcaa55b2eccfb2a2bfe6abde@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by erikd): I grabbed the source for "magic", unpacked them and tried to build them. `hsc2hs` failed so I added `-v` to the command line and this is what I got: {{{ > /usr/lib/ghc-8.0/bin/hsc2hs -v '--cc=/usr/bin/gcc' '--ld=/usr/bin/gcc' '--cflag=-fno-PIE' '--cflag=-fno-stack-protector' '--lflag=-fno-PIE' '--lflag=-fno-stack-protector' '--cflag=-D__GLASGOW_HASKELL__=800' '--cflag=-Dlinux_BUILD_OS=1' '--cflag=-Dx86_64_BUILD_ARCH=1' '--cflag=-Dlinux_HOST_OS=1' '--cflag=-Dx86_64_HOST_ARCH=1' '--cflag=-Idist/build/autogen''--cflag=-include' '--cflag=dist/build/autogen/cabal_macros.h' '--lflag=-lmagic' '--cflag=-I/usr/lib/ghc-8.0/lib/base-4.9.0.0/include' '--cflag=-I/usr/lib/ghc-8.0/lib/integer-gmp-1.0.0.1/include' '--cflag=-I/usr/lib/ghc-8.0/lib/include' '--lflag=-L/usr/lib/ghc-8.0/lib/base-4.9.0.0' '--lflag=-Wl,-R,/usr/lib/ghc-8.0/lib/base-4.9.0.0' '--lflag=-L/usr/lib/ghc-8.0/lib/integer-gmp-1.0.0.1' '--lflag=-Wl,-R,/usr/lib/ghc-8.0/lib/integer-gmp-1.0.0.1' '--lflag=-lgmp' '--lflag=-L/usr/lib/ghc-8.0/lib/ghc-prim-0.5.0.0' '--lflag=-Wl,-R,/usr/lib/ghc-8.0/lib/ghc-prim-0.5.0.0' '--lflag=-L/usr/lib/ghc-8.0/lib/rts' '--lflag=-Wl,-R,/usr/lib/ghc-8.0/lib/rts' '--lflag=-lm' '--lflag=-lrt' '--lflag=-ldl' '--lflag=-lffi' -o dist/build/Magic/Data.hs Magic/Data.hsc Executing: /usr/bin/gcc -c dist/build/Magic/Data_hsc_make.c -o dist/build/Magic/Data_hsc_make.o -fno-stack-protector -fno-PIE -fno-stack-protector -D__GLASGOW_HASKELL__=800 -Dlinux_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/usr/lib/ghc-8.0/lib/base-4.9.0.0/include -I/usr/lib/ghc-8.0/lib/integer-gmp-1.0.0.1/include -I/usr/lib/ghc-8.0/lib/include -I/usr/lib/ghc-8.0/lib/include/ Executing: /usr/bin/gcc -c dist/build/Magic/Data_hsc_utils.c -o dist/build/Magic/Data_hsc_utils.o -fno-stack-protector -fno-PIE -fno-stack-protector -D__GLASGOW_HASKELL__=800 -Dlinux_BUILD_OS=1 -Dx86_64_BUILD_ARCH=1 -Dlinux_HOST_OS=1 -Dx86_64_HOST_ARCH=1 -Idist/build/autogen -include dist/build/autogen/cabal_macros.h -I/usr/lib/ghc-8.0/lib/base-4.9.0.0/include -I/usr/lib/ghc-8.0/lib/integer-gmp-1.0.0.1/include -I/usr/lib/ghc-8.0/lib/include -I/usr/lib/ghc-8.0/lib/include/ Executing: /usr/bin/gcc dist/build/Magic/Data_hsc_make.o dist/build/Magic/Data_hsc_utils.o -o dist/build/Magic/Data_hsc_make -fno-PIE -fno-stack-protector -lmagic -L/usr/lib/ghc-8.0/lib/base-4.9.0.0 -Wl,-R,/usr/lib/ghc-8.0/lib/base-4.9.0.0 -L/usr/lib/ghc-8.0/lib/integer-gmp-1.0.0.1 -Wl,-R,/usr/lib/ghc-8.0/lib/integer-gmp-1.0.0.1 -lgmp -L/usr/lib/ghc-8.0/lib/ghc-prim-0.5.0.0 -Wl,-R,/usr/lib/ghc-8.0/lib/ghc-prim-0.5.0.0 -L/usr/lib/ghc-8.0/lib/rts -Wl,-R,/usr/lib/ghc-8.0/lib/rts -lm -lrt -ldl -lffi /usr/bin/ld: dist/build/Magic/Data_hsc_make.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 19:35:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 19:35:49 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.2a55bc89a624d5299b34fc388840e83d@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by erikd): The interesting bits of `ghc --info`: {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags","-fno-PIE -fno-stack-protector") ,("C compiler link flags","-no-pie") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld") ,("ld flags","-no-pie") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","/usr/bin/llc-3.7") ,("LLVM opt command","/usr/bin/opt-3.7") ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 19:46:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 19:46:33 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.b039df8847771a20be65fee93281de94@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by erikd): According to @hvr, this is likely a cabal bug that has been fixed (https://git.haskell.org/packages/Cabal.git/commitdiff/c30b179a73d9fd3f6edcdda5e881523cd6edd46a) but not released yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 19:48:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 19:48:58 -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.61be1f631f21d59a879d7ac95b38eca2@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: new Priority: high | Milestone: 8.2.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 20:12:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 20:12:00 -0000 Subject: [GHC] #12799: Itimer.c doesn't compile on iOS non-threaded RTS Message-ID: <046.68b9ced4f506a0574776364d7cfde1a4@haskell.org> #12799: Itimer.c doesn't compile on iOS non-threaded RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS uses the pthread-based `Itimer` implementation due to the bizarrely crippled timer mechanisms provided imposed by that platform. This broke in 999c464da36e925bd4ffea34c94d3a7b3ab0135c which fixed the pthreads implementation to correctly pause when unneeded. In doing this, however, it introduced a dependency on the RTS's synchronization primitives provided by `OSThreads.c` (e.g. `Condition`, `Mutex`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 20:14:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 20:14:47 -0000 Subject: [GHC] #4162: GHC API messes up signal handlers In-Reply-To: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> References: <049.709211b46c452cdea9069f91ddfa6b1a@haskell.org> Message-ID: <064.a7d9b752dbbed4c78bed6f14ddd34b5f@haskell.org> #4162: GHC API messes up signal handlers -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2633 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8a5960ad874d31fcf631b4d427ccd9fae571745c/ghc" 8a5960ad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8a5960ad874d31fcf631b4d427ccd9fae571745c" Uninstall signal handlers GHC installs signal handlers in runGhc/runGhcT to handle ^C but it never uninstalls them. It can be an issue, especially when using GHC as a library. Test Plan: validate Reviewers: bgamari, erikd, austin, simonmar Reviewed By: bgamari, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2633 GHC Trac Issues: #4162 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 20:14:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 20:14:47 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.be220e368c3d85014c5c6fe5bf0cb1d5@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"cc4710af723ca4bbcf77172ff715af22f9ce8419/ghc" cc4710af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cc4710af723ca4bbcf77172ff715af22f9ce8419" testsuite: Simplify kernel32 glue logic On Windows the testsuite driver calls kernel32 to set the current terminal codepage. The previous implementation of this was significantly more complex than necessary, and was wrong in the case of MSYS2, which requires that we explicitly load the library using the name of its DLL, including its file extension. Test Plan: Validate on Windows Reviewers: austin, RyanGlScott, Phyx Reviewed By: RyanGlScott, Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2641 GHC Trac Issues: #12661 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 20:21:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 20:21:40 -0000 Subject: [GHC] #12800: hs_try_putmvar003 sometimes fails Message-ID: <046.e1837edaff3493c41289a90d2307655f@haskell.org> #12800: hs_try_putmvar003 sometimes fails -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `hs_try_putmvar003` test appears to (unfortunately quite infrequently) crash. {{{ [1 of 1] Compiling Main ( ../mk/ghc-config.hs, ../mk/ghc- config.o ) Linking ../mk/ghc-config ... Looks like you don't have timeout, building it first... Timeout is 300 Found 360 .T files... Beginning test run at Wed Nov 2 20:43:04 2016 EET Wrong exit code (expected 0 , actual 139 ) Stdout: Stderr: /bin/sh: line 1: 31186 Segmentation fault: 11 ./hs_try_putmvar003 1 16 32 100 }}} [[https://phabricator.haskell.org/harbormaster/build/14760/?l=0|Here]] is a representative example from Harbormaster -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 20:43:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 20:43:30 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.7b660a4716cb7728916a3cab2e136356@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: infoneeded Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2666 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: Phab:D1656 => Phab:D2666 Comment: Well found! That does look plausible. Would you like to abandon Phab:D1656?]] I've added your patch Phab:D2666. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 22:19:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 22:19:10 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.b46d96df4278708275d606e08e683adc@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2666 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 2 23:40:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 02 Nov 2016 23:40:41 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.d9efcc200fa00ce0df309819d1ffa54b@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2666 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Where's the commit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 02:43:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 02:43:06 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.265f48c8c03e4632cf58679374e2ec24@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2666 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"967dd5c9f59e532fe9d6484888a2bae7d02fba11/ghc" 967dd5c9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="967dd5c9f59e532fe9d6484888a2bae7d02fba11" Merge cpe_ExprIsTrivial and exprIsTrivial Strangely my previous attempts at resolving this all seemed to end in perplexing segmentation faults in the GHC testsuite (including some rather recent attempts). Somehow this attempt miraculously works. However, there was one wrinkle that I still need to work out fully: we need to consider Lits as non-trivial in cpeArg. Failure to do this means that we would transform something like, $trModule = TrModule "HelloWorld"# into $trModule = case "HelloWorld"# of x { __DEFAULT -> TrModule x } Which then fails the consistentStgInfo check in CoreToStg for reasons that I am still trying to work out. Mark T12757 as fixed Reviewers: simonmar, simonpj, austin Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2666 GHC Trac Issues: #11158 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 02:43:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 02:43:06 -0000 Subject: [GHC] #12757: Compiled program segfaults at -O1 In-Reply-To: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> References: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> Message-ID: <057.f8d5b9f6f8eb19859c07d1f014b2f007@haskell.org> #12757: Compiled program segfaults at -O1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11312, #12585 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b5460dd6e54f4ba54bfb11469221e8c8f957e964/ghc" b5460dd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b5460dd6e54f4ba54bfb11469221e8c8f957e964" Add testcase for #12757 Test Plan: Validate, expected to fail Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2665 GHC Trac Issues: #12757 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 04:16:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 04:16:37 -0000 Subject: [GHC] #12801: Misleading error message when deriving Functor Message-ID: <044.c2d84a01411727fdbff6e379c4652bd2@haskell.org> #12801: Misleading error message when deriving Functor -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this trivial demo program: {{{ data Container = Container [Wibble Int] deriving (Eq, Show) data Wibble a = Wibble a | Wobble deriving (Eq, Functor, Show) }}} results in the error message: {{{ a.hs:6:13: error: • No instance for (Eq (Wibble Int)) arising from the first field of ‘Container’ (type ‘[Wibble Int]’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Eq Container) a.hs:6:17: error: • No instance for (Show (Wibble Int)) arising from the first field of ‘Container’ (type ‘[Wibble Int]’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Show Container) a.hs:12:17: error: • Can't make a derived instance of ‘Functor Wibble’: You need DeriveFunctor to derive an instance for this class • In the data declaration for ‘Wibble’ }}} The "No instance for (Eq|Show)" are rather misleading, because the *actual* error is that the `{-# LANGUAGE DeriveFunctor #-}` pragma is missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 04:24:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 04:24:35 -0000 Subject: [GHC] #12709: GHC panic In-Reply-To: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> References: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> Message-ID: <066.4bbf5c58ec9ec5ab0077b3719774b744@haskell.org> #12709: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): I don't know if it's exactly the same as this ticket, but I get a similar panic from the following minimization. {{{#!hs {-# Language TypeFamilies, TypeInType #-} import Data.Kind (Type) data U = U type family A (k :: Type) :: Type where A U = Type type family B (ty :: k) :: A k bad :: B 'U -> U bad _ = U }}} That gives the following panic when loaded in GHCi. {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-mingw32): kindPrimRep.go U }}} It does not panic when ''compiling'' with GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 04:24:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 04:24:54 -0000 Subject: [GHC] #12709: GHC panic In-Reply-To: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> References: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> Message-ID: <066.5864574467516d4c407c6bfd89a7a0ce@haskell.org> #12709: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 09:56:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 09:56:12 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.49ac73fbc1bfa54dd8297082daf7e92e@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2666 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Which then fails the consistentStgInfo check in CoreToStg for reasons that I am still trying to work out. Here's why (I think): * As the commit message says, if we case-bind the literal string, something that was a static data structure (predicted as `NoCafRefs` by `CorePrep` becomes a thunk. This prediction is made by `rhsIsStatic`, called in `CorePrep`. * Since it is marked as `NoCafRefs` it won't appear in anyone's SRT * But when it is evaluated, the thunk will allocate its result in the heap, and update the static closure to point to it. * Later the garbage collector will collect that thunk; the only pointer to it is from a static closure that is in no SRT. * The space will be re-used * Later someone uses the thing again, but the pointer now points to garbage. Seg fault. It's FATAL for something marked as `NoCafRefs` to turn into a thunk. Arrangig to panic on that would be good. It should not be just a warning, and I think it'd be worth the tiny perf hit to test it even in non-DEBUG code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 11:34:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 11:34:06 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" In-Reply-To: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> References: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> Message-ID: <059.dc583005de034f56e95588062ede290a@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well that's odd. I get {{{ T12788.hs:11:14: error: Empty record update }}} which comes from `RnPat.rnHsRecUpdFields`. And is quite correct. If I change the program to {{{ $(deriveJSON defaultOptions{unwrapUnaryRecords = True} ''Bad) }}} then I get {{{ T12788.hs:11:14: error: Variable not in scope: defaultOptions :: Options }}} which is also correct; `defaultOptions` is not in scope. All this happens with the 8.0.2 release candidate and HEAD. I can't easily try 8.0 itself. Can you try with the 8.0 branch and HEAD? It really would be better if the "empty record update" didn't mask the other error, namely that `defaultOptions` isn't in scope. Reason is the latter is reported by the type checker so that we can give the type of the out-of-scope variable, whereas the former comes from the renamer. Regardless, I can't make it crash. Maybe it got fixed, somehow? Can you double-check the repro case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 12:09:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 12:09:19 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.25fb2a7b70cb5b58335bb6dd61053839@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well I guess that * if we are doing GND for `(C (N a))`, where `N` is a newtype * then `(C a)` is representationally equal to `(C (N a))` and that's just what we need here. But I don't see an easy way to incorporate that knowledge in the solver. And this is very much a weird case: the `(C m)` constraint is entirely redundant. I worked out how GHC 8.0 is working. We generate this: {{{ instance C m => C (N m) where foo = coerce (foo :: m ()) :: N (m ()) }}} From this instance decl we generate {{{ dfCN :: C m => C (N m) dfCN d = MkC ($cfooN d) $cfooN :: C m => C (N m) => N m () $cfooN d _ = foo d d |> (a coercion) }}} Notice that in `$cfooN` we don't need the second dictionary argument (corresponding to the `C m` constrain in `foo`'s signature in the class decl). It just so happens that the instance context can satisfy it. But exploiting this fluke involves instantiating the call to `foo`, which is what I am now not doing. In comment:4, the fluke would require that from `C a` (the context of the instance decl) we could prove `D a` (the requirement of the call in the method body), again ignoring the supplied `(D (N a))`. I think the 8.0 behaviour is actually INCORRECT (it misbehaves in examples like comment:4), so I think we should indeed adopt the change for the 8.0 branch. Do we have any actual user complaints? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 13:00:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 13:00:31 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" In-Reply-To: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> References: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> Message-ID: <059.a126ebce3dfb20f8a01f479e6cc2abfe@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah! It turns out the error I experienced was with versions of GHC 8.0.2 and HEAD built on October 10. I experienced the same errors as you reported when using: * A GHC 8.0.2 built on October 18 * A GHC HEAD built on October 23 So this GHC panic must have been fixed recently. I'll try to find the offending commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 13:08:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 13:08:29 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.45b7a89b18382bf59e288696c74b8924@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm disinclined to fix this, too, for the reasons you articulated. The only place I'm aware of at the moment that exploited this trick was in the [https://github.com/ekmett/trifecta trifecta] library, and, as jophish noted in comment:2, the HEAD version of trifecta has already been patched to avoid this bug. But there could be other occurrences lurking in the wild, too... we'd probably need a build of Stackage with 8.0.2 to be sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 13:31:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 13:31:00 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" In-Reply-To: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> References: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> Message-ID: <059.85c475d697bd0a07526cc6eb94d675bb@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, it turns out to be bce99086e9f54909f51ff5a74cb8c666083bb021 (a.k.a. #12584) yet again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 13:36:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 13:36:32 -0000 Subject: [GHC] #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 Message-ID: <044.9c8bab5a25e1b9b83e76116a3cc77c77@haskell.org> #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Where building ieee754 succeeded with GHC 7.10, it fails with 8.0 on platforms without registerised builds, for example arm64: {{{ [1 of 2] Compiling Numeric.IEEE ( Numeric/IEEE.hs, dist- ghc/build/Numeric/IEEE.o ) In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2448:6: error: error: conflicting types for 'nextup' EFF_(nextup); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextup' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2501:6: error: error: conflicting types for 'nextup' EFF_(nextup); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextup' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2554:6: error: error: conflicting types for 'nextupf' EFF_(nextupf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextupf' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2607:6: error: error: conflicting types for 'nextupf' EFF_(nextupf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextupf' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2660:6: error: error: conflicting types for 'nextdown' EFF_(nextdown); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdown' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2713:6: error: error: conflicting types for 'nextdown' EFF_(nextdown); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdown' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2766:6: error: error: conflicting types for 'nextdownf' EFF_(nextdownf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdownf' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2819:6: error: error: conflicting types for 'nextdownf' EFF_(nextdownf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdownf' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) }}} {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags"," -fuse-ld=gold -Wl,-z,noexecstack") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld.gold") ,("ld flags"," -z noexecstack") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSLinux") ,("target arch","ArchARM64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","YES") ,("LLVM llc command","llc-3.7") ,("LLVM opt command","opt-3.7") ,("Project version","8.0.1") ,("Project Git commit id","4986837f8168cacf95c24fecc84d7b36c47f3c11") ,("Booter version","7.10.3") ,("Stage","2") ,("Build platform","aarch64-unknown-linux") ,("Host platform","aarch64-unknown-linux") ,("Target platform","aarch64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn thr_debug_p") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib/ghc") ,("Global Package DB","/usr/lib/ghc/package.conf.d") ] }}} The same is true for mips64el, s390x, alpha, hppa, m68k, sh4, sparc64, and I imagine mips and mipsel as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 14:15:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 14:15:01 -0000 Subject: [GHC] #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 In-Reply-To: <044.9c8bab5a25e1b9b83e76116a3cc77c77@haskell.org> References: <044.9c8bab5a25e1b9b83e76116a3cc77c77@haskell.org> Message-ID: <059.bc279b58ad5ceed0a29e20406b97d7ac@haskell.org> #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 14:20:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 14:20:36 -0000 Subject: [GHC] #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 In-Reply-To: <044.9c8bab5a25e1b9b83e76116a3cc77c77@haskell.org> References: <044.9c8bab5a25e1b9b83e76116a3cc77c77@haskell.org> Message-ID: <059.2199f19f4d643a40c5d43a7502f2b444@haskell.org> #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): I think it was broken not by GHC but by a new libc that started exposing primitives named the same way. To stop GHC emitting incompatible proto we can add next* functions to whitelist: {{{ compiler/cmm/CLabel.hs-math_funs = mkUniqSet [ compiler/cmm/CLabel.hs- -- _ISOC99_SOURCE compiler/cmm/CLabel.hs- (fsLit "acos"), (fsLit "acosf"), (fsLit "acosh"), compiler/cmm/CLabel.hs- (fsLit "acoshf"), (fsLit "acoshl"), (fsLit "acosl"), }}} But I suspect it won't help you as ieee754 actually redefines at least 'nextup'. As a workaround ieee754 might like to rename C symbols to at least not clast with libc symbols. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 14:21:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 14:21:02 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" In-Reply-To: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> References: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> Message-ID: <059.f38ea39582dbf7c856a9f8cc8670386f@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK good, thank you. So we can close as fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 18:05:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 18:05:30 -0000 Subject: [GHC] #12584: Renamer is not applied properly to the expressions in declaration splices In-Reply-To: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> References: <050.ea2f33bc9b0d53bd044fab70eeee30f9@haskell.org> Message-ID: <065.c2bad299ad2697ff235e5889caca0fc6@haskell.org> #12584: Renamer is not applied properly to the expressions in declaration splices -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2539 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"ec22bacdd625b04d28228dd5522d59d0bc8b1152/ghc" ec22bac/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ec22bacdd625b04d28228dd5522d59d0bc8b1152" Add test for #12788 Commit bce99086e9f54909f51ff5a74cb8c666083bb021 (#12584) fixed #12788. Let's add a test to make sure it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 18:05:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 18:05:30 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" In-Reply-To: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> References: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> Message-ID: <059.f59f03546661d3f9bcc1fa4d86bdd3af@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"ec22bacdd625b04d28228dd5522d59d0bc8b1152/ghc" ec22bac/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ec22bacdd625b04d28228dd5522d59d0bc8b1152" Add test for #12788 Commit bce99086e9f54909f51ff5a74cb8c666083bb021 (#12584) fixed #12788. Let's add a test to make sure it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 18:06:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 18:06:47 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" In-Reply-To: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> References: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> Message-ID: <059.43139d0f69444a7390a969c4e4c152ad@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => merge * milestone: => 8.0.2 Comment: I added a regression test to be safe. Since this fix was backported to 8.0.2, it should be safe to merge that commit as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 18:51:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 18:51:03 -0000 Subject: [GHC] #12734: Missed use of solved dictionaries leads to context stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.7ef1a5b655d5855a7ab4b9b5a4d7a347@haskell.org> #12734: Missed use of solved dictionaries leads to context stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): simonpj: thank you for a fast fix, I'm building head at the moment and I'll try it here! By the way, based on your description it reminded me about other bug I filled some time ago. Do you think it could be connected? It is not a high priority bug, but if it's connected maybe it's worth to mention it: https://ghc.haskell.org/trac/ghc/ticket/10778 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 20:37:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 20:37:58 -0000 Subject: [GHC] #12787: Weird type constraint with undecidable instances In-Reply-To: <043.fe9ea22ee0cc8d7eb5d0c1342d0d790e@haskell.org> References: <043.fe9ea22ee0cc8d7eb5d0c1342d0d790e@haskell.org> Message-ID: <058.3abf9dd2e8aec7796d6ea9181ce6880d@haskell.org> #12787: Weird type constraint with undecidable instances -------------------------------------+------------------------------------- Reporter: nome | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: invalid | UndecidableInstances Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nome): Thank you for the explanations. For the record: After some more reading (and a lot more thinking) on this topic, I realize that a) type classes are much weirder than I thought, and that b) the language and syntax of contexts is pretty misleading. It looks as though they're something like type-level guards (i.e. a precondition), but they're really constraints on polymorphic types ''resulting'' from applying a type class to a type: {{{#!hs type family constraintPartOfPartialOrd a :: Constraint type instance constraintPartOfPartialOrd a = TotalOrd a type instance constraintPartOfPartialOrd [a] = Eq a }}} ... put like this, it's clear why the deduced constraint is always `TotalOrd a`. So the instance syntax is really the wrong way around, and should instead be something like {{{#!hs instance PartialOrd a = TotalOrd a => tryCompare x y = Just $ tcompare x y }}} or maybe {{{#!hs instance PartialOrd a where type constraint TotalOrd a tryCompare x y = Just $ tcompare x y }}} because constraints are "attached" to the value-level part of a type class instance in pretty much the same way as [https://wiki.haskell.org/GHC/Type_families#An_associated_type_synonym_example associated type synonyms]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 21:30:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 21:30:32 -0000 Subject: [GHC] #9010: TemplateHaskell leads to an "unknown symbol" error In-Reply-To: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> References: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> Message-ID: <063.b8f2b99b418f20e344040eb82b0da2ca@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm actually not totally sure what the original issue was. basvandijk's issue clearly had to do with a C++ symbol, not a C symbol. Anyways linkers are complicated and Windows is a special beast, and almost every linking issue is going to involve a C dependency and TH. There's no a priori reason to think this is the same issue as anything discussed earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 21:50:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 21:50:46 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.0d5cad6fc3870fe63e91ac58a8013395@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): It may be that `library-dirs` is defined to be the directories in which to search for the Haskell library, not its C dependencies. But then, there is also `ld-options` which could be used to hold `-L` and/or `-rpath` options specifying the location of `zlib`. I agree ''if'' the Haskell library does not have an RPATH pointing at the location of `libz.so`, then ghc is blameless here because (as far as I can tell) it cannot know how to find `libz.so`. Cabal or the end user should be doing something to allow ghc to find the library. If the Haskell library does have an RPATH for `libz.so` then perhaps ghc should not be trying to load the library itself, as you discussed in comment:6. I also agree it's pretty unclear whose responsibility it is supposed to be to do what here... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 21:50:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 21:50:58 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.f553d0b36d13636b5d84a2f59fdc2139@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by bgamari): So I spent quite a while today working through building a tree with the new compiler. It turns out there are a number of build system issues which get in the way of this which I've fixed in Phab:D2672, Phab:D2673, and Phab:D2674. With these patches you can simply configure with, {{{ $ ./configure \ CONF_GCC_LINKER_OPTS_STAGE0=-no-pie \ CONF_LD_LINKER_OPTS_STAGE0=-no-pie \ CONF_HC_OPTS_STAGE0=-optl=-no-pie }}} and build as usual. It's not entirely clear here why the Haskell compiler options shouldn't just include `CONF_LD_LINKER_OPTS_*` with the appropriate prefix but I didn't want to change that today so instead I just passed `CONF_HC_OPTS_STAGE0` explicitly. Note that it is only necessary to pass `-no-pie` to the stage0 link; the later stages should build with `-fPIC` as this is the new compiler's default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 21:54:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 21:54:15 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.86b646525c886ef9febdadd6a7d1f02d@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * owner: trommler => * resolution: wontfix => Comment: > But currently GHC's dynamic linker mimics the behavior of the (static) RTS linker and would load `libz.so` before it loads `libHSzlib<...>.so`. Do you know why this is? If we could just not do this, it might fix this issue, right? I'm going to reopen this but mark as infoneeded, though I don't mind much if it ends up being closed again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 21:54:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 21:54:23 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.bc34ae79fb8e4f42709437f382f8f810@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 21:55:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 21:55:00 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.6f4dfe9372ce15d230cc70ad1665f027@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Maybe related, what is the meaning of this ghc-pkg output: {{{ extra-libraries: z extra-ghci-libraries: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 21:55:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 21:55:19 -0000 Subject: [GHC] #12738: GHC drops -optl flags In-Reply-To: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> References: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> Message-ID: <061.954f5e31e5748383cc9a97aa755f1804@haskell.org> #12738: GHC drops -optl flags -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"a977c96537bb7077c6445f02db98636b150e6e14/ghc" a977c965/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a977c96537bb7077c6445f02db98636b150e6e14" Omit unnecessary linker flags Summary: This omits -L and -l flags from the linker command line that shouldn't be necessary because GHC will already add them via the -package-id flags we pass. This also reverts part of 90538d86af579595987826cd893828d6f379f35a that rearranges the linker command line and causes some knock-on problems (see D2618). Test Plan: validate (need to validate on Windows too) Reviewers: Phyx, bgamari, niteria, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2639 GHC Trac Issues: #12738 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 22:00:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 22:00:46 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.31e1660d8a797f1e80315d826d1f73e7@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by rwbarton): > It's not entirely clear here why the Haskell compiler options shouldn't just include `CONF_LD_LINKER_OPTS_*` with the appropriate prefix but I didn't want to change that today so instead I just passed `CONF_HC_OPTS_STAGE0` explicitly. You mean `CONF_GCC_LINKER_OPTS_STAGE0` :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 3 23:50:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 03 Nov 2016 23:50:27 -0000 Subject: [GHC] #12738: GHC drops -optl flags In-Reply-To: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> References: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> Message-ID: <061.5d522824429e0354870dbc856a5d4e57@haskell.org> #12738: GHC drops -optl flags -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 09:17:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 09:17:45 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.c6e18c50b55c2c14178e2a4b5c702336@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e43f05b62053f4742b105636b7ebf4ce8486b13b/ghc" e43f05b6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e43f05b62053f4742b105636b7ebf4ce8486b13b" Add comments from Trac #12768 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 10:08:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 10:08:27 -0000 Subject: [GHC] #12803: Functional dependencies and type families Message-ID: <046.bf90e6b69da8519ff9649ddaf34345a4@haskell.org> #12803: Functional dependencies and type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ type family F a :: * class C a b | a -> b instance C p (F q) => C p [q] }}} Is the instance decl OK under the liberal coverage condition? That is, does `(C t [s1], C t [s2])` mean that `(s1 ~ s2)`? NO! The context of the instance declaration means that `p -> F q` but that does not imply `p -> q` unless `F` is injective! So this program is wrongly accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 10:08:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 10:08:49 -0000 Subject: [GHC] #12803: Functional dependencies and type families In-Reply-To: <046.bf90e6b69da8519ff9649ddaf34345a4@haskell.org> References: <046.bf90e6b69da8519ff9649ddaf34345a4@haskell.org> Message-ID: <061.b7584d694d9a395ba682b545a3ba0386@haskell.org> #12803: Functional dependencies and type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -17,0 +17,2 @@ + + I realised this when investigating #10778. New description: Consider {{{ type family F a :: * class C a b | a -> b instance C p (F q) => C p [q] }}} Is the instance decl OK under the liberal coverage condition? That is, does `(C t [s1], C t [s2])` mean that `(s1 ~ s2)`? NO! The context of the instance declaration means that `p -> F q` but that does not imply `p -> q` unless `F` is injective! So this program is wrongly accepted. I realised this when investigating #10778. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 11:03:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 11:03:31 -0000 Subject: [GHC] #12694: GHC HEAD no longer reports inaccessible code In-Reply-To: <045.5b8927bc68b32eb0c009890144074b13@haskell.org> References: <045.5b8927bc68b32eb0c009890144074b13@haskell.org> Message-ID: <060.e3c90cc093f46fad64758f474877e3aa@haskell.org> #12694: GHC HEAD no longer reports inaccessible code -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd missed this. Actually it turns out that it's already fixed in 8.0. What happens is this: * `(t1 ~ t2)` is actually a class constraint (homogeneous equality), with superclass `(t1 ~~ t2)` (heterogeneous equality). * `(t1 ~~ t2)` is actuall a class constraint with superclass `(t1 ~# t2)` (true nominal type equality). * The `oclose` function in `FunDeps` already takes account of true nominal equality. Iavor appears to have put this in as part of fe61599ffebb27924c4beef47b6237542644f3f4. To the code above I added {{{ data IndexOf a b data ElementByIdx a b class Measurable a data GraphBuilderT g (m :: * -> *) a data Ptr a b }}} And then your example compiles fine. More precisely, in addition to incorrectly reporting the coverate error, GHC 7.10 correctly says {{{ T10778.hs:18:10: Couldn't match type ‘a’ with ‘ElementByIdx (IndexOf a cont) cont’ ‘a’ is a rigid type variable bound by an instance declaration: (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) at T10778.hs:18:10 Inaccessible code in an instance declaration: (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) In the ambiguity check for an instance declaration: forall a g (m :: * -> *) i idx cont. (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) }}} But because of #12694, #12466, it now says (much more confusingly) {{{ T10778.hs:20:5: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘mkRef3’: mkRef3 = ... }}} The pattern match checker sees that the entire instance is inaccessible, and so reports that the (only) equation for `mkRef3` is redundant. See #12694 for a simpler case. Do you agree that the instance is in fact inaccessible? Want to change the example to something more sensible to add as a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 11:06:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 11:06:03 -0000 Subject: [GHC] #12734: Missed use of solved dictionaries leads to context stack overflow In-Reply-To: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> References: <046.0e1d0f3aa4b3f59f1ccc17171e00b154@haskell.org> Message-ID: <061.d7077113c5b2b38a12fe9f2c2db5c7b5@haskell.org> #12734: Missed use of solved dictionaries leads to context stack overflow -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > By the way, based on your description it reminded me about other bug I filled some time ago. Do you think it could be connected? It is not a high priority bug, but if it's connected maybe it's worth to mention it: #10778 It's not connected, but it's already fixed! I also discovered #12803 in my travels -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 11:07:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 11:07:16 -0000 Subject: [GHC] #10778: GHC doesn't infer all constrains In-Reply-To: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> References: <046.c3c6007a301d4e9f2bfd6528e390abd4@haskell.org> Message-ID: <061.e566652bb37da5a0165cd38c34065072@haskell.org> #10778: GHC doesn't infer all constrains -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd missed this. Actually it turns out that it's already fixed in 8.0. What happens is this: * `(t1 ~ t2)` is actually a class constraint (homogeneous equality), with superclass `(t1 ~~ t2)` (heterogeneous equality). * `(t1 ~~ t2)` is actuall a class constraint with superclass `(t1 ~# t2)` (true nominal type equality). * The `oclose` function in `FunDeps` already takes account of true nominal equality. Iavor appears to have put this in as part of fe61599ffebb27924c4beef47b6237542644f3f4. To the code above I added {{{ data IndexOf a b data ElementByIdx a b class Measurable a data GraphBuilderT g (m :: * -> *) a data Ptr a b }}} And then your example compiles fine. More precisely, in addition to incorrectly reporting the coverate error, GHC 7.10 correctly says {{{ T10778.hs:18:10: Couldn't match type ‘a’ with ‘ElementByIdx (IndexOf a cont) cont’ ‘a’ is a rigid type variable bound by an instance declaration: (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) at T10778.hs:18:10 Inaccessible code in an instance declaration: (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) In the ambiguity check for an instance declaration: forall a g (m :: * -> *) i idx cont. (PtrFrom idx i, Appendable cont idx a, HasContainer g cont, Monad m) => RefBuilder3 a (GraphBuilderT g m) (Ptr i) }}} But because of #12466, it now says (much more confusingly) {{{ T10778.hs:20:5: warning: [-Woverlapping-patterns] Pattern match is redundant In an equation for ‘mkRef3’: mkRef3 = ... }}} The pattern match checker sees that the entire instance is inaccessible, and so reports that the (only) equation for `mkRef3` is redundant. See #12694 for a simpler case. Do you agree that the instance is in fact inaccessible? Want to change the example to something more sensible to add as a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 12:32:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 12:32:46 -0000 Subject: [GHC] #12803: Functional dependencies and type families In-Reply-To: <046.bf90e6b69da8519ff9649ddaf34345a4@haskell.org> References: <046.bf90e6b69da8519ff9649ddaf34345a4@haskell.org> Message-ID: <061.091115d3ccea4a175b38d93f36437461@haskell.org> #12803: Functional dependencies and type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2cdd9bd5208e3ad78d7a3b8b82c8ae1be486b34d/ghc" 2cdd9bd5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2cdd9bd5208e3ad78d7a3b8b82c8ae1be486b34d" Take account of injectivity when doing fundeps This fixes Trac #12803. Yikes! See Note [Care with type functions]. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 12:37:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 12:37:12 -0000 Subject: [GHC] #12803: Functional dependencies and type families In-Reply-To: <046.bf90e6b69da8519ff9649ddaf34345a4@haskell.org> References: <046.bf90e6b69da8519ff9649ddaf34345a4@haskell.org> Message-ID: <061.ce01bcb1fe307f0beec9fb0017137123@haskell.org> #12803: Functional dependencies and type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 13:07:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 13:07:18 -0000 Subject: [GHC] #12801: Misleading error message when deriving Functor In-Reply-To: <044.c2d84a01411727fdbff6e379c4652bd2@haskell.org> References: <044.c2d84a01411727fdbff6e379c4652bd2@haskell.org> Message-ID: <059.7ae7b1bf2086c4eddc2acf1367146275@haskell.org> #12801: Misleading error message when deriving Functor -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think this is a duplicate of #10684, as the failure to derive `Functor` for `Wibble` prevents `Eq` and `Show` from being derived for `Wibble`, causing a cascade of error messages for `Container`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 13:10:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 13:10:24 -0000 Subject: [GHC] #12804: forever contains a space leak Message-ID: <051.e6e8506308627c95310012620f0b2e9d@haskell.org> #12804: forever contains a space leak -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 4.9.0.0's `forever` (implemented in terms of `Applicative`) has a space leak for certain base `Monad`s. The old `forever` (implemented in terms of `Monad`) does not. See these messages for details * https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125177.html * https://mail.haskell.org/pipermail/haskell-cafe/2016-October/125178.html * https://mail.haskell.org/pipermail/haskell- cafe/2016-November/125443.html This is not necessarily `forever`'s fault. It seems likely that the broken behaviour that occurs with `ReaderT` and `StateT` (on `IO`) could be fixed by a specialised implementation of `*>` (for `ReaderT` and `StateT`). Perhaps, then, this bug should ultimately be fixed in `transformers` (and various other packages which supply `Applicative`s) but it is a regression introduced by base-4.9.0.0 so I think it's worthwhile to discuss here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 13:14:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 13:14:39 -0000 Subject: [GHC] #12805: Generalise type of asProxyTypeOf Message-ID: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> #12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Could we please generalise the type of `asProxyTypeOf` to `asProxyTypeOf :: a -> proxy a -> a`? https://hackage.haskell.org/package/base-4.9.0.0/docs/Data- Proxy.html#v:asProxyTypeOf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 16:27:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 16:27:33 -0000 Subject: [GHC] #12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors Message-ID: <048.0512583fd6a7656eb69fd06f05fe112a@haskell.org> #12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've reported on this issue to the stack issue tracker here https://github.com/commercialhaskell/stack/issues/2752#issuecomment-257378515 The steps to reproduce are the following * Make a new stack project (lts-5.3 in my case). stack new curl-test -resolver=lts-5,3 * Add curl as a dependency to the library. * Modify the Lib file to the following {{{ {-# LANGUAGE TemplateHaskell #-} module Lib where return [] someFunc :: IO () someFunc = return () }}} The error that I get with GHC 8 is this {{{ ghc.EXE: unable to load package `curl-1.3.8' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `stricmp' ghc.EXE: Could not on-demand load symbol 'curl_strequal' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `curl_strequal' ghc.EXE: Could not on-demand load symbol '.refptr.Curl_cstrdup' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `.refptr.Curl_cstrdup' ghc.EXE: Could not on-demand load symbol 'curl_slist_free_all' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `curl_slist_free_all' ghc.EXE: Could not on-demand load symbol 'Curl_ssl_connect_nonblocking' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `Curl_ssl_connect_nonblocking' ghc.EXE: Could not on-demand load symbol '.refptr.Curl_crealloc' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `.refptr.Curl_crealloc' ghc.EXE: Could not on-demand load symbol 'curl_msnprintf' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `curl_msnprintf' ghc.EXE: Could not on-demand load symbol '.refptr.Curl_cmalloc' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `.refptr.Curl_cmalloc' ghc.EXE: Could not on-demand load symbol 'Curl_verify_windows_version' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `Curl_verify_windows_version' ghc.EXE: Could not on-demand load symbol 'Curl_sspi_global_init' ghc.EXE: C:\Users\darwi\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\lib\libcurl.a: unknown symbol `Curl_sspi_global_init' ghc.EXE: Could not on-demand load symbol 'curl_global_init' ghc.EXE: C:\sr\snapshots\df48cbae\lib\x86_64-windows- ghc-8.0.1\curl-1.3.8-B8AxMCtSRkiFrZLK4gerBe\HScurl-1.3.8-B8AxMCtSRkiFrZLK4gerBe.o: unknown symbol `curl_global_init' }}} but this still fails with GHC 7.10.3 with a similar error. This is happening on two Windows 10 machines so it's not an isolated case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 16:35:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 16:35:27 -0000 Subject: [GHC] #9010: TemplateHaskell leads to an "unknown symbol" error In-Reply-To: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> References: <048.5b4988a70d3adc65f614ee618855b8f9@haskell.org> Message-ID: <063.a6e506a379c0dda849a9695f92069365@haskell.org> #9010: TemplateHaskell leads to an "unknown symbol" error -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Darwin226): Fair enough. I've created a new ticket. Linking it here in case someone Googles their way to this one https://ghc.haskell.org/trac/ghc/ticket/12806#ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 16:39:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 16:39:27 -0000 Subject: [GHC] #12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors In-Reply-To: <048.0512583fd6a7656eb69fd06f05fe112a@haskell.org> References: <048.0512583fd6a7656eb69fd06f05fe112a@haskell.org> Message-ID: <063.2647caafe33f7951ac68d645c2bbb37a@haskell.org> #12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: Phyx- (added) * os: Unknown/Multiple => Windows * component: Compiler => Runtime System (Linker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 17:26:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 17:26:19 -0000 Subject: [GHC] #12804: forever contains a space leak In-Reply-To: <051.e6e8506308627c95310012620f0b2e9d@haskell.org> References: <051.e6e8506308627c95310012620f0b2e9d@haskell.org> Message-ID: <066.b9e7836e946eb88b0fa13ddcafaf54df@haskell.org> #12804: forever contains a space leak -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): I confirm that the space leak is gone for `ReaderT` of `IO` if I define {{{#!hs f *> v = ReaderT $ \ r -> runReaderT f r *> runReaderT v r }}} I presume (but haven't checked) that the space leak is also gone for `StateT` of `IO` if the corresponding implementation for `*>` is given in the `Applicative` instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 17:28:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 17:28:21 -0000 Subject: [GHC] #12804: forever contains a space leak In-Reply-To: <051.e6e8506308627c95310012620f0b2e9d@haskell.org> References: <051.e6e8506308627c95310012620f0b2e9d@haskell.org> Message-ID: <066.dee3f3a98164a989eb95c63b6093aca0@haskell.org> #12804: forever contains a space leak -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ekmett, core-libraries-committee@… (added) Comment: Adding Edward and the core libraries committee; it's their territory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 17:38:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 17:38:38 -0000 Subject: [GHC] #12804: forever contains a space leak In-Reply-To: <051.e6e8506308627c95310012620f0b2e9d@haskell.org> References: <051.e6e8506308627c95310012620f0b2e9d@haskell.org> Message-ID: <066.c2c99db63790f46b17c2c4d09517774c@haskell.org> #12804: forever contains a space leak -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): Ultimately I conclude that the issue lies in `transformers`, not `base`. I filed this issue on `transformers`: http://hub.darcs.net/ross/transformers/issue/33 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 18:16:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 18:16:55 -0000 Subject: [GHC] #7606: Stride scheduling for Haskell threads with priorities In-Reply-To: <045.581885bdc60230df28dfd649be0a0b27@haskell.org> References: <045.581885bdc60230df28dfd649be0a0b27@haskell.org> Message-ID: <060.d58929dff47c169a57fde1d3804ae767@haskell.org> #7606: Stride scheduling for Haskell threads with priorities -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) Comment: Edward, BTW what's the state of this? The last set of numbers look not too bad at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 19:56:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 19:56:29 -0000 Subject: [GHC] #12804: forever contains a space leak In-Reply-To: <051.e6e8506308627c95310012620f0b2e9d@haskell.org> References: <051.e6e8506308627c95310012620f0b2e9d@haskell.org> Message-ID: <066.7e9b6537e71017e852b30919faa0b2da@haskell.org> #12804: forever contains a space leak -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The `transformers` patch has been merged. Let's hope that Ross releases soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 19:57:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 19:57:06 -0000 Subject: [GHC] #12804: forever contains a space leak In-Reply-To: <051.e6e8506308627c95310012620f0b2e9d@haskell.org> References: <051.e6e8506308627c95310012620f0b2e9d@haskell.org> Message-ID: <066.e44e1da83bd74db428be962b58665071@haskell.org> #12804: forever contains a space leak -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 20:14:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 20:14:46 -0000 Subject: [GHC] #12801: Misleading error message when deriving Functor In-Reply-To: <044.c2d84a01411727fdbff6e379c4652bd2@haskell.org> References: <044.c2d84a01411727fdbff6e379c4652bd2@haskell.org> Message-ID: <059.4a883452016ff903e2c699ea54d09990@haskell.org> #12801: Misleading error message when deriving Functor -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => duplicate Comment: Yes, this is a dupe of #10684. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 20:21:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 20:21:13 -0000 Subject: [GHC] #7606: Stride scheduling for Haskell threads with priorities In-Reply-To: <045.581885bdc60230df28dfd649be0a0b27@haskell.org> References: <045.581885bdc60230df28dfd649be0a0b27@haskell.org> Message-ID: <060.938ec8bf7fc288114ec5c3a48f51f3f7@haskell.org> #7606: Stride scheduling for Haskell threads with priorities -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): No new progress since my last comment! Perhaps we should resurrect this patchset. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 20:37:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 20:37:42 -0000 Subject: [GHC] #12539: Possible typo causes Stack and Cabal installs to fail In-Reply-To: <046.addee2c026228d83f37e1e76899d7fc7@haskell.org> References: <046.addee2c026228d83f37e1e76899d7fc7@haskell.org> Message-ID: <061.8203eb461a063bd6d15a44a4b94d51a7@haskell.org> #12539: Possible typo causes Stack and Cabal installs to fail -------------------------------------+------------------------------------- Reporter: ConorIA | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mitchty): As a note to any future people from google, this was a typo on my part in how I had been getting ghc 7.10 ported to alpine linux and is correct as being invalid as a ghc bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 20:47:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 20:47:45 -0000 Subject: [GHC] #12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors In-Reply-To: <048.0512583fd6a7656eb69fd06f05fe112a@haskell.org> References: <048.0512583fd6a7656eb69fd06f05fe112a@haskell.org> Message-ID: <063.4337f9c51d954cbdde7216ef08772cd5@haskell.org> #12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- * milestone: => 8.2.1 Comment: Thanks for the report. It seems we don't quite deal correctly with symbols at the start of a section. We incorrectly think they're undefined because their addresses are 0. 8.0.2 would alleviate this somewhat as it'll have import library support, so it would like against the DLL in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 20:54:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 20:54:07 -0000 Subject: [GHC] #12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors In-Reply-To: <048.0512583fd6a7656eb69fd06f05fe112a@haskell.org> References: <048.0512583fd6a7656eb69fd06f05fe112a@haskell.org> Message-ID: <063.7dbb3eb16a2d16a4fd4d64ef96b06125@haskell.org> #12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): What I don't quite get is what's causing it to link against anything in the library to begin with.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 21:30:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 21:30:54 -0000 Subject: [GHC] #12807: GHC is too verbose by default (source/object paths) Message-ID: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> #12807: GHC is too verbose by default (source/object paths) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With the default verbosity, GHC shows the path of the source file and the path of the object file (or "interpreted" in GHCi) making the lines very long as in the following example: {{{ [133 of 159] Compiling ViperVM.Arch.Linux.Internals.Input ( src/lib/ViperVM/Arch/Linux/Internals/Input.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Input.o ) [134 of 159] Compiling ViperVM.Arch.Linux.Input ( src/lib/ViperVM/Arch/Linux/Input.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Input.o ) [135 of 159] Compiling ViperVM.System.Input ( src/lib/ViperVM/System/Input.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/System/Input.o ) [136 of 159] Compiling ViperVM.Arch.Linux.Internals.Sound ( src/lib/ViperVM/Arch/Linux/Internals/Sound.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Sound.o ) [137 of 159] Compiling ViperVM.Arch.Linux.Internals.Graphics ( src/lib/ViperVM/Arch/Linux/Internals/Graphics.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Graphics.o ) }}} In most cases, I think we don't need these paths. I propose that we keep this output for the verbose mode and that we change the default behaviour to something like: {{{ [135 of 159] Compiling ViperVM.System.Input (.hs -> .o) [136 of 159] Compiling ViperVM.Arch.Linux.Internals.Sound (.hs -> .o) -- GHCi [137 of 159] Compiling ViperVM.Arch.Linux.Internals.Graphics (.hs -> interpreted) }}} It is also particularily nice with BackPack that uses hashes in output paths: we may not want to expose them to users by default. Example: {{{#!patch [1 of 1] Including p[A=r:A] Instantiating p[A=r:A] - [1 of 2] Compiling A[sig] ( p/A.hsig, bkp26.out/p/p-8YQRY0unRYZCev5HBjXieS/A.o ) - [2 of 2] Compiling P ( p/P.hs, bkp26.out/p/p-8YQRY0unRYZCev5HBjXieS/P.o ) - [1 of 1] Compiling M ( q/M.hs, bkp26.out/q/M.o ) + [1 of 2] Compiling A[sig] (.hsig -> .o) + [2 of 2] Compiling P (.hs -> .o) + [1 of 1] Compiling M (.hs -> .o) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 21:33:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 21:33:56 -0000 Subject: [GHC] #12807: GHC is too verbose by default (source/object paths) In-Reply-To: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> References: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> Message-ID: <060.2f4ffb7e512c3b09185213af9d44ef72@haskell.org> #12807: GHC is too verbose by default (source/object paths) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2679 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D2679 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 22:58:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 22:58:41 -0000 Subject: [GHC] #12807: GHC is too verbose by default (source/object paths) In-Reply-To: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> References: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> Message-ID: <060.da2443fba7f97b755224d4024514783f@haskell.org> #12807: GHC is too verbose by default (source/object paths) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2679 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK by me. Is there a flag to show the path? Sometimes there is doubt and being able to see is good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 23:13:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 23:13:14 -0000 Subject: [GHC] #12800: hs_try_putmvar003 sometimes fails In-Reply-To: <046.e1837edaff3493c41289a90d2307655f@haskell.org> References: <046.e1837edaff3493c41289a90d2307655f@haskell.org> Message-ID: <061.3cd423fa0b164cbc706d14e746e06fa5@haskell.org> #12800: hs_try_putmvar003 sometimes fails -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2678 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D2678 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 4 23:13:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 04 Nov 2016 23:13:39 -0000 Subject: [GHC] #12800: hs_try_putmvar003 sometimes fails In-Reply-To: <046.e1837edaff3493c41289a90d2307655f@haskell.org> References: <046.e1837edaff3493c41289a90d2307655f@haskell.org> Message-ID: <061.e4e2c14d9c47ad6837a3b6a97a329201@haskell.org> #12800: hs_try_putmvar003 sometimes fails -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2678 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 00:58:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 00:58:12 -0000 Subject: [GHC] #12807: GHC is too verbose by default (source/object paths) In-Reply-To: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> References: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> Message-ID: <060.cfce1fb5aacf207c389d9d954867bbfa@haskell.org> #12807: GHC is too verbose by default (source/object paths) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2679 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I have added one: `-fshow-module-paths` (I'm not sure I have followed flag conventions, nor if the name is the best for this). It can be used instead of `-v2` (or higher verbosity) which may be too verbose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 05:34:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 05:34:41 -0000 Subject: [GHC] #11571: Need more intelligent conditionalization of libgcc rts symbols for x32 In-Reply-To: <047.5f427ce2a17580df7f32c78c02d7671e@haskell.org> References: <047.5f427ce2a17580df7f32c78c02d7671e@haskell.org> Message-ID: <062.52ab09e5826528dcf8076c7268f2f1d5@haskell.org> #11571: Need more intelligent conditionalization of libgcc rts symbols for x32 --------------------------------------------+----------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System (Linker) | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+----------------------------- Changes (by glaubitz): * Attachment "x32-use-native-x86_64-insn.patch" added. Minimal patch to support ghc on x32. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 05:37:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 05:37:24 -0000 Subject: [GHC] #11571: Need more intelligent conditionalization of libgcc rts symbols for x32 In-Reply-To: <047.5f427ce2a17580df7f32c78c02d7671e@haskell.org> References: <047.5f427ce2a17580df7f32c78c02d7671e@haskell.org> Message-ID: <062.e935e5994d230ab563ecf7ce6324d3cd@haskell.org> #11571: Need more intelligent conditionalization of libgcc rts symbols for x32 --------------------------------------------+----------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System (Linker) | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+----------------------------- Comment (by glaubitz): I suggest the patch attached above. I extended the x32 detection in rts/RtsSymbols.c to use "!(defined(__x86_64__) && defined(__ILP32__))". Could we apply this one so that GHC can at least build as unregisterised on x32 without any problems? If I remember correctly, on x32 I also had to use Integer-Simple to make it build. Thanks, Adrian -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 06:00:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 06:00:47 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... Message-ID: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- '''Background:''' I've been intrigued investigating whether GHC can produce code "as fast as Cee (C/C++/Rust/etc.)" by-any-means-possible, and have been using the very tight inner composite culling loops (purely integer operations) of a basic Sieve of Eratosthenes implementation as a test vehicle. '''Synopsis:''' This is a follow-on of the work leading to finding the efficiency problem described in ticket #12798, but involves pushing the speed even further as per the method described for "primesieve as per [http://primesieve.org/] in the "Highly optimized inner loop" section. '''Description of test code:''' Essentially, this method involves extreme loop unrolling with very imperative code although coded functionally; in the case of the following code it means that, recognizing that for all odd primes (which they all are other than two), and that all word sizes are of an even number of bits, there will be a repeating pattern of composite number culls that repeats every word size number of bits. Thus for a word size of one eight-bit byte, we can unroll to eight composite culls in the body of one loop, with loops cases for the primes modulo 8 of 1, 3, 5, and 7, and for the eight bit start positions (b0..b7) meaning there are four times eight is 32 loop cases. When there are no longer a full eight culls left, the culling reverts to conventional single-cull-per-loop as per the test program of ticket #12798. To do this using GHC we need pointer arithmetic, and the only way to implement pointer arithmetic in GHC is to use the Addr# primitive. GHC/Haskell has one other slight overhead over Cee languages in that we need to move the culling array to a pinned array to avoid having it moved while the culling is going on and then move it back when finished but this takes a negligible amount of time (one percent or so) as compared to the culling. As usual for test programs, the culling operations are repeated in a loop for a number of times to give more accurate timing not influenced by execution not related to the culling. All of this is included in the following code (truncated as to loop coses for inclusion here): {{{#!hs -- EfficiencyBug.hs -- showing that there is a register loop invariant bug in generation of assembler code... -- LLVM shows the bug clearer since the code is generally a little faster... {-# LANGUAGE FlexibleContexts, BangPatterns, MagicHash, UnboxedTuples #-} {-# OPTIONS_GHC -O2 -rtsopts -keep-s-files #-} -- or -O2 -fllvm import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base import GHC.ST ( ST(..) ) import GHC.Exts numLOOPS = 10000 :: Int -- Uses a very simple Sieve of Eratosthenes for fixed 2 ^ 18 range (so one L1 cache size) to prove it. twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soep1 :: () -> [Word32] soep1() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfBts = (256 * 1024) `div` 2 -- to 2^18 + 2 is 128 KBits = 16 KBytes bf <- newArray (0, bfBts - 1) False :: ST s (STUArray s Int Bool) cullb bf cullb bf@(STUArray l u n marr#) = ST $ \s0# -> case getSizeofMutableByteArray# marr# s0# of { (# s1#, n# #) -> let loop t mr# s0# = -- cull a number of times to test timing if t <= 0 then (# s0#, STUArray l u n mr# #) else case getSizeofMutableByteArray# mr# s0# of { (# s1#, n# #) -> case newPinnedByteArray# n# s1# of { (# s2#, marr'# #) -> case copyMutableByteArray# mr# 0# marr'# 0# n# s2# of { s3# -> case unsafeFreezeByteArray# marr'# s3# of { (# s4#, arr# #) -> -- must do this case byteArrayContents# arr# of { adr# -> -- to obtain the addr# here let cullp i@(I# i#) sp# = let !p@(I# p#) = i + i + 3 in let !s@(I# s#) = (p * p - 3) `div` 2 in if s >= n then case copyMutableByteArray# marr'# 0# mr# 0# n# sp# of so# -> (# so#, mr# #) else let !(UArray _ _ _ tarr#) = twos in case readWord64Array# marr# (i# `uncheckedIShiftRL#` 6#) sp# of { (# sp0#, v0# #) -> case (v0# `and#` ((int2Word# 1#) `uncheckedShiftL#` (i# `andI#` 63#))) `eqWord#` (int2Word# 0#) of 0# -> cullp (i + 1) sp0# -- not prime _ -> -- is prime -- most program execution time spent in the following tight loops. -- the following code implments extream loop unrolling... let !pi@(I# pi#) = fromIntegral p in let !sw@(I# sw#) = s `shiftR` 3 in let !sb@(I# sb#) = s .&. 7 in let p1 = sb + pi in let !(I# r1#) = p1 `shiftR` 3 in let p2 = p1 + pi in let !(I# r2#) = p2 `shiftR` 3 in let p3 = p2 + pi in let !(I# r3#) = p3 `shiftR` 3 in let p4 = p3 + pi in let !(I# r4#) = p4 `shiftR` 3 in let p5 = p4 + pi in let !(I# r5#) = p5 `shiftR` 3 in let p6 = p5 + pi in let !(I# r6#) = p6 `shiftR` 3 in let p7 = p6 + pi in let !(I# r7#) = p7 `shiftR` 3 in let !lmt@(I# lmt#) = (fromIntegral n `shiftR` 3) - p7 in let !lmt1# = plusAddr# adr# lmt# in let !strt# = plusAddr# adr# sw# in let !(I# n#) = n in let (# !so#, !sco# #) = case ((((p - 1) `div` 2) .&. 3) `shiftL` 3) + sb of { 0 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 1#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 2#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 4#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 8#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 16#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 32#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 64#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 128#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; 1 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 2#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 4#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 8#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 16#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 32#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 64#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 128#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 1#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; -- and so on for 30 more cases... _ -> (# strt#, sp0# #) {- normally never taken case, all cases covered -} } in let !ns# = ((minusAddr# so# adr#) `uncheckedIShiftL#` 3#) +# sb# in -- extreme loop unrolling ends here; remaining primes culled conventionally... let cull j# sc# = -- very tight inner loop case j# <# n# of 0# -> cullp (i + 1) sc# _ -> let i# = j# `andI#` 31# in let !sh# = indexWord32Array# tarr# i# in -- (1 `shiftL` (j .&. 31))) let w# = j# `uncheckedIShiftRL#` 5# in case readWord32Array# marr'# w# sc# of { (# sc0#, ov# #) -> case writeWord32Array# marr'# w# (ov# `or#` sh#) sc0# of { sc1# -> cull (j# +# pi#) sc1# }} in cull ns# sp0# } in case cullp 0 s4# of (# sp#, mrp# #) -> loop (t - 1) mrp# sp# }}}}} in loop numLOOPS marr# s1# } main = print $ length $ soep1() }}} '''The problem:''' The problem is in the innermost loop of the cases, for which case "0" the following assembly code (using -fllvm) is produced: {{{ seGU_info$def: # BB#0: # %cgRL cmpq %r14, 70(%rbx) jbe .LBB35_1 .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax addq %r14, %rax orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) cmpq 70(%rbx), %rax movq %rax, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx rex64 jmpq *%rcx # TAILCALL }}} One can readily see that the compiler is not lifting the Loop Invariant Code Flow as in initializing the registers to outside the inner loop, meaning there are many register loads from memory which are not necessary. '''Desired results:''' The desired assembly code is something like the following, which is similar to what is produced by Cee (C/C++/Rust/etc.): {{{ seGU_info$def: # BB#0: # %cgRL movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax movq 70(%rbx), %rbx cmpq %r14, %rbx jbe .LBB35_1 .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) addq %rax, %r14 cmpq %rbx, %rax jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx # rbx clobbered here anyway rex64 jmpq *%rcx # TAILCALL }}} '''Full testing:''' The actual unrolled loop code is too long to post here, but to verify the result is correct (23000) and the performance, the full actual file is attached here. Due to the magic of modern CPU instruction fusion, the code is not as slow as it would indicate by the number of increased instructions, but while it is about twice as fast as when culled conventionally (Intel Skylake), it is about half again as slow as Cee. On an Intel Sky Lake i5-6500 (running at 3.5 GHz for single threading), this takes about one second, about two seconds culled conventionally, but only about 0.6 seconds for Rust/LLVM (with the assembly code output essentially identical to the "desired" code). '''Other back ends and targets:''' Although the code generated by the native NCG has other problems (not moving the loop test to the end of the loop to avoid one jump, and not combining the read and modify and store instructions into the single available instruction), it exhibits the same problem as to not lifting the Loop Invariant Code Flow register initialization. Although this code is x86_64, the problem also applies to x86 code even though the x86 architecture doesn't have enough registers to do this in one loop and needs to be split into two loops culling only four composites per loop, but there still is a significant gain in speed. Although not tested, it probably also applies to other targets such as ARM (which has many general purpose registers). '''Conclusion:''' The use of Addr# primitives is probably not a frequent use case, but as shown here that when one needs their use, they should be efficient. I considered that GHC may intentionally limit the performance of these unsafe primitives to limit their use unless absolutely necessary as in marshalling, something as C## does for the use of unsafe pointers, but surely GHC would not do that as the target programmers are different. '''If this and ticket #12798 were fixed, for this use case the GHC code would be within a percent or two of the performance of Cee.''' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 06:01:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 06:01:31 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.06f40eca01cc3e28fe57f8394d476e57@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by GordonBGood): * Attachment "GHC_EfficiencyBug.hs" added. Test program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 15:01:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 15:01:49 -0000 Subject: [GHC] #12809: TYPE 'UnboxedTupleRep is still a lie Message-ID: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> #12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new scheme for describing kinds of types with values with `TYPE :: RuntimeRep -> Type` is a large improvement on the old way of using kind `#` for all unlifted types. In particular, the new scheme differentiates between the kind of `Int#` and `Float#`, for example, because these have different calling conventions. This is Good. But there is still a lie left in the whole scheme: `UnboxedTupleRep`, which covers all unboxed tuples. Of course, unboxed tuples of different arities and contents have different calling conventions, so these should be distinguished at the kind level. Simon and I have cooked up a new scheme to handle this, summarized in these definitions: {{{#!hs TYPE :: RuntimeRep -> Type -- highly magical, just as before type RuntimeRep = [UnaryRep] -- this bit is the new part data UnaryRep = PtrRepLifted -- like the old RuntimeRep type | PtrRepUnlifted | IntRep | ... type Lifted = '[PtrRepLifted] -- a very common case type Type = TYPE Lifted -- good old Type }}} The `UnaryRep` type is the big sum of all possible representations, just like the `RuntimeRep` of today. It drops `VoidRep` and `UnboxedTupleRep`, however. The interpretation of this is that the kinds now include a ''list'' of unary representation forms. A "unary representation" corresponds to what we might expect to store in one machine register at runtime. Unboxed tuples naturally have a variable number of associated unary reps: this is precisely what an unboxed tuple means. It also baldly states that the unary unboxed tuple is identical (at runtime) to the thing in the tuple (which is correct) and also allows us to remove the runtime distinction between `(# #)` and `Void#`, which now both have kind `TYPE '[]`. (Indeed, perhaps we should just say `type Void# = (# #)`.) This will not be backward compatible with GHC 8.0. But I'm OK with this, as any user access to these features requires importing internal modules, and it seems quite painful to try to come up with a migration story here for an experimental feature. Patch will be written this weekend, with any luck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 16:05:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 16:05:23 -0000 Subject: [GHC] #12809: TYPE 'UnboxedTupleRep is still a lie In-Reply-To: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> References: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> Message-ID: <062.53a3645fb2d06f3b8add22245c542427@haskell.org> #12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: If this is implemented, will it obviate the error-checks needed to fix things like #11723, #11724, #11509, etc.? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 16:06:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 16:06:52 -0000 Subject: [GHC] #12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors In-Reply-To: <048.0512583fd6a7656eb69fd06f05fe112a@haskell.org> References: <048.0512583fd6a7656eb69fd06f05fe112a@haskell.org> Message-ID: <063.04d87895d45e53b48f1fdb5a37f512d0@haskell.org> #12806: curl dependency in conjunction with Template Haskell causes "unknown symbol" errors -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 17:32:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 17:32:44 -0000 Subject: [GHC] #12739: Failure installing elm-init-1.0.5 (ExitFailure (-6)) In-Reply-To: <044.d04b081fdc88360a67572c2b270dd90a@haskell.org> References: <044.d04b081fdc88360a67572c2b270dd90a@haskell.org> Message-ID: <059.c098aad6a4b3668144381b26eb381e3d@haskell.org> #12739: Failure installing elm-init-1.0.5 (ExitFailure (-6)) ---------------------------------+-------------------------------------- Reporter: rofer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by lspitzner): I observed a similar error for a different package. Also on ghc-7.8.4 and both 32/64bit x86. In my case it seems to be connected to template- haskell-2.11.0.0, i.e. if i constrain template-haskell to ==2.9.0.0, compilation works again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 20:27:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 20:27:38 -0000 Subject: [GHC] #12810: -Wredundant-constraints doesn't factor in associated type families Message-ID: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> #12810: -Wredundant-constraints doesn't factor in associated type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I compile this code: {{{#!hs {-# LANGUAGE TypeFamilies #-} module M where class C a where type T a instance C a => C [a] where type T [a] = T a }}} with `-Wredundant-constraints` enabled, it complains: {{{ $ /opt/ghc/head/bin/ghc -Wredundant-constraints M.hs [1 of 1] Compiling M ( M.hs, M.o ) M.hs:7:10: warning: [-Wredundant-constraints] • Redundant constraint: C a • In the instance declaration for ‘C [a]’ }}} I don't think this is right. The RHS of `T [a]` won't be able to reduce unless there's a `T a` instance available–that is, unless there's a `C a` instance available, which is what the context provides, making it non- redundant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 20:51:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 20:51:59 -0000 Subject: [GHC] #12810: -Wredundant-constraints doesn't factor in associated type families In-Reply-To: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> References: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> Message-ID: <065.135f78955e8dd92683f72a9ddb7acbbf@haskell.org> #12810: -Wredundant-constraints doesn't factor in associated type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This also came up in Phab:D2636 (the fix for #2721 and #8165), since you can now use `GeneralizedNewtypeDeriving` to derive an instance for a class with an associated type family on a newtype. But in [https://phabricator.haskell.org/D2636#77793 this example]: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-} class C a where type T a newtype Identity a = Identity a deriving C }}} If you compile this with `-Wredundant-constraints`, GHC will look at the derived instance: {{{#!hs instance C a => C (Identity a) where type T (Identity a) = T a }}} And it will emit a warning! {{{ • Redundant constraint: C a • In the instance declaration for ‘C (Identity a)’ }}} This might be even worse that the original example, because now it's //GHC// that's providing the redundant constraint, not the programmer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 20:56:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 20:56:41 -0000 Subject: [GHC] #12810: -Wredundant-constraints doesn't factor in associated type families In-Reply-To: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> References: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> Message-ID: <065.e884d572400ed177eacca4a74b7ee2e4@haskell.org> #12810: -Wredundant-constraints doesn't factor in associated type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well type families are allowed to not reduce. For example {{{ *M> :t undefined :: T Int undefined :: T Int :: T Int }}} there's nothing stopping you from writing `T Int`, regardless of whether there is an instance `C Int`. So GHC's warning is consistent with that. In your comment, the problem doesn't seem to be the type family, but rather the lack of any methods. An empty class body gives the same warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 21:08:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 21:08:15 -0000 Subject: [GHC] #12810: -Wredundant-constraints doesn't factor in associated type families In-Reply-To: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> References: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> Message-ID: <065.601db41ee1d14b1055bdb888155fdacc@haskell.org> #12810: -Wredundant-constraints doesn't factor in associated type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Bah, my mental model of associated families has tripped me up once again. I would have sworn that this code would have been a counterexample to your claim: {{{#!hs {-# LANGUAGE TypeFamilies #-} module M where class C a where type T a instance C Int where type T Int = Bool instance {- C a => -} C [a] where type T [a] = T a f :: T [Int] -> Bool f x = x }}} But to my surprise, that typechecks even in the absence of that `C a` constraint on the `C [a]` instance. So I can see your point. I suppose then that this is actually subsumed under #11369? Or is the presence of associated type families enough to make a class no longer "empty"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 22:09:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 22:09:43 -0000 Subject: [GHC] #12164: Type signatures in patterns not (yet) handled by Template Haskell In-Reply-To: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> References: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> Message-ID: <060.a473b55cd2b6b7162e5d229737352801@haskell.org> #12164: Type signatures in patterns not (yet) handled by Template Haskell -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"b0121209f8fb47a7cb8fc32e10d8e2c06d4502c2/ghc" b0121209/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b0121209f8fb47a7cb8fc32e10d8e2c06d4502c2" Handle types w/ type variables in signatures inside patterns (DsMeta) The comment indicated that scoping of type variables was a large problem but Simon fixed it in e21e13fb52b99b14770cc5857df57bbcc9c85102. Thus, we can implement repP for signatures very easily in the usual way now. Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: mpickering, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2490 GHC Trac Issues: #12164 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 23:10:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 23:10:10 -0000 Subject: [GHC] #12692: Can't find interface-file decl with Typeable In-Reply-To: <047.8081d198b95305daa8d4af7070a41151@haskell.org> References: <047.8081d198b95305daa8d4af7070a41151@haskell.org> Message-ID: <062.37865052b53a9469ff5092f09754fffa@haskell.org> #12692: Can't find interface-file decl with Typeable -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12132 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12132 * milestone: => 8.0.2 Comment: This is really #12132 in disguise (which has been fixed in GHC 8.0.2 and HEAD). You can see this by observing the output of compiling `Main` with `-ddump-splices`: {{{ [3 of 3] Compiling Main ( Main.hs, interpreted ) Main.hs:7:3-26: Splicing declarations sequence [ppDec $ (2, 1)] ======> type PP2 = PP '(P (PosBin.D0 PosBin.B1), PosBin.O) }}} The key part is that `PP2` contains a promoted boxed tuple, and the error happens when you try to get the `Typeable` instance for it. In any case, this has already been fixed, and it'd be impractical to create a regression test from all of this `singletons` code, so I'll just close this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 5 23:29:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 05 Nov 2016 23:29:04 -0000 Subject: [GHC] #12811: GHC tells me to use RankNTypes when it's already enabled Message-ID: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> #12811: GHC tells me to use RankNTypes when it's already enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was stumped for a while today because GHC kept telling me to turn on `RankNTypes` even when it was already enabled! I eventually realized this was the problem: {{{#!hs {-# LANGUAGE RankNTypes #-} module Bug where foo :: foral a. a -> a foo x = x }}} {{{ $ ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:15: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall . }}} That is, the real culprit was misspelling `forall` as `foral`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 02:18:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 02:18:53 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.c4d9c3707508587a760ed479b7f1211c@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by GordonBGood: @@ -288,1 +288,1 @@ - cmpq %rbx, %rax + cmpq %rbx, %r14 @@ -298,10 +298,11 @@ - '''Full testing:''' The actual unrolled loop code is too long to post - here, but to verify the result is correct (23000) and the performance, the - full actual file is attached here. Due to the magic of modern CPU - instruction fusion, the code is not as slow as it would indicate by the - number of increased instructions, but while it is about twice as fast as - when culled conventionally (Intel Skylake), it is about half again as slow - as Cee. On an Intel Sky Lake i5-6500 (running at 3.5 GHz for single - threading), this takes about one second, about two seconds culled - conventionally, but only about 0.6 seconds for Rust/LLVM (with the - assembly code output essentially identical to the "desired" code). + '''Full testing:''' The actual unrolled loop code including all the case + loops is too long to post here, but to verify the result is correct + (23000) and the performance, the full actual file is attached here. Due + to the magic of modern CPU instruction fusion and Out Of Order (OOE) + execution, the code is not as slow as it would indicate by the number of + increased instructions, but while it is about twice as fast as when culled + conventionally (Intel Skylake), it is about half again as slow as Cee. On + an Intel Sky Lake i5-6500 (running at 3.5 GHz for single threading), this + takes about one second, about two seconds culled conventionally, but only + about 0.6 seconds for Rust/LLVM (with the assembly code output essentially + identical to the "desired" code). @@ -329,1 +330,1 @@ - marshalling, something as C## does for the use of unsafe pointers, but + marshalling, something as C# does for the use of unsafe pointers, but New description: '''Background:''' I've been intrigued investigating whether GHC can produce code "as fast as Cee (C/C++/Rust/etc.)" by-any-means-possible, and have been using the very tight inner composite culling loops (purely integer operations) of a basic Sieve of Eratosthenes implementation as a test vehicle. '''Synopsis:''' This is a follow-on of the work leading to finding the efficiency problem described in ticket #12798, but involves pushing the speed even further as per the method described for "primesieve as per [http://primesieve.org/] in the "Highly optimized inner loop" section. '''Description of test code:''' Essentially, this method involves extreme loop unrolling with very imperative code although coded functionally; in the case of the following code it means that, recognizing that for all odd primes (which they all are other than two), and that all word sizes are of an even number of bits, there will be a repeating pattern of composite number culls that repeats every word size number of bits. Thus for a word size of one eight-bit byte, we can unroll to eight composite culls in the body of one loop, with loops cases for the primes modulo 8 of 1, 3, 5, and 7, and for the eight bit start positions (b0..b7) meaning there are four times eight is 32 loop cases. When there are no longer a full eight culls left, the culling reverts to conventional single-cull-per-loop as per the test program of ticket #12798. To do this using GHC we need pointer arithmetic, and the only way to implement pointer arithmetic in GHC is to use the Addr# primitive. GHC/Haskell has one other slight overhead over Cee languages in that we need to move the culling array to a pinned array to avoid having it moved while the culling is going on and then move it back when finished but this takes a negligible amount of time (one percent or so) as compared to the culling. As usual for test programs, the culling operations are repeated in a loop for a number of times to give more accurate timing not influenced by execution not related to the culling. All of this is included in the following code (truncated as to loop coses for inclusion here): {{{#!hs -- EfficiencyBug.hs -- showing that there is a register loop invariant bug in generation of assembler code... -- LLVM shows the bug clearer since the code is generally a little faster... {-# LANGUAGE FlexibleContexts, BangPatterns, MagicHash, UnboxedTuples #-} {-# OPTIONS_GHC -O2 -rtsopts -keep-s-files #-} -- or -O2 -fllvm import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base import GHC.ST ( ST(..) ) import GHC.Exts numLOOPS = 10000 :: Int -- Uses a very simple Sieve of Eratosthenes for fixed 2 ^ 18 range (so one L1 cache size) to prove it. twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soep1 :: () -> [Word32] soep1() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfBts = (256 * 1024) `div` 2 -- to 2^18 + 2 is 128 KBits = 16 KBytes bf <- newArray (0, bfBts - 1) False :: ST s (STUArray s Int Bool) cullb bf cullb bf@(STUArray l u n marr#) = ST $ \s0# -> case getSizeofMutableByteArray# marr# s0# of { (# s1#, n# #) -> let loop t mr# s0# = -- cull a number of times to test timing if t <= 0 then (# s0#, STUArray l u n mr# #) else case getSizeofMutableByteArray# mr# s0# of { (# s1#, n# #) -> case newPinnedByteArray# n# s1# of { (# s2#, marr'# #) -> case copyMutableByteArray# mr# 0# marr'# 0# n# s2# of { s3# -> case unsafeFreezeByteArray# marr'# s3# of { (# s4#, arr# #) -> -- must do this case byteArrayContents# arr# of { adr# -> -- to obtain the addr# here let cullp i@(I# i#) sp# = let !p@(I# p#) = i + i + 3 in let !s@(I# s#) = (p * p - 3) `div` 2 in if s >= n then case copyMutableByteArray# marr'# 0# mr# 0# n# sp# of so# -> (# so#, mr# #) else let !(UArray _ _ _ tarr#) = twos in case readWord64Array# marr# (i# `uncheckedIShiftRL#` 6#) sp# of { (# sp0#, v0# #) -> case (v0# `and#` ((int2Word# 1#) `uncheckedShiftL#` (i# `andI#` 63#))) `eqWord#` (int2Word# 0#) of 0# -> cullp (i + 1) sp0# -- not prime _ -> -- is prime -- most program execution time spent in the following tight loops. -- the following code implments extream loop unrolling... let !pi@(I# pi#) = fromIntegral p in let !sw@(I# sw#) = s `shiftR` 3 in let !sb@(I# sb#) = s .&. 7 in let p1 = sb + pi in let !(I# r1#) = p1 `shiftR` 3 in let p2 = p1 + pi in let !(I# r2#) = p2 `shiftR` 3 in let p3 = p2 + pi in let !(I# r3#) = p3 `shiftR` 3 in let p4 = p3 + pi in let !(I# r4#) = p4 `shiftR` 3 in let p5 = p4 + pi in let !(I# r5#) = p5 `shiftR` 3 in let p6 = p5 + pi in let !(I# r6#) = p6 `shiftR` 3 in let p7 = p6 + pi in let !(I# r7#) = p7 `shiftR` 3 in let !lmt@(I# lmt#) = (fromIntegral n `shiftR` 3) - p7 in let !lmt1# = plusAddr# adr# lmt# in let !strt# = plusAddr# adr# sw# in let !(I# n#) = n in let (# !so#, !sco# #) = case ((((p - 1) `div` 2) .&. 3) `shiftL` 3) + sb of { 0 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 1#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 2#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 4#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 8#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 16#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 32#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 64#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 128#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; 1 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 2#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 4#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 8#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 16#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 32#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 64#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 128#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 1#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; -- and so on for 30 more cases... _ -> (# strt#, sp0# #) {- normally never taken case, all cases covered -} } in let !ns# = ((minusAddr# so# adr#) `uncheckedIShiftL#` 3#) +# sb# in -- extreme loop unrolling ends here; remaining primes culled conventionally... let cull j# sc# = -- very tight inner loop case j# <# n# of 0# -> cullp (i + 1) sc# _ -> let i# = j# `andI#` 31# in let !sh# = indexWord32Array# tarr# i# in -- (1 `shiftL` (j .&. 31))) let w# = j# `uncheckedIShiftRL#` 5# in case readWord32Array# marr'# w# sc# of { (# sc0#, ov# #) -> case writeWord32Array# marr'# w# (ov# `or#` sh#) sc0# of { sc1# -> cull (j# +# pi#) sc1# }} in cull ns# sp0# } in case cullp 0 s4# of (# sp#, mrp# #) -> loop (t - 1) mrp# sp# }}}}} in loop numLOOPS marr# s1# } main = print $ length $ soep1() }}} '''The problem:''' The problem is in the innermost loop of the cases, for which case "0" the following assembly code (using -fllvm) is produced: {{{ seGU_info$def: # BB#0: # %cgRL cmpq %r14, 70(%rbx) jbe .LBB35_1 .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax addq %r14, %rax orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) cmpq 70(%rbx), %rax movq %rax, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx rex64 jmpq *%rcx # TAILCALL }}} One can readily see that the compiler is not lifting the Loop Invariant Code Flow as in initializing the registers to outside the inner loop, meaning there are many register loads from memory which are not necessary. '''Desired results:''' The desired assembly code is something like the following, which is similar to what is produced by Cee (C/C++/Rust/etc.): {{{ seGU_info$def: # BB#0: # %cgRL movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax movq 70(%rbx), %rbx cmpq %r14, %rbx jbe .LBB35_1 .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) addq %rax, %r14 cmpq %rbx, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx # rbx clobbered here anyway rex64 jmpq *%rcx # TAILCALL }}} '''Full testing:''' The actual unrolled loop code including all the case loops is too long to post here, but to verify the result is correct (23000) and the performance, the full actual file is attached here. Due to the magic of modern CPU instruction fusion and Out Of Order (OOE) execution, the code is not as slow as it would indicate by the number of increased instructions, but while it is about twice as fast as when culled conventionally (Intel Skylake), it is about half again as slow as Cee. On an Intel Sky Lake i5-6500 (running at 3.5 GHz for single threading), this takes about one second, about two seconds culled conventionally, but only about 0.6 seconds for Rust/LLVM (with the assembly code output essentially identical to the "desired" code). '''Other back ends and targets:''' Although the code generated by the native NCG has other problems (not moving the loop test to the end of the loop to avoid one jump, and not combining the read and modify and store instructions into the single available instruction), it exhibits the same problem as to not lifting the Loop Invariant Code Flow register initialization. Although this code is x86_64, the problem also applies to x86 code even though the x86 architecture doesn't have enough registers to do this in one loop and needs to be split into two loops culling only four composites per loop, but there still is a significant gain in speed. Although not tested, it probably also applies to other targets such as ARM (which has many general purpose registers). '''Conclusion:''' The use of Addr# primitives is probably not a frequent use case, but as shown here that when one needs their use, they should be efficient. I considered that GHC may intentionally limit the performance of these unsafe primitives to limit their use unless absolutely necessary as in marshalling, something as C# does for the use of unsafe pointers, but surely GHC would not do that as the target programmers are different. '''If this and ticket #12798 were fixed, for this use case the GHC code would be within a percent or two of the performance of Cee.''' -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 02:25:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 02:25:37 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.029784a5faa06fa599bcb09b4464dc36@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by GordonBGood: @@ -273,2 +273,4 @@ - cmpq %r14, %rbx - jbe .LBB35_1 + cmpq %r14, %rbx # rbx clobbered here, but old + value + jbe .LBB35_1 # never used again until replaced + after loop New description: '''Background:''' I've been intrigued investigating whether GHC can produce code "as fast as Cee (C/C++/Rust/etc.)" by-any-means-possible, and have been using the very tight inner composite culling loops (purely integer operations) of a basic Sieve of Eratosthenes implementation as a test vehicle. '''Synopsis:''' This is a follow-on of the work leading to finding the efficiency problem described in ticket #12798, but involves pushing the speed even further as per the method described for "primesieve as per [http://primesieve.org/] in the "Highly optimized inner loop" section. '''Description of test code:''' Essentially, this method involves extreme loop unrolling with very imperative code although coded functionally; in the case of the following code it means that, recognizing that for all odd primes (which they all are other than two), and that all word sizes are of an even number of bits, there will be a repeating pattern of composite number culls that repeats every word size number of bits. Thus for a word size of one eight-bit byte, we can unroll to eight composite culls in the body of one loop, with loops cases for the primes modulo 8 of 1, 3, 5, and 7, and for the eight bit start positions (b0..b7) meaning there are four times eight is 32 loop cases. When there are no longer a full eight culls left, the culling reverts to conventional single-cull-per-loop as per the test program of ticket #12798. To do this using GHC we need pointer arithmetic, and the only way to implement pointer arithmetic in GHC is to use the Addr# primitive. GHC/Haskell has one other slight overhead over Cee languages in that we need to move the culling array to a pinned array to avoid having it moved while the culling is going on and then move it back when finished but this takes a negligible amount of time (one percent or so) as compared to the culling. As usual for test programs, the culling operations are repeated in a loop for a number of times to give more accurate timing not influenced by execution not related to the culling. All of this is included in the following code (truncated as to loop coses for inclusion here): {{{#!hs -- EfficiencyBug.hs -- showing that there is a register loop invariant bug in generation of assembler code... -- LLVM shows the bug clearer since the code is generally a little faster... {-# LANGUAGE FlexibleContexts, BangPatterns, MagicHash, UnboxedTuples #-} {-# OPTIONS_GHC -O2 -rtsopts -keep-s-files #-} -- or -O2 -fllvm import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base import GHC.ST ( ST(..) ) import GHC.Exts numLOOPS = 10000 :: Int -- Uses a very simple Sieve of Eratosthenes for fixed 2 ^ 18 range (so one L1 cache size) to prove it. twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soep1 :: () -> [Word32] soep1() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfBts = (256 * 1024) `div` 2 -- to 2^18 + 2 is 128 KBits = 16 KBytes bf <- newArray (0, bfBts - 1) False :: ST s (STUArray s Int Bool) cullb bf cullb bf@(STUArray l u n marr#) = ST $ \s0# -> case getSizeofMutableByteArray# marr# s0# of { (# s1#, n# #) -> let loop t mr# s0# = -- cull a number of times to test timing if t <= 0 then (# s0#, STUArray l u n mr# #) else case getSizeofMutableByteArray# mr# s0# of { (# s1#, n# #) -> case newPinnedByteArray# n# s1# of { (# s2#, marr'# #) -> case copyMutableByteArray# mr# 0# marr'# 0# n# s2# of { s3# -> case unsafeFreezeByteArray# marr'# s3# of { (# s4#, arr# #) -> -- must do this case byteArrayContents# arr# of { adr# -> -- to obtain the addr# here let cullp i@(I# i#) sp# = let !p@(I# p#) = i + i + 3 in let !s@(I# s#) = (p * p - 3) `div` 2 in if s >= n then case copyMutableByteArray# marr'# 0# mr# 0# n# sp# of so# -> (# so#, mr# #) else let !(UArray _ _ _ tarr#) = twos in case readWord64Array# marr# (i# `uncheckedIShiftRL#` 6#) sp# of { (# sp0#, v0# #) -> case (v0# `and#` ((int2Word# 1#) `uncheckedShiftL#` (i# `andI#` 63#))) `eqWord#` (int2Word# 0#) of 0# -> cullp (i + 1) sp0# -- not prime _ -> -- is prime -- most program execution time spent in the following tight loops. -- the following code implments extream loop unrolling... let !pi@(I# pi#) = fromIntegral p in let !sw@(I# sw#) = s `shiftR` 3 in let !sb@(I# sb#) = s .&. 7 in let p1 = sb + pi in let !(I# r1#) = p1 `shiftR` 3 in let p2 = p1 + pi in let !(I# r2#) = p2 `shiftR` 3 in let p3 = p2 + pi in let !(I# r3#) = p3 `shiftR` 3 in let p4 = p3 + pi in let !(I# r4#) = p4 `shiftR` 3 in let p5 = p4 + pi in let !(I# r5#) = p5 `shiftR` 3 in let p6 = p5 + pi in let !(I# r6#) = p6 `shiftR` 3 in let p7 = p6 + pi in let !(I# r7#) = p7 `shiftR` 3 in let !lmt@(I# lmt#) = (fromIntegral n `shiftR` 3) - p7 in let !lmt1# = plusAddr# adr# lmt# in let !strt# = plusAddr# adr# sw# in let !(I# n#) = n in let (# !so#, !sco# #) = case ((((p - 1) `div` 2) .&. 3) `shiftL` 3) + sb of { 0 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 1#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 2#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 4#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 8#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 16#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 32#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 64#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 128#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; 1 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 2#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 4#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 8#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 16#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 32#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 64#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 128#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 1#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; -- and so on for 30 more cases... _ -> (# strt#, sp0# #) {- normally never taken case, all cases covered -} } in let !ns# = ((minusAddr# so# adr#) `uncheckedIShiftL#` 3#) +# sb# in -- extreme loop unrolling ends here; remaining primes culled conventionally... let cull j# sc# = -- very tight inner loop case j# <# n# of 0# -> cullp (i + 1) sc# _ -> let i# = j# `andI#` 31# in let !sh# = indexWord32Array# tarr# i# in -- (1 `shiftL` (j .&. 31))) let w# = j# `uncheckedIShiftRL#` 5# in case readWord32Array# marr'# w# sc# of { (# sc0#, ov# #) -> case writeWord32Array# marr'# w# (ov# `or#` sh#) sc0# of { sc1# -> cull (j# +# pi#) sc1# }} in cull ns# sp0# } in case cullp 0 s4# of (# sp#, mrp# #) -> loop (t - 1) mrp# sp# }}}}} in loop numLOOPS marr# s1# } main = print $ length $ soep1() }}} '''The problem:''' The problem is in the innermost loop of the cases, for which case "0" the following assembly code (using -fllvm) is produced: {{{ seGU_info$def: # BB#0: # %cgRL cmpq %r14, 70(%rbx) jbe .LBB35_1 .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax addq %r14, %rax orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) cmpq 70(%rbx), %rax movq %rax, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx rex64 jmpq *%rcx # TAILCALL }}} One can readily see that the compiler is not lifting the Loop Invariant Code Flow as in initializing the registers to outside the inner loop, meaning there are many register loads from memory which are not necessary. '''Desired results:''' The desired assembly code is something like the following, which is similar to what is produced by Cee (C/C++/Rust/etc.): {{{ seGU_info$def: # BB#0: # %cgRL movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax movq 70(%rbx), %rbx cmpq %r14, %rbx # rbx clobbered here, but old value jbe .LBB35_1 # never used again until replaced after loop .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) addq %rax, %r14 cmpq %rbx, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx # rbx clobbered here anyway rex64 jmpq *%rcx # TAILCALL }}} '''Full testing:''' The actual unrolled loop code including all the case loops is too long to post here, but to verify the result is correct (23000) and the performance, the full actual file is attached here. Due to the magic of modern CPU instruction fusion and Out Of Order (OOE) execution, the code is not as slow as it would indicate by the number of increased instructions, but while it is about twice as fast as when culled conventionally (Intel Skylake), it is about half again as slow as Cee. On an Intel Sky Lake i5-6500 (running at 3.5 GHz for single threading), this takes about one second, about two seconds culled conventionally, but only about 0.6 seconds for Rust/LLVM (with the assembly code output essentially identical to the "desired" code). '''Other back ends and targets:''' Although the code generated by the native NCG has other problems (not moving the loop test to the end of the loop to avoid one jump, and not combining the read and modify and store instructions into the single available instruction), it exhibits the same problem as to not lifting the Loop Invariant Code Flow register initialization. Although this code is x86_64, the problem also applies to x86 code even though the x86 architecture doesn't have enough registers to do this in one loop and needs to be split into two loops culling only four composites per loop, but there still is a significant gain in speed. Although not tested, it probably also applies to other targets such as ARM (which has many general purpose registers). '''Conclusion:''' The use of Addr# primitives is probably not a frequent use case, but as shown here that when one needs their use, they should be efficient. I considered that GHC may intentionally limit the performance of these unsafe primitives to limit their use unless absolutely necessary as in marshalling, something as C# does for the use of unsafe pointers, but surely GHC would not do that as the target programmers are different. '''If this and ticket #12798 were fixed, for this use case the GHC code would be within a percent or two of the performance of Cee.''' -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 12:43:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 12:43:02 -0000 Subject: [GHC] #12810: -Wredundant-constraints doesn't factor in associated type families In-Reply-To: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> References: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> Message-ID: <065.4d5560a7bac282021d20d4e129255c86@haskell.org> #12810: -Wredundant-constraints doesn't factor in associated type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with rwbarton in that you do not need the constraint. I think this is just #11369. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 12:48:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 12:48:15 -0000 Subject: [GHC] #12691: Refine the behaviour of -dno-debug-output and -dtrace-level In-Reply-To: <049.ace4deffc6467efccc60320f9ecf71eb@haskell.org> References: <049.ace4deffc6467efccc60320f9ecf71eb@haskell.org> Message-ID: <064.b9fd9e6720f05dfe3e00c8f9c2656c1c@haskell.org> #12691: Refine the behaviour of -dno-debug-output and -dtrace-level -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"1c886eadcfbb593bb06bfff7b8a4914b5349f080/ghc" 1c886ea/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1c886eadcfbb593bb06bfff7b8a4914b5349f080" Stop -dno-debug-output suppressing -ddump-tc-trace Summary: The user manual states that -dno-debug-output should suppress *unsolicited* debugging output which essentially amounts to calls to `pprTrace`. Before I unified the interface of `traceTc` and `traceRn`, the flag suppressed calls to `traceTc` but not to `traceRn` or any other tracing function already controlled by a flag. Thus, in order to make the behaviour more uniform, it seemed best to remove this one special case. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2628 GHC Trac Issues: #12691 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 14:11:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 14:11:10 -0000 Subject: [GHC] #12224: Replace placeHolderPunRhs with a PlaceHolder value In-Reply-To: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> References: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> Message-ID: <059.ef0e5117e75a751ae160cf82379ffc79@haskell.org> #12224: Replace placeHolderPunRhs with a PlaceHolder value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): It seems that to do this I need to have a `Functor` instance for `PostRn id`, which does not seem possible. Any pointers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 14:21:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 14:21:03 -0000 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> Message-ID: <056.c4adf2b305bb943cebeb294b6a4ffbd4@haskell.org> #2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: patch Priority: lowest | Milestone: 8.2.1 Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T2721 Blocked By: | Blocking: Related Tickets: #8165 | Differential Rev(s): Phab:D2636 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"630d88176e8dd3ccc269451bca8f55398ef5265c/ghc" 630d8817/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="630d88176e8dd3ccc269451bca8f55398ef5265c" Allow GeneralizedNewtypeDeriving for classes with associated type families Summary: This implements the ability to derive associated type family instances for newtypes automatically using `GeneralizedNewtypeDeriving`. Refer to the users' guide additions for how this works; I essentially follow the pattern laid out in https://ghc.haskell.org/trac/ghc/ticket/8165#comment:18. Fixes #2721 and #8165. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2636 GHC Trac Issues: #2721, #8165 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 14:21:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 14:21:03 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.1ecff0162ab6868fe6adac2f7bd37023@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: RyanGlScott Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Phab:D2636 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"630d88176e8dd3ccc269451bca8f55398ef5265c/ghc" 630d8817/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="630d88176e8dd3ccc269451bca8f55398ef5265c" Allow GeneralizedNewtypeDeriving for classes with associated type families Summary: This implements the ability to derive associated type family instances for newtypes automatically using `GeneralizedNewtypeDeriving`. Refer to the users' guide additions for how this works; I essentially follow the pattern laid out in https://ghc.haskell.org/trac/ghc/ticket/8165#comment:18. Fixes #2721 and #8165. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2636 GHC Trac Issues: #2721, #8165 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 14:21:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 14:21:23 -0000 Subject: [GHC] #12810: -Wredundant-constraints doesn't factor in associated type families In-Reply-To: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> References: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> Message-ID: <065.36ca085890cd08bbfc6e0f212e73fed1@haskell.org> #12810: -Wredundant-constraints doesn't factor in associated type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #11369 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 14:21:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 14:21:31 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.78510e254a0cfe0d443b9672f8a20611@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another use case for this emerged in #12810. Now that we can use GND for deriving instances of classes with associated type families, it's quite easy to trigger `-Wredundant-constraints` with code like this: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-} class C a where type T a newtype Identity a = Identity a deriving C }}} as it will generate the following instance: {{{#!hs instance C a => C (Identity a) where type T (Identity a) = T a }}} and GHC will emit this warning: {{{ • Redundant constraint: C a • In the instance declaration for ‘C (Identity a)’ }}} Now we have examples where GHC-generated code is producing warnings, which is disconcerting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 14:22:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 14:22:42 -0000 Subject: [GHC] #2721: Newtype deriving doesn't work with type families In-Reply-To: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> References: <041.2b37e78c0fdcc1135c0e600ca8b06d99@haskell.org> Message-ID: <056.f9aab2077244dd3a8fe7a8fefacd6c42@haskell.org> #2721: Newtype deriving doesn't work with type families -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 8.2.1 Component: Compiler (Type | Version: 6.10.1 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_fail/T2721 Blocked By: | Blocking: Related Tickets: #8165 | Differential Rev(s): Phab:D2636 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 14:24:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 14:24:30 -0000 Subject: [GHC] #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families In-Reply-To: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> References: <050.06ad77a65d8c07fe5a5a7d453c7926f4@haskell.org> Message-ID: <065.2255ffa69895f7e7cc8d9821548908b3@haskell.org> #8165: Use GeneralizedNewtypeDeriving to automatically create associated type families -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: RyanGlScott Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T8165, | deriving/should_fail/T8165_fail1, | deriving/should_fail/T8165_fail2 Blocked By: | Blocking: Related Tickets: #2721 | Differential Rev(s): Phab:D2636 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => deriving/should_compile/T8165, deriving/should_fail/T8165_fail1, deriving/should_fail/T8165_fail2 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 14:47:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 14:47:05 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.8154201d24a04ebf7b8941f5f3b7d91c@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"ead83db8a7db772a9f248af9767a4283218a5c9f/ghc" ead83db/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ead83db8a7db772a9f248af9767a4283218a5c9f" Describe symptoms of (and the cure for) #12768 in 8.0.2 release notes GHC 8.0.2 introduced a bugfix involving GeneralizedNewtypeDeriving in 96d451450923a80b043b5314c5eaaa9d0eab7c56. This made typechecking of GND-produced code a bit stricter, and an unfortunate side effect of this was that there were a couple of corner-case programs that stopped compiling when transitioning from GHC 8.0.1 to 8.0.2. Since the number of affected programs seems quite small, and since the fix is so straightforward, we opt to simply note this discrepancy in the 8.0.2 release notes. Resolves #12768. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 14:51:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 14:51:43 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.0af4d2b36cb2ce006df56e5fd4ae74b5@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: After talking with bgamari about this, I've opted to simply note the difference in behavior for this program in the 8.0.2 release notes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 15:15:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 15:15:21 -0000 Subject: [GHC] #12805: Generalise type of asProxyTypeOf In-Reply-To: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> References: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> Message-ID: <066.ef84f3196065afd620289c6f0ee04a1c@haskell.org> #12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've personally no objection to this idea. But I urge you to run this by the [https://mail.haskell.org/mailman/listinfo/libraries Haskell libraries mailing list] first, since proposals to generalize type signatures in `base` have sometimes proven to be controversial :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 15:57:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 15:57:08 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.be4a0d8b176c7e142727645fccceaa9c@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Wow, those constraints are really off! To highlight how bad the behavior was in 8.0.1, even this typechecks! {{{#!hs class (MonadLogger m, MonadIO m) => MonadLoggerIO m where askLoggerIO :: m (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) default askLoggerIO :: (Trans.MonadTrans t) => t m (Loc -> LogSource -> LogLevel -> LogStr -> IO ()) askLoggerIO = Trans.lift askLoggerIO }}} I'll draft up a patch for the 8.0.2 users' guide explaining this difference the a similar vein as ead83db8a7db772a9f248af9767a4283218a5c9f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 16:11:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 16:11:15 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.a5a56eeb90a3b3a63c8e64931d4c2314@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 16:11:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 16:11:55 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.be43b8a4e4a60bd0a06e6a24a26b49d1@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2682 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 16:46:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 16:46:25 -0000 Subject: [GHC] #12224: Replace placeHolderPunRhs with a PlaceHolder value In-Reply-To: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> References: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> Message-ID: <059.d1892d99fb4a52b34583e577e2b77cbb@haskell.org> #12224: Replace placeHolderPunRhs with a PlaceHolder value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): alanz, presumably you're talking this datatype in `HsPat`? {{{#!hs -- For details on above see note [Api annotations] in ApiAnnotation data HsRecField' id arg = HsRecField { hsRecFieldLbl :: Located id, hsRecFieldArg :: arg, -- ^ Filled in by renamer when punning hsRecPun :: Bool -- ^ Note [Punning] } deriving (Data, Functor, Foldable, Traversable) }}} And you want to change `hsRecFieldArg` to be of type `PostRn id arg`? If so, I don't think you'll be able to derive `Functor`, `Foldable`, or `Traversable` anymore, since GHC won't know what code to fill in for the irreducible type family `PostRn id arg`. One possible workaround is to define your `Functor` instances manually: {{{#!hs instance Functor (HsRecField' Id) where fmap f (HsRecField a b c) = HsRecField a (f b) c instance Functor (HsRecField' Name) where fmap _ (HsRecField a b c) = HsRecField a b c instance Functor (HsRecField' RdrName) where fmap _ (HsRecField a b c) = HsRecField a b c }}} and similarly for `Foldable` and `Traversable`. It's not the prettiest solution, but I think it might work for GHC's purposes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 16:53:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 16:53:28 -0000 Subject: [GHC] #12798: LLVM seeming to over optimize, producing inefficient assembly code... In-Reply-To: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> References: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> Message-ID: <065.a38db14ea4452b8e30fc8ef338d5aeff@haskell.org> #12798: LLVM seeming to over optimize, producing inefficient assembly code... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AlexET): On current HEAD with llvm 3.9.0, the follwing code {{{ import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base import Control.Monad.ST numLOOPS = 10000 :: Int twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soe :: () -> [Word32] soe() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfLmt = (256 * 1024) `div` 2 - 1 -- to 2^18 + 2 is 128 KBits - 1 = 16 KBytes cmpstsb <- newArray (0, bfLmt) False :: ST s (STUArray s Int Bool) cmpstsw <- (castSTUArray :: STUArray s Int Bool -> ST s (STUArray s Int Word32)) cmpstsb return $! twos -- force evaluation of twos outside the loop. let loop n = -- cull a number of times to test timing if n <= 0 then return cmpstsb else let cullp i = let p = i + i + 3 in let s = (p * p - 3) `div` 2 in if s > bfLmt then loop (n - 1) else do isCmpst <- unsafeRead cmpstsb i if isCmpst then cullp (i + 1) else -- is Prime let cull j = -- very tight inner loop where all the time is spent if j > bfLmt then cullp (i + 1) else do let sh = unsafeAt twos (j .&. 31) -- (1 `shiftL` (j .&. 31))) let w = j `shiftR` 5 ov <- unsafeRead cmpstsw w unsafeWrite cmpstsw w (ov .|. sh) cull (j + p) in cull s in cullp 0 loop numLOOPS main = print $ length $ soe() }}} Gives the inner loop, which is almost the same as rust. {{{ .LBB28_7: movq %rcx, %rdx sarq $5, %rdx movl %ecx, %edi andl $31, %edi movl 16(%r9,%rdi,4), %edi orl %edi, 16(%rax,%rdx,4) addq %rsi, %rcx .LBB28_5: cmpq $131071, %rcx jle .LBB28_7 }}} The CMM and initial llvm code is the same as your code for 8.0.1, so it seems the difference is due to the fact that rust ships with its own more recent llvm than ghc 8.0.1 supports. The difference in the code between my version and your original version is that we force `twos` early which is needed to prevent the evaluation of that within the loop, an optimisation which seems to have been missed by HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 16:56:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 16:56:51 -0000 Subject: [GHC] #12224: Replace placeHolderPunRhs with a PlaceHolder value In-Reply-To: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> References: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> Message-ID: <059.07765901c658730af2ec85b1bac9899b@haskell.org> #12224: Replace placeHolderPunRhs with a PlaceHolder value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): I tried that, but get {{{ compiler/hsSyn/HsPat.hs:331:57: Couldn't match expected type ‘PostRn id b’ with actual type ‘b’ ‘b’ is a rigid type variable bound by the type signature for fmap :: (a -> b) -> HsRecField' id lbl a -> HsRecField' id lbl b at compiler/hsSyn/HsPat.hs:331:3 Relevant bindings include a :: PostRn id a (bound at compiler/hsSyn/HsPat.hs:331:25) f :: a -> b (bound at compiler/hsSyn/HsPat.hs:331:8) fmap :: (a -> b) -> HsRecField' id lbl a -> HsRecField' id lbl b (bound at compiler/hsSyn/HsPat.hs:331:3) In the second argument of ‘HsRecField’, namely ‘(f a)’ In the expression: HsRecField ln (f a) p }}} I had to bring in an `id` separate from the `lbl` to get the `Data` instances to come out. My interpretation of the error message is that it is impossible to define `fmap` for this type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 16:58:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 16:58:50 -0000 Subject: [GHC] #12224: Replace placeHolderPunRhs with a PlaceHolder value In-Reply-To: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> References: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> Message-ID: <059.cac35a1d2a060d0651d00b7e7b8dce1f@haskell.org> #12224: Replace placeHolderPunRhs with a PlaceHolder value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): alanz, can you show me the diff? From the error message, I'm wondering if you're trying to do something like `instance Functor (HsRecField' id)`, which won't work. You need to instantiate `id` with a concrete type in each `Functor` instance in order to `PostRn id` to reduce enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 17:13:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 17:13:18 -0000 Subject: [GHC] #12224: Replace placeHolderPunRhs with a PlaceHolder value In-Reply-To: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> References: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> Message-ID: <059.826d0a6f8c182655a7bc91ac4486ef51@haskell.org> #12224: Replace placeHolderPunRhs with a PlaceHolder value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): See https://phabricator.haskell.org/D2683 I started doing individual instances, but it broke elsewhere -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 17:13:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 17:13:52 -0000 Subject: [GHC] #12224: Replace placeHolderPunRhs with a PlaceHolder value In-Reply-To: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> References: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> Message-ID: <059.365aa2e280b55c462f5c992fdbb78ae1@haskell.org> #12224: Replace placeHolderPunRhs with a PlaceHolder value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2683 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => D2683 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 18:54:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 18:54:51 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.e4f944ad36a3848da12e65bbacca0858@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The change in behavior is surely a bug fix here. Changes in user-facing behavior between minor versions due to bug fixing are OK. And I agree with Ryan's phrasing in the Phab Diff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 20:18:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 20:18:04 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.fa9f84cffe1c7778e1e4abbad7d222ce@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2684 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 20:18:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 20:18:21 -0000 Subject: [GHC] #12004: Windows unexpected failures In-Reply-To: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> References: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> Message-ID: <060.35cfb97cb386a7d54a6165947fb0c5c3@haskell.org> #12004: Windows unexpected failures ---------------------------------+---------------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * differential: => Phab:D2684 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 20:18:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 20:18:40 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.2531f51dcbd47a383660080934c59267@haskell.org> #12725: T7037 is broken on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2684 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 6 23:43:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 06 Nov 2016 23:43:31 -0000 Subject: [GHC] #12798: LLVM seeming to over optimize, producing inefficient assembly code... In-Reply-To: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> References: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> Message-ID: <065.c147850fe40bb57f8295d80e1e489906@haskell.org> #12798: LLVM seeming to over optimize, producing inefficient assembly code... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by GordonBGood): So you are saying we need to both force the evaluation of "twos" '''and''' run a newer version of LLVM (which we can't do with GHC version 8.0.1) in order to get the desired output but that the forced evaluation of "twos" would not be necessary if HEAD did not have a regression as to this optimization? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 03:53:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 03:53:47 -0000 Subject: [GHC] #12812: Debugging functions should throw warnings Message-ID: <051.eab9c65f72de3691a7e42c099484ab94@haskell.org> #12812: Debugging functions should throw warnings -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The function Debug.Trace.trace is useful for debugging, however, we don't want this function to be present in production code. An excerpt from Debug.Trace explains why: {{{ The 'trace' function should /only/ be used for debugging, or for monitoring execution. The function is not referentially transparent: its type indicates that it is a pure function but it has the side effect of outputting the trace message. }}} It would be useful if the compiler threw warnings when such functions are used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 08:38:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 08:38:04 -0000 Subject: [GHC] #12800: hs_try_putmvar003 sometimes fails In-Reply-To: <046.e1837edaff3493c41289a90d2307655f@haskell.org> References: <046.e1837edaff3493c41289a90d2307655f@haskell.org> Message-ID: <061.85ee9dc5bbc3ef64aea4baa505fbfee6@haskell.org> #12800: hs_try_putmvar003 sometimes fails -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2678 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"91f9e13887f49c28e4dbde4edc2c5c65de44c9e9/ghc" 91f9e13/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="91f9e13887f49c28e4dbde4edc2c5c65de44c9e9" Fix hs_try_putmvar003 (#12800) Summary: There was a race condition on some shared data when creating the callback thread. I couldn't repro the issue without inserting a dummy usleep(100), but it's definitely a bug. Test Plan: validate Reviewers: bgamari, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2678 GHC Trac Issues: #12800 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 08:44:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 08:44:34 -0000 Subject: [GHC] #12800: hs_try_putmvar003 sometimes fails In-Reply-To: <046.e1837edaff3493c41289a90d2307655f@haskell.org> References: <046.e1837edaff3493c41289a90d2307655f@haskell.org> Message-ID: <061.323a6ae92d6c9da0ccb34c755f7550d9@haskell.org> #12800: hs_try_putmvar003 sometimes fails -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2678 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 09:47:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 09:47:58 -0000 Subject: [GHC] #12810: -Wredundant-constraints doesn't factor in associated type families In-Reply-To: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> References: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> Message-ID: <065.5038ade10f306a1b306d378550d59560@haskell.org> #12810: -Wredundant-constraints doesn't factor in associated type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Associated types are completely equivalent to top-level type families. Really the only difference is that you are prompted to provide a type instance at the same time as a class instances; and perhaps that the two "logically belong together". But there is no runtime evidence needed, and hence no class constraint is needed in function definitions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 09:52:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 09:52:01 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.901059cfe2422be3084e916c9ed8b996@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think this is just a bug in the code that infers the context for the instance declaration that arises from GND. We should tet {{{ instance {- Empty context!! -} C (Identity a) where type T (Identity a) = T a }}} Where is that code? I can help with this after the PLDI deadline. Anyway, I think this is unrelated to the original topic of the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 09:54:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 09:54:55 -0000 Subject: [GHC] #12811: GHC tells me to use RankNTypes when it's already enabled In-Reply-To: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> References: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> Message-ID: <065.e996c05af2f5e5d619c5f0d185ba0e14@haskell.org> #12811: GHC tells me to use RankNTypes when it's already enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes indeed. Perhaps someone can arrange to suppress the suggestion if `RankNTypes` is already on? That would help a bit, by removing the confusing suggestion. But it's hard to come up with a good error message for {{{ a b . c d }}} as a type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 13:35:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 13:35:02 -0000 Subject: [GHC] #12805: Generalise type of asProxyTypeOf In-Reply-To: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> References: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> Message-ID: <066.b755659d833039f3b5bec4a1a80189ab@haskell.org> #12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): I've reopened an old discussion on the libraries list here: https://mail.haskell.org/pipermail/libraries/2016-November/027409.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 13:58:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 13:58:13 -0000 Subject: [GHC] #12220: TypeApplications and DefaultSignatures - problems deducing type variables. In-Reply-To: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> References: <047.4c0b684b6c05a7daab4bccbfbe8d15c9@haskell.org> Message-ID: <062.ce37734e64b7f1a5f616901dd974fff1@haskell.org> #12220: TypeApplications and DefaultSignatures - problems deducing type variables. -------------------------------------+------------------------------------- Reporter: mkloczko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | DefaultSignatures, TypeApplications Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | generics/T12220 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"2e8463b232054b788b73e6551947a9434aa76009/ghc" 2e8463b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2e8463b232054b788b73e6551947a9434aa76009" Update 8.0.2 release notes for #12784 Summary: The fix for #12220 exposed some ill-typed programs which passed the typechecker in GHC 8.0.1 but now fail to typecheck in GHC 8.0.2. It's a bit difficult to characterize what exactly triggers this bug, but we at least have a minimal example and a simple fix to illustrate the problem and solution, so let's add that the the 8.0.2 release notes to advertise this change. Resolves #12784. Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2682 GHC Trac Issues: #12784 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 13:58:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 13:58:13 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.2ed543fb996a619156495393ed198068@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"2e8463b232054b788b73e6551947a9434aa76009/ghc" 2e8463b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2e8463b232054b788b73e6551947a9434aa76009" Update 8.0.2 release notes for #12784 Summary: The fix for #12220 exposed some ill-typed programs which passed the typechecker in GHC 8.0.1 but now fail to typecheck in GHC 8.0.2. It's a bit difficult to characterize what exactly triggers this bug, but we at least have a minimal example and a simple fix to illustrate the problem and solution, so let's add that the the 8.0.2 release notes to advertise this change. Resolves #12784. Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2682 GHC Trac Issues: #12784 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 14:00:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 14:00:03 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.d70be0ed8d2046a2f2dc544eeef9bffa@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge Comment: Let's merge this release-notes fix into 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 14:52:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 14:52:21 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.08a7c30fcfbf6367ff843db806093656@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): So roughly: We don't have loop invariant hoisting and we should? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 14:52:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 14:52:44 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.5ff9c3c03e39249e1e17bebd324d6ff9@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Or it's not firing as much as we'd like? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 14:57:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 14:57:41 -0000 Subject: [GHC] #12813: GHC panic when installing haskell-opencv with nix Message-ID: <045.9797c5d0ccdfcd0aa89770429b903f84@haskell.org> #12813: GHC panic when installing haskell-opencv with nix -------------------------------------+------------------------------------- Reporter: turion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I installed https://github.com/LumiGuide/haskell-opencv using their recommended build system "nix", i.e. starting nix-shell in the cloned repository, waiting half an hour for several builds to complete and then doing the following from within the nix-shell: {{{ [nix-shell:~/haskell-opencv]$ cabal build Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Resolving dependencies... [1 of 1] Compiling Main ( dist/setup/setup.hs, dist/setup/Main.o ) Linking ./dist/setup/setup ... Configuring opencv-0.0.0... Building opencv-0.0.0... Preprocessing library opencv-0.0.0... In file included from Types.hsc:96:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from Features2d.hsc:69:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from HighGui.hsc:87:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from ColorMaps.hsc:28:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from Drawing.hsc:52:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from GeometricImgTransform.hsc:81:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from ImgFiltering.hsc:72:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from ObjectDetection.hsc:36:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from StructuralAnalysis.hsc:47:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from Video.hsc:32:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from MotionAnalysis.hsc:44:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from Constants.hsc:9:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from ArrayOps.hsc:19:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from Constants.hsc:9:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from Marshal.hsc:21:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from ImgCodecs.hsc:31:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from MiscImgTransform.hsc:14:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from Types.hsc:18:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from Constants.hsc:9:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ In file included from Constants.hsc:11:0: /nix/store/ybmw9vbx8s8791lc7iggf8yd88kgwmxs-bindings- DSL-1.0.23/lib/ghc-8.0.1/bindings-DSL-1.0.23/include/bindings.dsl.h:191:3: Warnung: »bc_fielddata« definiert, aber nicht verwendet [-Wunused- variable] } bc_fielddata; ^ [ 1 of 70] Compiling OpenCV.Internal.VideoIO.Constants ( dist/build/OpenCV/Internal/VideoIO/Constants.hs, dist/build/OpenCV/Internal/VideoIO/Constants.o ) [ 2 of 70] Compiling OpenCV.Internal.VideoIO.Types ( src/OpenCV/Internal/VideoIO/Types.hs, dist/build/OpenCV/Internal/VideoIO/Types.o ) [ 3 of 70] Compiling OpenCV.VideoIO.Types ( src/OpenCV/VideoIO/Types.hs, dist/build/OpenCV/VideoIO/Types.o ) [ 4 of 70] Compiling OpenCV.Internal.Photo.Constants ( dist/build/OpenCV/Internal/Photo/Constants.hs, dist/build/OpenCV/Internal/Photo/Constants.o ) [ 5 of 70] Compiling OpenCV.Internal.ImgProc.MiscImgTransform ( dist/build/OpenCV/Internal/ImgProc/MiscImgTransform.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform.o ) [ 6 of 70] Compiling OpenCV.Internal.ImgCodecs ( dist/build/OpenCV/Internal/ImgCodecs.hs, dist/build/OpenCV/Internal/ImgCodecs.o ) [ 7 of 70] Compiling OpenCV.Internal.Core.Types.Constants ( dist/build/OpenCV/Internal/Core/Types/Constants.hs, dist/build/OpenCV/Internal/Core/Types/Constants.o ) [ 8 of 70] Compiling OpenCV.Internal.C.PlacementNew ( src/OpenCV/Internal/C/PlacementNew.hs, dist/build/OpenCV/Internal/C/PlacementNew.o ) [ 9 of 70] Compiling OpenCV.Internal.C.PlacementNew.TH ( src/OpenCV/Internal/C/PlacementNew/TH.hs, dist/build/OpenCV/Internal/C/PlacementNew/TH.o ) [10 of 70] Compiling OpenCV.Internal.Mutable ( src/OpenCV/Internal/Mutable.hs, dist/build/OpenCV/Internal/Mutable.o ) [11 of 70] Compiling OpenCV.Internal.Core.ArrayOps ( dist/build/OpenCV/Internal/Core/ArrayOps.hs, dist/build/OpenCV/Internal/Core/ArrayOps.o ) [12 of 70] Compiling OpenCV.Internal ( src/OpenCV/Internal.hs, dist/build/OpenCV/Internal.o ) [13 of 70] Compiling OpenCV.Internal.Calib3d.Constants ( dist/build/OpenCV/Internal/Calib3d/Constants.hs, dist/build/OpenCV/Internal/Calib3d/Constants.o ) [14 of 70] Compiling OpenCV.Internal.C.Types ( src/OpenCV/Internal/C/Types.hs, dist/build/OpenCV/Internal/C/Types.o ) [15 of 70] Compiling OpenCV.Internal.Core.Types.Matx ( src/OpenCV/Internal/Core/Types/Matx.hs, dist/build/OpenCV/Internal/Core/Types/Matx.o ) [16 of 70] Compiling OpenCV.Internal.Core.Types.Matx.TH ( src/OpenCV/Internal/Core/Types/Matx/TH.hs, dist/build/OpenCV/Internal/Core/Types/Matx/TH.o ) [17 of 70] Compiling OpenCV.Internal.Core.Types.Point ( src/OpenCV/Internal/Core/Types/Point.hs, dist/build/OpenCV/Internal/Core/Types/Point.o ) [18 of 70] Compiling OpenCV.Internal.Core.Types.Point.TH ( src/OpenCV/Internal/Core/Types/Point/TH.hs, dist/build/OpenCV/Internal/Core/Types/Point/TH.o ) [19 of 70] Compiling OpenCV.Internal.Core.Types.Size ( src/OpenCV/Internal/Core/Types/Size.hs, dist/build/OpenCV/Internal/Core/Types/Size.o ) [20 of 70] Compiling OpenCV.Internal.Core.Types.Size.TH ( src/OpenCV/Internal/Core/Types/Size/TH.hs, dist/build/OpenCV/Internal/Core/Types/Size/TH.o ) [21 of 70] Compiling OpenCV.Internal.Core.Types.Vec ( src/OpenCV/Internal/Core/Types/Vec.hs, dist/build/OpenCV/Internal/Core/Types/Vec.o ) [22 of 70] Compiling OpenCV.Internal.Core.Types.Vec.TH ( src/OpenCV/Internal/Core/Types/Vec/TH.hs, dist/build/OpenCV/Internal/Core/Types/Vec/TH.o ) [23 of 70] Compiling OpenCV.Internal.C.Inline ( src/OpenCV/Internal/C/Inline.hs, dist/build/OpenCV/Internal/C/Inline.o ) [24 of 70] Compiling OpenCV.Core.Types.Size ( src/OpenCV/Core/Types/Size.hs, dist/build/OpenCV/Core/Types/Size.o ) [25 of 70] Compiling OpenCV.Core.Types.Vec ( src/OpenCV/Core/Types/Vec.hs, dist/build/OpenCV/Core/Types/Vec.o ) [26 of 70] Compiling OpenCV.TypeLevel ( src/OpenCV/TypeLevel.hs, dist/build/OpenCV/TypeLevel.o ) [27 of 70] Compiling OpenCV.Internal.ImgProc.MiscImgTransform.TypeLevel ( src/OpenCV/Internal/ImgProc/MiscImgTransform/TypeLevel.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform/TypeLevel.o ) [28 of 70] Compiling OpenCV.Internal.ImgProc.MiscImgTransform.ColorCodes ( src/OpenCV/Internal/ImgProc/MiscImgTransform/ColorCodes.hs, dist/build/OpenCV/Internal/ImgProc/MiscImgTransform/ColorCodes.o ) [29 of 70] Compiling OpenCV.ImgProc.MiscImgTransform.ColorCodes ( src/OpenCV/ImgProc/MiscImgTransform/ColorCodes.hs, dist/build/OpenCV/ImgProc/MiscImgTransform/ColorCodes.o ) [30 of 70] Compiling OpenCV.Internal.Core.Types.Mat.Depth ( src/OpenCV/Internal/Core/Types/Mat/Depth.hs, dist/build/OpenCV/Internal/Core/Types/Mat/Depth.o ) [31 of 70] Compiling OpenCV.Internal.Exception ( src/OpenCV/Internal/Exception.hs, dist/build/OpenCV/Internal/Exception.o ) [32 of 70] Compiling OpenCV.Exception ( src/OpenCV/Exception.hs, dist/build/OpenCV/Exception.o ) [33 of 70] Compiling OpenCV.Internal.Core.Types.Mat.Marshal ( dist/build/OpenCV/Internal/Core/Types/Mat/Marshal.hs, dist/build/OpenCV/Internal/Core/Types/Mat/Marshal.o ) [34 of 70] Compiling OpenCV.Core.Types.Point ( src/OpenCV/Core/Types/Point.hs, dist/build/OpenCV/Core/Types/Point.o ) [35 of 70] Compiling OpenCV.Internal.Core.Types ( src/OpenCV/Internal/Core/Types.hs, dist/build/OpenCV/Internal/Core/Types.o ) [36 of 70] Compiling OpenCV.Internal.Core.Types.Mat ( src/OpenCV/Internal/Core/Types/Mat.hs, dist/build/OpenCV/Internal/Core/Types/Mat.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1000/ghc26419_0/libghc_275.so: undefined symbol: inline_c_OpenCV_Internal_Exception_1_2402dbf3aea4f7f79392b71ed42618962a22e9aa Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [39 of 70] Compiling OpenCV.Internal.Core.Types.Rect ( src/OpenCV/Internal/Core/Types/Rect.hs, dist/build/OpenCV/Internal/Core/Types/Rect.o ) [40 of 70] Compiling OpenCV.Internal.Core.Types.Rect.TH ( src/OpenCV/Internal/Core/Types/Rect/TH.hs, dist/build/OpenCV/Internal/Core/Types/Rect/TH.o ) [41 of 70] Compiling OpenCV.Core.Types.Rect ( src/OpenCV/Core/Types/Rect.hs, dist/build/OpenCV/Core/Types/Rect.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1000/ghc26419_0/libghc_281.so: undefined symbol: inline_c_OpenCV_Core_Types_Point_19_5c3d561e8841e5271fd465bfb109504b1d56b3f6 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [42 of 70] Compiling OpenCV.Core.Types.Matx ( src/OpenCV/Core/Types/Matx.hs, dist/build/OpenCV/Core/Types/Matx.o ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 15:10:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 15:10:12 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? Message-ID: <050.64605755935b9b77ebba2d41701d372d@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11369, #12810 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a design question that emerged from code that I originally discovered [https://ghc.haskell.org/trac/ghc/ticket/11369#comment:17 here] and [https://ghc.haskell.org/trac/ghc/ticket/12810#comment:3 here]. To recap, it's now possible to have code like this: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-} class C a where type T a newtype Identity a = Identity a deriving C }}} Compiling this (with `-Wredundant-constraints`) generates this code: {{{#!hs instance C a => C (Identity a) where type T (Identity a) = T a }}} But now GHC will complain: {{{ • Redundant constraint: C a • In the instance declaration for ‘C (Identity a)’ }}} This warning makes sense from the perspective that the `C a` constraint isn't ever used by the associated type family instance. So the question arises: should GND avoid generating an instance context for the representation type in the event it's deriving a class with no methods? Fortunately, patching GHC to do this is trivial: {{{#!diff diff --git a/compiler/typecheck/TcDeriv.hs b/compiler/typecheck/TcDeriv.hs index 4722f16..df2d3d5 100644 --- a/compiler/typecheck/TcDeriv.hs +++ b/compiler/typecheck/TcDeriv.hs @@ -1272,7 +1272,8 @@ mkNewTypeEqn dflags overlap_mode tvs [ let (Pair t1 t2) = mkCoerceClassMethEqn cls dfun_tvs inst_tys rep_inst_ty m in mkPredOrigin (DerivOriginCoerce meth t1 t2) TypeLevel (mkReprPrimEqPred t1 t2) - | meth <- classMethods cls ] + | meth <- meths ] + meths = classMethods cls -- If there are no tyvars, there's no need -- to abstract over the dictionaries we need @@ -1281,7 +1282,11 @@ mkNewTypeEqn dflags overlap_mode tvs -- instance C T -- rather than -- instance C Int => C T - all_preds = rep_pred_o : coercible_constraints ++ sc_theta -- NB: rep_pred comes + all_preds = if null meths then [] else [rep_pred_o] + -- See Note [GND and method-free classes] + ++ coercible_constraints + ++ sc_theta + -- NB: rep_pred_o comes first ------------------------------------------------------------------- -- Figuring out whether we can only do this newtype-deriving thing }}} After implementing this patch, I ran the testsuite, and there were some surprising results. One thing that shocked me was that the program reported in #6088, which had previously failed due to a patch resulting from #8984, was now passing! {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE EmptyDataDecls #-} module T6088 where class C a newtype A n = A Int type family Pos n data True instance (Pos n ~ True) => C (A n) newtype B n = B (A n) deriving (C) }}} That is because previously, GHC was trying to generate an instance like this: {{{#!hs instance (Pos n ~ True) => C (B n) }}} And this was rejected, since we don't infer exotic equality constraints when deriving. But with this patch, it now generates: {{{#!hs instance {- Empty context => -} C (B n) }}} Which is certainly valid. But is it what a user would expect? I'm not so sure. As hvr notes in #11369, sometimes empty classes are used to enforce invariants, like in the following case: {{{#!hs class Throws e readFoo :: Throws IOError => FilePath -> IO Foo readFoo fn = {- ... -} }}} What if you wanted to have a `Throws` instance for a newtype? You'd probably want something like this: {{{#!hs newtype Id a = MkId a instance Throws a => Throws (Id a) }}} Which feels like something GND should be able to take care of with ease. But to your surprise, you try this: {{{#!hs newtype Id a = MkId a deriving Throws }}} And now GHC generates not the instance above, but rather just: {{{#!hs instance Throws (Identity a) }}} So it's possible that we would lose some of the expressiveness of GND by implementing this change. Is that acceptable? I'm not sure, so I though I'd solicit feedback here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 15:11:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 15:11:01 -0000 Subject: [GHC] #11369: Suppress redundant-constraint warnings in case of empty classes In-Reply-To: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> References: <042.737377bf025e0f1e9e16df66e2da43c7@haskell.org> Message-ID: <057.397220bf79243ea5799db3e5fd15347a@haskell.org> #11369: Suppress redundant-constraint warnings in case of empty classes -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): simonpj, I've opened #12814 to discuss the design you propose in comment:18. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 15:11:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 15:11:33 -0000 Subject: [GHC] #12810: -Wredundant-constraints doesn't factor in associated type families In-Reply-To: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> References: <050.ebddd25b47b24c145a4b05c02a3000e7@haskell.org> Message-ID: <065.d00b45189cc788f215ecc00455a30e55@haskell.org> #12810: -Wredundant-constraints doesn't factor in associated type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've opened #12814 to discuss the matter of comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 15:20:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 15:20:20 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.ac7d9210ce5cc09ae3ac40abe40c5585@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire, simonpj (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 15:32:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 15:32:30 -0000 Subject: [GHC] #12805: Generalise type of asProxyTypeOf In-Reply-To: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> References: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> Message-ID: <066.21adabe0ecb4a521c1da30f057eac9db@haskell.org> #12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, I had no idea that this had already been discussed on the mailing list before! You should have mentioned that - given the positive response from the earlier discussion (and the more current discussion on the mailing list), I don't see any reason why we shouldn't incorporate this change into `base`. Care to submit a patch on Phabricator? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 16:16:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 16:16:37 -0000 Subject: [GHC] #12763: Incorrect behavior with empty functional dependencies In-Reply-To: <047.270f76781eaf61ddb7db1183cbaa2fe1@haskell.org> References: <047.270f76781eaf61ddb7db1183cbaa2fe1@haskell.org> Message-ID: <062.90d605b8555a42405888a4a2b0fba569@haskell.org> #12763: Incorrect behavior with empty functional dependencies -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T12763 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 16:17:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 16:17:03 -0000 Subject: [GHC] #12797: Default Rules stop working when providing some constraints In-Reply-To: <046.3e265c62039d77b084607215464a4e41@haskell.org> References: <046.3e265c62039d77b084607215464a4e41@haskell.org> Message-ID: <061.6b2ef3b3a4580664a038758d7cc0f74d@haskell.org> #12797: Default Rules stop working when providing some constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12797 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 19:49:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 19:49:18 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.14292b6d3c57960f3a6e7634a815cf9e@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: upstream => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 2722cd55431452ad7fc7fcae030b1587086dec8f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 19:49:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 19:49:40 -0000 Subject: [GHC] #12738: GHC drops -optl flags In-Reply-To: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> References: <046.9b4a8719e9f8fd3d2e249278a0534514@haskell.org> Message-ID: <061.5e9d26aa9df00a0beac24e2ad678c5e5@haskell.org> #12738: GHC drops -optl flags -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 5c91d076c8017a89ceb43811506b9427ab85ad7e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 19:50:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 19:50:06 -0000 Subject: [GHC] #12746: Assertion failed with BuildFlavour = devel2 (one more) In-Reply-To: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> References: <044.436300eb2fa6d28a25bfdcb0e6018fe1@haskell.org> Message-ID: <059.abf3a069a7c1809c59bbb7f175bca78b@haskell.org> #12746: Assertion failed with BuildFlavour = devel2 (one more) -------------------------------------+------------------------------------- Reporter: pacak | Owner: mpickering Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2624 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as c33aad1e77bdfa929f52cefa8ebf7c5917b60405. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 20:25:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 20:25:07 -0000 Subject: [GHC] #12728: setnumcapabilities001 sometimes fails on Windows In-Reply-To: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> References: <046.bd3dd62a15658c520271ab8ea8feebfd@haskell.org> Message-ID: <061.7de0e0ff2bf5af6e9cdbfe957ba19541@haskell.org> #12728: setnumcapabilities001 sometimes fails on Windows -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2617 Wiki Page: | -----------------------------------+-------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as 2722cd55431452ad7fc7fcae030b1587086dec8f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 21:35:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 21:35:13 -0000 Subject: [GHC] #12630: Assertion failed with BuildFlavour = devel2 In-Reply-To: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> References: <044.44de7d164e3ac2cb54d44ca44fcb1f68@haskell.org> Message-ID: <059.03ed36b345c2045812e67b1721d36edc@haskell.org> #12630: Assertion failed with BuildFlavour = devel2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:5 merged to `ghc-8.0` as cc3a9504f638fe14fd6532c3b616343a2ee947dd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 22:02:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 22:02:06 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.a5bc336f3a077cde8e55a477c94140b7@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Frankly, I was surprised that GND assumes any class constraint at all. Why should it be different than other forms of `deriving`? Just infer the class constraint based on the constraints that arise when type-checking the generated definition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 7 22:18:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 07 Nov 2016 22:18:44 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.5e890e140462cd038a2cb0fd97808699@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 goldfire]: > Frankly, I was surprised that GND assumes any class constraint at all. Why should it be different than other forms of `deriving`? Just infer the class constraint based on the constraints that arise when type-checking the generated definition. I'm not sure how the thing you're imagining is different from what actually happens. GND must infer a constraint (applied to the representation type for the newtype) in order to typecheck any calls to `coerce` that GND generates. This is quite similar to stock deriving. For example, in: {{{#!hs data Foo a b = Foo b deriving Show }}} You must infer `Show b` in order to typecheck the generated `showsPrec` function. The only difference in this scenario is that there are no stock derivable classes without methods, but with GND, such a thing is possible. So it's quite a different beast. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 01:33:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 01:33:58 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.ecb7bdf35fa2e7626417d7ee7a506b95@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by GordonBGood): Yes, we don't have loop invariant hoisting (at least for Addr#) and we should, or it's not firing as we'd like. The c-- (cmm) code starts like this: {{{ cull_seCS_entry() // [R2, R1] { info_tbl: [(cgKv, label: cull_seCS_info rep:HeapRep 9 nonptrs { Fun {arity: 2 fun_type: ArgSpec 4} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset cgKv: _seCT::I64 = R2; _seCS::P64 = R1; goto cgKo; cgKo: if ((old + 0) - < SpLim) goto cgKw; else goto cgKx; cgKw: R2 = _seCT::I64; R1 = _seCS::P64; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; cgKx: goto cgKn; cgKn: _seBQ::I64 = I64[_seCS::P64 + 6]; _seCD::I64 = I64[_seCS::P64 + 14]; _seCF::I64 = I64[_seCS::P64 + 22]; _seCH::I64 = I64[_seCS::P64 + 30]; _seCJ::I64 = I64[_seCS::P64 + 38]; _seCL::I64 = I64[_seCS::P64 + 46]; _seCN::I64 = I64[_seCS::P64 + 54]; _seCP::I64 = I64[_seCS::P64 + 62]; _seCQ::I64 = I64[_seCS::P64 + 70]; _cgKq::I64 = _seCT::I64 < _seCQ::I64; _seCV::I64 = _cgKq::I64; switch [-9223372036854775808 .. 9223372036854775807] _seCV::I64 { case 0 : goto cgKu; default: goto cgKt; } cgKu: goto cgKF; cgKF: R1 = _seCT::I64; call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; cgKt: goto cgKA; cgKA: _seCY::I64 = %MO_UU_Conv_W8_W64(I8[_seCT::I64]); _seCY::I64 = _seCY::I64; _cgKI::I64 = _seCY::I64 | 1; _seCZ::I64 = _cgKI::I64; I8[_seCT::I64] = %MO_UU_Conv_W64_W8(_seCZ::I64); _seD3::I64 = %MO_UU_Conv_W8_W64(I8[_seCT::I64 + (_seCD::I64 << 0)]); _seD3::I64 = _seD3::I64; _cgKN::I64 = _seD3::I64 | 2; _seD4::I64 = _cgKN::I64; I8[_seCT::I64 + (_seCD::I64 << 0)] = %MO_UU_Conv_W64_W8(_seD4::I64); _seD8::I64 = %MO_UU_Conv_W8_W64(I8[_seCT::I64 + (_seCF::I64 << 0)]); _seD8::I64 = _seD8::I64; _cgKS::I64 = _seD8::I64 | 4; _seD9::I64 = _cgKS::I64; I8[_seCT::I64 + (_seCF::I64 << 0)] = %MO_UU_Conv_W64_W8(_seD9::I64); _seDd::I64 = %MO_UU_Conv_W8_W64(I8[_seCT::I64 + (_seCH::I64 << 0)]); _seDd::I64 = _seDd::I64; _cgKX::I64 = _seDd::I64 | 8; _seDe::I64 = _cgKX::I64; I8[_seCT::I64 + (_seCH::I64 << 0)] = %MO_UU_Conv_W64_W8(_seDe::I64); _seDi::I64 = %MO_UU_Conv_W8_W64(I8[_seCT::I64 + (_seCJ::I64 << 0)]); _seDi::I64 = _seDi::I64; _cgL2::I64 = _seDi::I64 | 16; _seDj::I64 = _cgL2::I64; I8[_seCT::I64 + (_seCJ::I64 << 0)] = %MO_UU_Conv_W64_W8(_seDj::I64); _seDn::I64 = %MO_UU_Conv_W8_W64(I8[_seCT::I64 + (_seCL::I64 << 0)]); _seDn::I64 = _seDn::I64; _cgL7::I64 = _seDn::I64 | 32; _seDo::I64 = _cgL7::I64; I8[_seCT::I64 + (_seCL::I64 << 0)] = %MO_UU_Conv_W64_W8(_seDo::I64); _seDs::I64 = %MO_UU_Conv_W8_W64(I8[_seCT::I64 + (_seCN::I64 << 0)]); _seDs::I64 = _seDs::I64; _cgLc::I64 = _seDs::I64 | 64; _seDt::I64 = _cgLc::I64; I8[_seCT::I64 + (_seCN::I64 << 0)] = %MO_UU_Conv_W64_W8(_seDt::I64); _seDx::I64 = %MO_UU_Conv_W8_W64(I8[_seCT::I64 + (_seCP::I64 << 0)]); _seDx::I64 = _seDx::I64; _cgLh::I64 = _seDx::I64 | 128; _seDy::I64 = _cgLh::I64; I8[_seCT::I64 + (_seCP::I64 << 0)] = %MO_UU_Conv_W64_W8(_seDy::I64); _cgLm::I64 = _seCT::I64 + _seBQ::I64; _seDA::I64 = _cgLm::I64; _seCT::I64 = _seDA::I64; goto cgKn; } }, }}} with the register initializations outside the loops as I originally wrote it and ends up after many steps of optimizations with the initializations inside the loops as follows: {{{ cull_seCS_entry() // [R1, R2] { [(cgKv, cull_seCS_info: const 8589934596; const 38654705664; const 9;)] } {offset cgKv: _seCT::I64 = R2; _seCS::P64 = R1; goto cgKn; cgKn: switch [-9223372036854775808 .. 9223372036854775807] (_seCT::I64 < I64[_seCS::P64 + 70]) { case 0 : goto cgKu; default: goto cgKt; } cgKu: R1 = _seCT::I64; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; cgKt: _seBQ::I64 = I64[_seCS::P64 + 6]; _seCD::I64 = I64[_seCS::P64 + 14]; _seCF::I64 = I64[_seCS::P64 + 22]; _seCH::I64 = I64[_seCS::P64 + 30]; _seCJ::I64 = I64[_seCS::P64 + 38]; _seCL::I64 = I64[_seCS::P64 + 46]; _seCN::I64 = I64[_seCS::P64 + 54]; _seCP::I64 = I64[_seCS::P64 + 62]; I8[_seCT::I64] = %MO_UU_Conv_W64_W8(%MO_UU_Conv_W8_W64(I8[_seCT::I64]) | 1); I8[_seCT::I64 + _seCD::I64] = %MO_UU_Conv_W64_W8(%MO_UU_Conv_W8_W64(I8[_seCT::I64 + _seCD::I64]) | 2); I8[_seCT::I64 + _seCF::I64] = %MO_UU_Conv_W64_W8(%MO_UU_Conv_W8_W64(I8[_seCT::I64 + _seCF::I64]) | 4); I8[_seCT::I64 + _seCH::I64] = %MO_UU_Conv_W64_W8(%MO_UU_Conv_W8_W64(I8[_seCT::I64 + _seCH::I64]) | 8); I8[_seCT::I64 + _seCJ::I64] = %MO_UU_Conv_W64_W8(%MO_UU_Conv_W8_W64(I8[_seCT::I64 + _seCJ::I64]) | 16); I8[_seCT::I64 + _seCL::I64] = %MO_UU_Conv_W64_W8(%MO_UU_Conv_W8_W64(I8[_seCT::I64 + _seCL::I64]) | 32); I8[_seCT::I64 + _seCN::I64] = %MO_UU_Conv_W64_W8(%MO_UU_Conv_W8_W64(I8[_seCT::I64 + _seCN::I64]) | 64); I8[_seCT::I64 + _seCP::I64] = %MO_UU_Conv_W64_W8(%MO_UU_Conv_W8_W64(I8[_seCT::I64 + _seCP::I64]) | 128); _seCT::I64 = _seCT::I64 + _seBQ::I64; goto cgKn; } } }}} The movement of the register initialization to inside the loops seems to happen at a very early stage (as when it is recognized that these are pointer/addr# operations) and never gets fixed... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 06:25:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 06:25:59 -0000 Subject: [GHC] #12815: ghc: panic Loading temp shared object failed Message-ID: <048.4317bf9ad361be52d7f76d33ae01aa5f@haskell.org> #12815: ghc: panic Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: brodyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: osx | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I ran 'stack upgrade' and after downloading, configuring, building and registering all 178 required packages I got this: {{{ [1 of 1] Compiling Main ( /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack- upgrade11535/stack-1.2.0/Setup.hs, /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack- upgrade11535/stack-1.2.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack- upgrade11535/stack-1.2.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ... Configuring stack-1.2.0... stack-1.2.0: build Preprocessing library stack-1.2.0... [ 1 of 96] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 96] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 3 of 96] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 4 of 96] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o ) [ 5 of 96] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 6 of 96] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o ) [ 7 of 96] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 8 of 96] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 9 of 96] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/ghc29794_0/libghc_55.dylib, 5): no suitable image found. Did find: /var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/ghc29794_0/libghc_55.dylib: malformed mach-o: load commands size (47248) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 178 action(s). -- While building package stack-1.2.0 using: /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack- upgrade11535/stack-1.2.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 06:49:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 06:49:55 -0000 Subject: [GHC] #12815: ghc: panic Loading temp shared object failed In-Reply-To: <048.4317bf9ad361be52d7f76d33ae01aa5f@haskell.org> References: <048.4317bf9ad361be52d7f76d33ae01aa5f@haskell.org> Message-ID: <063.81ce7f2609e9743ef053ce0292283c7b@haskell.org> #12815: ghc: panic Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: brodyberg | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: osx Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: See #12479. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 09:05:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 09:05:31 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.c22ea9744ea0416eede7bb1e310780fc@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): As I understand it, these movements could not sensibly be hoisted at the Core level, or could they? I'm failing to see how the code at the top lines up with the Cmm you are showing. Maybe show STG code too, and say how they match up? If we can do the floating in Core, that would be better! If the opportunity only gets exposed when we are in Cmm, I wonder if it's worth our doing this in Cmm, or whether it's best left to LLVM? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 09:29:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 09:29:12 -0000 Subject: [GHC] #12816: Link error with GOLD linker Message-ID: <045.624e6d1d1f17d355af2801ec56e977b0@haskell.org> #12816: Link error with GOLD linker -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.1 (Linking) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 1. I think we should add "pthread" to the list of extra-libs in "rts/package.conf.in" for the threaded RTS on UNIX-like host OSes. 2. we should include MachDeps.h in "rts/package.conf.in" Current master branch (2e8463b232054b788b73e6551947a9434aa76009) build is broken on my system[0]. When ghc-stage1 tries to produce ghc-stage2, I get: {{{ /home/hsyl20/repo/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161107.so: error: undefined reference to 'pthread_create' /home/hsyl20/repo/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161107.so: error: undefined reference to 'pthread_detach }}} (logs: http://pastebin.com/EbqEx6Gg ) I have tracked down the regression to the following recent commit: a977c96537bb7077c6445f02db98636b150e6e14 If I revert this commit, it builds. However I think this commit has only revealed the bug: if I add "pthread" to the list of extra-libs in "rts/package.conf.in", it builds too. We already add it on freebsd and openbsd but not on Linux. I think I have finally found out why other devs on #ghc haven't noticed this bug: my system uses the GOLD linker (because of #12748), but if I switch back to the BFD linker, it builds without error. While investigating this bug, I have noticed that linker flags for 64-bit atomic ops introduced by https://git.haskell.org/ghc.git/commitdiff/c06e3f46d24ef69f3a3d794f5f604cb8c2a40cbc aren't set while they should: WORD_SIZE_IN_BITS isn't defined because we don't include MachDeps.h [0] x86-64, ArchLinux (Linux 4.8.6), GNU gold (GNU Binutils 2.27) 1.12, gcc (GCC) 6.2.1 20160830 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 10:07:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 10:07:39 -0000 Subject: [GHC] #12748: BFD linker issue with GHCi In-Reply-To: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> References: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> Message-ID: <060.ba08dbbc1081a9d8551221154e46c8c6@haskell.org> #12748: BFD linker issue with GHCi -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: Resolution: | bfd,linker,ghci Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: Can you give it a spin on ghc-HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 10:07:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 10:07:40 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.054ed6e5eb41b867c0b680f1f970ceef@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:2 goldfire]: > Just infer the class constraint based on the constraints that arise when type-checking the generated definition. I agree with this; and it's precisely what Ryan's patch does. `mkNewTypeEqn` generates the constraints that are necessary to satisfy the instance decl; they are then simplified, perhaps to nothing at all. We are going to generate {{{ instance ?? => C (N a) where ...type instances... op = coerce (op :: rep-ty) }}} So for each method (if any) we need * `C rep_ty` so that we have the underlying `op` * `op_ty[rep_ty] ~R op_ty[N a]` to for the coercion of the `op` If there are no methods we don't need any of those constraints. Ryan's notes above show that the result may perhaps not be what you want, but if not, just use a standalone deriving and specify the instance context. So I vote for this patch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 10:41:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 10:41:19 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.02313feecb1c2061cac9d5e3e385f891@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjcjoosten): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 12:41:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 12:41:37 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.18978272341a3f627e76b6eaabde30f7@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thank you for the small test case. I can see what is happening here. After `SpecConstr`, and occurrence analysis we get {{{ Rec { $slast_s_s1J5 :: forall a_a1BZ. a_a1BZ -> Slist a_a1BZ -> Eq a_a1BZ => a_a1BZ $slast_s_s1J5 = \ (@ a_a1BZ) (sc_s1J0 :: a_a1BZ) (sc_s1J1 :: Slist a_a1BZ) (sc_s1IZ :: Eq a_a1BZ) -> case sc_s1J1 of wild_Xp [Dmd=] { Nil_s -> sc_s1J0; Cons_s _ [Occ=Dead] _ [Occ=Dead] -> let { sc_s1J1 [Occ=Once] :: Slist a_a1BZ [LclId] sc_s1J1 = wild_Xp } in last_s @ a_a1BZ sc_s1IZ sc_s1J1 } last_s [Occ=LoopBreaker] :: forall a_a1kp. Eq a_a1kp => Slist a_a1kp -> a_a1kp [RULES: "SC:last_s0" [ALWAYS] forall (@ a_a1BZ) (sc_s1J0 :: a_a1BZ) (sc_s1J1 :: Slist a_a1BZ) (sc_s1IZ :: Eq a_a1BZ). last_s @ a_a1BZ sc_s1IZ (Cons_s @ a_a1BZ sc_s1J0 sc_s1J1) = $slast_s_s1J5 @ a_a1BZ sc_s1J0 sc_s1J1 sc_s1IZ] last_s = \ (@ a_a1BC) ($dEq_a1BE :: Eq a_a1BC) (ds_d1Do [Occ=Once!] :: Slist a_a1BC) -> case ds_d1Do of { Nil_s -> lvl_s1Fa @ a_a1BC; Cons_s x_a1kB [Occ=Once] xs_a1kC [Occ=Once!, Dmd=] -> case xs_a1kC of { Nil_s -> x_a1kB; Cons_s a1_a1zd [Occ=Once] a2_a1ze [Occ=Once] -> $slast_s_s1J5 @ a_a1BC a1_a1zd a2_a1ze $dEq_a1BE } } end Rec } }}} Then in `last_s`: * `$s_last_s_s1J5` is inlined * The RULE fires, yielding a new cal to `$s_last_s_s1J5` * `$s_last_s_s1J5` is inlined again * and so on. The problem is that `$s_last_s_s1J5` should be a loop breaker. See the extensive notes under `Note [Choosing loop breakers]`. But alas in `occAnalRec` we see this {{{ pairs :: [(Id,CoreExpr)] pairs | isEmptyVarSet weak_fvs = reOrderNodes 0 bndr_set weak_fvs tagged_nodes [] | otherwise = loopBreakNodes 0 bndr_set weak_fvs loop_breaker_edges [] }}} We want to go via the `loopBreakNodes` call, but actually `weak_fvs` is empty so we go via the former call. I'm not yet sure exactly why... just recording breadcrumbs for now. How urgent is this for you, Stef? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 12:54:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 12:54:57 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.d52926604c4f023fd58b19955ab2f72c@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjcjoosten): We have several work-arounds for now: using an old GHC version, turning off optimisations, and using other code without this behavior, so I'm fine right now. From your analysis, I should be able to come up with a no- inline pragma too. I only raised the priority to increase the visibility: didn't want this to go unnoticed before the next release, so thank you for taking a look at it! Regards, Sebastiaan (PS: Stef is my dad) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 15:28:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 15:28:30 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.ecfb7cd23797a33d99e3d59f6a8111d5@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ilovezfs): Here's another instance in the wild that just got released: https://github.com/purescript/purescript/issues/2421. {{{ src/Control/Monad/Supply/Class.hs:30:10: error: • Couldn't match type ‘m’ with ‘StateT s m’ ‘m’ is a rigid type variable bound by the instance declaration at src/Control/Monad/Supply/Class.hs:30:10 Expected type: StateT s m Integer Actual type: StateT s (StateT s m) Integer etc. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 15:33:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 15:33:23 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.e47b1db3e364f9c7a5fc3a4d935e087e@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): And the relevant code (excerpted from https://github.com/purescript/purescript/blob/master/src/Control/Monad/Supply/Class.hs): {{{#!hs class Monad m => MonadSupply m where fresh :: m Integer peek :: m Integer default fresh :: MonadTrans t => t m Integer fresh = lift fresh default peek :: MonadTrans t => t m Integer peek = lift peek instance MonadSupply m => MonadSupply (StateT s m) instance (Monoid w, MonadSupply m) => MonadSupply (WriterT w m) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 15:48:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 15:48:29 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.5c5580683337efbadb7efe1f0f656082@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I suppose so. But it would also seem possible to skip figuring out, a priori, what constraints should be there. Can't we just type-check the generated code and then posit whatever constraints are necessary for that code to be accepted? That's what we do for `stock` instances, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 15:53:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 15:53:03 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.87445a5c7cdee11a33a3ac99ecfc4c37@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:5 goldfire]: > Can't we just type-check the generated code and then posit whatever constraints are necessary for that code to be accepted? That's what we do for `stock` instances, no? Currently, no. The code for this is [http://git.haskell.org/ghc.git/blob/2e8463b232054b788b73e6551947a9434aa76009:/compiler/typecheck/TcDerivInfer.hs#l46 inferConstraints] in `TcDerivInfer`. For stock deriving, it walks over each field of each constructor for a datatype, puts the class constraint on the field's type, and then simplifies. So `data Foo a b = Foo a Int deriving Show` becomes `(Show a, Show Int)` becomes `Show a`. As for why this is done this way, I'm not sure, but I do know that GHC figures out the instance context //before// ever generating the class method implementations (possibly for typechecking purposes). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 16:03:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 16:03:45 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.88066ee6e073ba028674c0b8dd7a018f@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I suppose I knew that, when I think about it. But why don't we do it the other way? (This is an honest question -- not just trying to be a gadfly.) It seems easier and more robust. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 17:37:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 17:37:36 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.c79bc0b733166189cbfc366ee41bbdac@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The rationale is this. * For 'deriving' clauses we need to figure out what the context of the derived instance declaration should be. * What we ''actually'' do is this: we gather together all the constraints that ''will'' be required, and simplify them to make a minimal instance context. * We could instead (a) generate the method bindings etc, (b) typecheck them, (c) figuring out the constraints that are needed to do so, and minimise them (d) turn all that into an instance decl (e) typecheck the instance decl with all its methods. But typechecking instance decls is already fairly complicated and (a-c) sounds tricky to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 19:05:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 19:05:05 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.08ebd4c1a1184bd01520b7b232f710a7@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm happy with Ryan's patch, too. But I'm still think my new approach would be simpler than the existing one. (a) is already done. That's !TcGenDeriv. (b) is already done: `tcInstDcls` (or similar) (c) will be the set of unsolved wanted constraints left over after solving. These will have to be checked for exoticness, but that's it! (d) is simply taking the result of (c) and sticking it in the instance decl. There is a matter that (c) outputs `Type` and (d) will want `HsContext` -- but I think we already have a way of squirreling a `Type` inside of an `HsType`, so this shouldn't be bad. (e) would be necessary, and it would be repeated work. So this new approach is probably slower than the existing one. In exchange, we get to delete the first several hundred lines of !TcDerivInfer (`inferConstraints`). In any case, if it's not broken, perhaps we shouldn't fix it. I just find that special-casing the 0-method case to be a bit odd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 19:26:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 19:26:05 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.c8b9f68132f6dc5647e586945b95f58f@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I am sure you understand this better than I do, but what happens in a case involving non-regular recursion (e.g. deriving `Eq` for `data X a = A a | B (X (a, a))`)? I argued for the same approach in the setting of `DeriveAnyClass`, and was disappointed that instead a heuristic was adopted that has no reason to be correct in general, so I think something is a bit "broken" here, in the sense of your last paragraph. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 20:15:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 20:15:49 -0000 Subject: [GHC] #12805: Generalise type of asProxyTypeOf In-Reply-To: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> References: <051.2d11ec8997c4cfcd1e323f954845c195@haskell.org> Message-ID: <066.1fc55fb955c3e91d99f253bc18d677cb@haskell.org> #12805: Generalise type of asProxyTypeOf -------------------------------------+------------------------------------- Reporter: tomjaguarpaw | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tomjaguarpaw): > Care to submit a patch on Phabricator? In principle I can, but I'm rather disinclined to learn the whole GHC contributor system just to flip a single bit in the source code. I'd appreciate it if someone more experienced would do it, otherwise it will have to wait until I have a lot of free time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 20:27:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 20:27:13 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.c665148237bced3c866137e424544288@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by GordonBGood): Replying to [comment:6 simonpj]: > I'm failing to see how the code at the top lines up with the Cmm you are showing. @simonpj, the cmm code shown is the first of the "cull" case loops from the Haskell GHC code. The bottom "optimized" version has had the register initialization dropped down into inside the loop. > Maybe show STG code too, and say how they match up? If we can do the floating in Core, that would be better! Here is the STG code for the same cull loop/recursive function, massively back tabbed for display purposes here (output of -ddump-stg from GHC version 8.0.1 on 64-bit Windows, lines 898 through 1132): {{{ let { cull_seCS [Occ=LoopBreaker] :: GHC.Prim.Addr# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.Addr#, GHC.Prim.State# GHC.Prim.RealWorld #) [LclId, Arity=2, Str=DmdType , Unf=OtherCon []] = sat-only \r srt:SRT:[] [c#_seCT sp#_seCU] case ltAddr# [c#_seCT lmt1#_seCQ] of _ [Occ=Dead] { __DEFAULT -> case readWord8OffAddr# [c#_seCT 0# sp#_seCU] of _ [Occ=Dead] { (#,#) ipv8_seCX [Occ=Once] ipv9_seCY [Occ=Once] -> case or# [ipv9_seCY 1##] of sat_seCZ { __DEFAULT -> case writeWord8OffAddr# [c#_seCT 0# sat_seCZ ipv8_seCX] of sp1#_seD0 [OS=OneShot] { __DEFAULT -> case readWord8OffAddr# [c#_seCT r1#_seCD sp1#_seD0] of _ [Occ=Dead] { (#,#) ipv10_seD2 [Occ=Once] ipv11_seD3 [Occ=Once] -> case or# [ipv11_seD3 2##] of sat_seD4 { __DEFAULT -> case writeWord8OffAddr# [c#_seCT r1#_seCD sat_seD4 ipv10_seD2] of sp3#_seD5 [OS=OneShot] { __DEFAULT -> case readWord8OffAddr# [c#_seCT r2#_seCF sp3#_seD5] of _ [Occ=Dead] { (#,#) ipv12_seD7 [Occ=Once] ipv13_seD8 [Occ=Once] -> case or# [ipv13_seD8 4##] of sat_seD9 { __DEFAULT -> case writeWord8OffAddr# [c#_seCT r2#_seCF sat_seD9 ipv12_seD7] of sp5#_seDa [OS=OneShot] { __DEFAULT -> case readWord8OffAddr# [c#_seCT r3#_seCH sp5#_seDa] of _ [Occ=Dead] { (#,#) ipv14_seDc [Occ=Once] ipv15_seDd [Occ=Once] -> case or# [ipv15_seDd 8##] of sat_seDe { __DEFAULT -> case writeWord8OffAddr# [c#_seCT r3#_seCH sat_seDe ipv14_seDc] of sp7#_seDf [OS=OneShot] { __DEFAULT -> case readWord8OffAddr# [c#_seCT r4#_seCJ sp7#_seDf] of _ [Occ=Dead] { (#,#) ipv16_seDh [Occ=Once] ipv17_seDi [Occ=Once] -> case or# [ipv17_seDi 16##] of sat_seDj { __DEFAULT -> case writeWord8OffAddr# [c#_seCT r4#_seCJ sat_seDj ipv16_seDh] of sp9#_seDk [OS=OneShot] { __DEFAULT -> case readWord8OffAddr# [c#_seCT r5#_seCL sp9#_seDk] of _ [Occ=Dead] { (#,#) ipv18_seDm [Occ=Once] ipv19_seDn [Occ=Once] -> case or# [ipv19_seDn 32##] of sat_seDo { __DEFAULT -> case writeWord8OffAddr# [c#_seCT r5#_seCL sat_seDo ipv18_seDm] of sp11#_seDp [OS=OneShot] { __DEFAULT -> case readWord8OffAddr# [c#_seCT r6#_seCN sp11#_seDp] of _ [Occ=Dead] { (#,#) ipv20_seDr [Occ=Once] ipv21_seDs [Occ=Once] -> case or# [ipv21_seDs 64##] of sat_seDt { __DEFAULT -> case writeWord8OffAddr# [c#_seCT r6#_seCN sat_seDt ipv20_seDr] of sp13#_seDu [OS=OneShot] { __DEFAULT -> case readWord8OffAddr# [c#_seCT r7#_seCP sp13#_seDu] of _ [Occ=Dead] { (#,#) ipv22_seDw [Occ=Once] ipv23_seDx [Occ=Once] -> case or# [ipv23_seDx 128##] of sat_seDy { __DEFAULT -> case writeWord8OffAddr# [c#_seCT r7#_seCP sat_seDy ipv22_seDw] of sp15#_seDz [OS=OneShot] { __DEFAULT -> case plusAddr# [c#_seCT p#_seBQ] of sat_seDA { __DEFAULT -> cull_seCS sat_seDA sp15#_seDz; }; }; }; }; }; }; }; }; }; }; }; }; }; }; }; }; }; }; }; }; }; }; }; }; }; 0# -> (#,#) [c#_seCT sp#_seCU]; }; } in }}} You can see that the STG code just reflects the original Haskell source code and that the faulty register initialization has not yet been dropped down to within the loop(s), so the problem is not here. The problem is in the CMM optimization pass, thus it also applies to NCG (although of course NCG also has other problems). The easiest way to fix this might be to turn on the appropriate LLVM loop invariant code flow optimizations (if they would work) and have it only apply to LLVM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 20:34:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 20:34:03 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.36bdd6a63e30ce990b7356c3bd2967e8@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's really not simple... one instance may need other instances, so we need to solved simultaneous equations; see `Note [Simplifying the instance context]` in `TcDerivInfer`. Also we aren't really special-casing the 0-method case. For each method we need 1. `C rep-ty (same for each method) 2. A coercible constraint (different for each method) Instead of generating N copies of (1) we generate just 1. But if N=0 we can generate zero of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 20:39:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 20:39:14 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.9341b35b72863f2345b4b95ef4443900@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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Updating https://github.com/alanz/ghc-exactprint/blob/no- annotations/tests/Test/NoAnnotations.hs#L119 to be {{{#!hs let !printed = pragmaStr ++ "\n" ++ (showSDoc_ $ GHC.ppr parsedOrig) }}} i.e. to simply `ppr` the `ParsedSource` and compare the resulting re- parsed AST. The initial results are for ghc-8.0.1, of the 823 test cases in ghc- exactprint, the straight GHC ppr fails to roundtrip 106 where it cannot be reparsed, and another 84 where the re-parsed AST does not match the original. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 20:48:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 20:48:29 -0000 Subject: [GHC] #12748: BFD linker issue with GHCi In-Reply-To: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> References: <045.9df6c99d0f17d6a514ad3639e393c6df@haskell.org> Message-ID: <060.8f0eb545b8c63b02255b86dc053c4b99@haskell.org> #12748: BFD linker issue with GHCi -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: Resolution: fixed | bfd,linker,ghci Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => closed * resolution: => fixed Comment: @slyfox I can't reproduce with ghc-8.0 branch (cc3a9504f638fe14fd6532c3b616343a2ee947dd) and the BFD linker. I close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 21:17:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 21:17:38 -0000 Subject: [GHC] #12817: Degraded performance with constraint synonyms Message-ID: <047.617960d55e862f6bf01a754dec8e8040@haskell.org> #12817: Degraded performance with constraint synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The attached bug demonstrates how using constraint synonyms can negatively impact performance. I have two functions which are identical, except that one uses a constraint synonym: {{{ type CElt r = (Num r, Eq r) fooSlow :: (CElt r) => Bar r -> Bar r {-# INLINABLE fooSlow #-} fooSlow (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar . eitherFoo) u fooSlow (C2 c) = C2 $ fooSlow c fooFast :: (Num r, Eq r) => Bar r -> Bar r {-# INLINABLE fooFast #-} fooFast (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar . eitherFoo) u fooFast (C2 c) = C2 $ fooFast c }}} Using criterion, `fooSlow` is about 3x slower than `fooFast`. Main.hs needs `criterion` and `deepseq`, but the problem should be evident just from inspecting the core of Bar.hs, which only relies on `base`. Code was compiled with GHC-8.0.1 with `-O2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 21:18:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 21:18:16 -0000 Subject: [GHC] #12817: Degraded performance with constraint synonyms In-Reply-To: <047.617960d55e862f6bf01a754dec8e8040@haskell.org> References: <047.617960d55e862f6bf01a754dec8e8040@haskell.org> Message-ID: <062.058ef289d956a3fa987185479eb3f253@haskell.org> #12817: Degraded performance with constraint synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * Attachment "csynbug.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 21:28:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 21:28:34 -0000 Subject: [GHC] #12817: Degraded performance with constraint synonyms In-Reply-To: <047.617960d55e862f6bf01a754dec8e8040@haskell.org> References: <047.617960d55e862f6bf01a754dec8e8040@haskell.org> Message-ID: <062.10f0ad81a51cc3b09186815aa43f5507@haskell.org> #12817: Degraded performance with constraint synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 8 22:35:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 08 Nov 2016 22:35:52 -0000 Subject: [GHC] #12817: Degraded performance with constraint synonyms In-Reply-To: <047.617960d55e862f6bf01a754dec8e8040@haskell.org> References: <047.617960d55e862f6bf01a754dec8e8040@haskell.org> Message-ID: <062.b4dc30e5a26075808644d81098e430bf@haskell.org> #12817: Degraded performance with constraint synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by crockeea: @@ -27,0 +27,4 @@ + + For some context, in my real code from which this example was extracted, + the 'fast' (no constraint synonym) version takes 78 microseconds, while + the 'slow' version with the synonym takes 360 microseconds. New description: The attached bug demonstrates how using constraint synonyms can negatively impact performance. I have two functions which are identical, except that one uses a constraint synonym: {{{ type CElt r = (Num r, Eq r) fooSlow :: (CElt r) => Bar r -> Bar r {-# INLINABLE fooSlow #-} fooSlow (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar . eitherFoo) u fooSlow (C2 c) = C2 $ fooSlow c fooFast :: (Num r, Eq r) => Bar r -> Bar r {-# INLINABLE fooFast #-} fooFast (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar . eitherFoo) u fooFast (C2 c) = C2 $ fooFast c }}} Using criterion, `fooSlow` is about 3x slower than `fooFast`. Main.hs needs `criterion` and `deepseq`, but the problem should be evident just from inspecting the core of Bar.hs, which only relies on `base`. Code was compiled with GHC-8.0.1 with `-O2`. For some context, in my real code from which this example was extracted, the 'fast' (no constraint synonym) version takes 78 microseconds, while the 'slow' version with the synonym takes 360 microseconds. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 9 13:52:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Nov 2016 13:52:04 -0000 Subject: [GHC] #12818: Allow reify to find top-level bindings in later declaration groups Message-ID: <056.f19e742bf3d69968df87513dc7491856@haskell.org> #12818: Allow reify to find top-level bindings in later declaration groups -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D2519 | Wiki Page: -------------------------------------+------------------------------------- Some time ago, at Tweag we were considering inspecting the types of declarations added with `addTopDecls` like this: {{{ {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH.Syntax main :: IO () main = $(do ds <- [d| f = True |] addTopDecls ds addModFinalizer $ do VarI _ t _ <- reify (mkName "f") runIO $ hPutStrLn stderr ("f :: " ++ show t) [| return () |] ) }}} `f` is not in scope when the finalizer is added. But its type would be known when the finalizer runs. This worked before the patch https://phabricator.haskell.org/D2286. There is a patch that we submitted to address this https://phabricator.haskell.org/D2519, but it turned out later that we didn't need it and the patch was considered less than ideal. We are opening this ticket to keep track of the nuance in case someone finds the patch useful later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 9 13:53:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Nov 2016 13:53:16 -0000 Subject: [GHC] #12818: Allow reify to find top-level bindings in later declaration groups In-Reply-To: <056.f19e742bf3d69968df87513dc7491856@haskell.org> References: <056.f19e742bf3d69968df87513dc7491856@haskell.org> Message-ID: <071.a81f66d8595357d82014c80f0dde432b@haskell.org> #12818: Allow reify to find top-level bindings in later declaration groups -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11832 | Differential Rev(s): Phab:D2519 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * related: => #11832 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 9 23:12:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 09 Nov 2016 23:12:01 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.7170cedf731e7ecbf2693552b3254033@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:5 simonpj]: > GHC's constraint solver uses the "given" constraint (here `Num Int` via a superclass of `C Int b`) where possible. You may say "If there is an instance declaration, use that instead of the given constraint. But no > {{{ > f :: Ord [a] => ... > f x = ..Need Eq [a]... > }}} If we didn't have overlapping instances, could we reduce the `Ord [a]` constraint to `Ord a` when checking the signature (changing the semantics of `FlexibleContexts` a bit)? That would open up a different path to `Eq [a]`. Or do these constraints sometimes arise in situations where they can't be (or shouldn't be) reduced? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 01:30:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 01:30:09 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.4585415e8f6feb6c5db7a7ccafad2178@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alkar): Hi, as a developer on 48-core machine, I upvote the issue. I can reproduce it with many programs, e.g. this trivial one: {{{ #!bash $ cat x.hs main = getContents >>= print . length $ ghc -O2 -rtsopts -threaded x $ time head -c10MB /dev/zero | ./x 10000000 real 0m0.182s user 0m0.180s sys 0m0.012s $ time head -c10MB /dev/zero | ./x +RTS -N 10000000 real 0m1.782s user 0m45.183s sys 0m10.305s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 08:49:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 08:49:19 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.765bf87c3ab9d4ec82b46908a9b19f8c@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Replying to [comment:30 alkar]: > Hi, as a developer on 48-core machine, I upvote the issue. I can reproduce it with many programs, e.g. this trivial one: > > > {{{ > #!bash > $ cat x.hs > main = getContents >>= print . length > $ ghc -O2 -rtsopts -threaded x > $ time head -c10MB /dev/zero | ./x > 10000000 > > real 0m0.182s > user 0m0.180s > sys 0m0.012s > $ time head -c10MB /dev/zero | ./x +RTS -N > 10000000 > > real 0m1.782s > user 0m45.183s > sys 0m10.305s > }}} > > The problem can be tamed with -A option (somewhere around 200M is optimal in my case), but still it's pretty bad: > > {{{ > #!bash > $ time head -c10MB /dev/zero | ./x +RTS -N -A200M > 10000000 > > real 0m0.712s > user 0m1.144s > sys 0m0.412s > }}} Can you share a bit more info on your setup? - GHC version you tried it on - where does '''+RTS -s''' claim to attribute the time to - '''lstopo-no-graphics''' output - '''numactl''' -H output A few tweaks happened in #9221 since latest GHC-8.0.1 release. It has a few more knobs to tune like '''-qn''' (number of GC threads), '''-n''' (nursery chunks), '''-qb0''' (work-stealing nursery scan mode). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 11:12:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 11:12:57 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.94e4032db49975e42941b6a0ca7fa775@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alkar): * Attachment "numactl.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 11:13:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 11:13:38 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.448aa719758c9d014cae3256483f7351@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alkar): * Attachment "lstopo.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 11:15:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 11:15:42 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.e0fe5cabddcf13b0a9fe3c1e51bd0a3a@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alkar): In previous post I used ghc-7.10.1 by mistake. With 8.0.1 (`stack ghc -- -O2 -rtsopts -threaded x`) single core performance is same (around `0.18s`), but with `+RTS -N` I get better results: {{{ real 0m0.843s user 0m22.149s sys 0m2.256s }}} Even better with `-A200M`: {{{ real 0m0.793s user 0m1.200s sys 0m0.692s }}} {{{ $ head -c10MB /dev/zero | ./x +RTS -s -N > /dev/null 406,012,416 bytes allocated in the heap 30,457,408 bytes copied during GC 674,776 bytes maximum residency (2 sample(s)) 665,248 bytes maximum slop 27 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 775 colls, 775 par 16.945s 0.429s 0.0006s 0.0302s Gen 1 2 colls, 1 par 0.052s 0.002s 0.0012s 0.0013s Parallel GC work balance: 0.14% (serial 0%, perfect 100%) TASKS: 98 (1 bound, 97 peak workers (97 total), using -N48) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 2.660s ( 0.091s elapsed) MUT time 11.065s ( 0.744s elapsed) GC time 16.997s ( 0.432s elapsed) EXIT time 0.028s ( 0.003s elapsed) Total time 30.750s ( 1.270s elapsed) Alloc rate 36,694,519 bytes per MUT second Productivity 36.1% of total user, 873.3% of total elapsed gc_alloc_block_sync: 38774 whitehole_spin: 0 gen[0].sync: 408 gen[1].sync: 130 }}} I attached outputs of `lstopo` (I don't have -no-graphics variant there) and `numactl -H`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 15:55:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 15:55:32 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.232f1f8ade2707ffe03bff0e6cd43ff6@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In reply to comment:31 > Hi, as a developer on 48-core machine, I upvote the issue. I can reproduce it with many programs, e.g. this trivial one: It is far from clear to me that we should expect the program you cited to run well with `-N`. It allocates heavily and `-N` will use parallel GC on a heavily imbalanced heap. Looking at the eventlog confirms that nearly all of the cores are simply waiting for GC. As expected disabling parallel GC with `+RTS -qg` drastically reduces system time due to reduced synchronization overhead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 16:03:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 16:03:52 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.eb5f77021b6a6a48f6b5a071c82bfbb0@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7fe71636dc14a219c26def5cac2da9fa20689540/ghc" 7fe7163/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7fe71636dc14a219c26def5cac2da9fa20689540" Adapt the (commented out) pprTrace in OccurAnal I did this while investigating Trac #12776 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 16:03:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 16:03:52 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.aea7f9d897e5176940ec5dfe9115f81c@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f05d685ae05ec293083f2fa7ec7ba057fbe64869/ghc" f05d685a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f05d685ae05ec293083f2fa7ec7ba057fbe64869" Refactoring of mkNewTypeEqn The refactoring here is very small. I did it while studying Trac #12814. To implement the change in #12814, we can just un-comment the lines at line 1275. It's ready to go but I didn't want to pull the trigger in this commit }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 16:05:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 16:05:02 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.a6cde842220d6ad983f5c73a04eecca5@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => RyanGlScott Comment: Ryan, I suggest you pull the trigger on this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 17:11:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 17:11:27 -0000 Subject: [GHC] #12819: Pattern synonym signatures are not validity-checked Message-ID: <047.ea2438d0a734e559e510fecf46b09b65@haskell.org> #12819: Pattern synonym signatures are not validity-checked -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ponder this garbage: {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns, TypeFamilies, KindSignatures #-} module Bug where type family F a -- F :: * -> * data T :: (* -> *) -> * pattern Q :: T F -> String pattern Q x <- (undefined -> x) }}} This is accepted by GHC 8.0.1 and HEAD. But it has an unsaturated type family! Urk! The problem is that `TcSigs.tcPatSynSig` never does validity checking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 17:18:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 17:18:49 -0000 Subject: [GHC] #12820: Regression around pattern synonyms and higher-rank types Message-ID: <047.8ff9e83595f6e43eb23a94e0b79eda39@haskell.org> #12820: Regression around pattern synonyms and higher-rank types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0.1 accepts, but HEAD rejects: {{{#!hs {-# LANGUAGE PatternSynonyms, RankNTypes, ViewPatterns #-} module Bug where pattern P :: (forall a. a -> a) -> String pattern P x <- (\ _ -> id -> x) }}} (Sidenote: kudos to the parser on figuring out my view pattern.) HEAD gives this error: {{{ Bug.hs:6:30: error: • Couldn't match expected type ‘forall a. a -> a’ with actual type ‘a0 -> a0’ • In the declaration for pattern synonym ‘P’ • Relevant bindings include x :: a0 -> a0 (bound at Bug.hs:6:30) }}} The code looks correct to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 17:19:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 17:19:19 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.94298484f5158c4e2b7d2ab25d59abdd@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Phab:D2692 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2692 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 18:16:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 18:16:10 -0000 Subject: [GHC] #12817: Degraded performance with constraint synonyms In-Reply-To: <047.617960d55e862f6bf01a754dec8e8040@haskell.org> References: <047.617960d55e862f6bf01a754dec8e8040@haskell.org> Message-ID: <062.c31fb25c7f7a6f1390101629544e0550@haskell.org> #12817: Degraded performance with constraint synonyms -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 18:50:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 18:50:46 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.9ba47b6e46f82300e5750618d0ecc9a6@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"bae4a55b1fb403f610b4b55a1b6fb3f03e9c2026/ghc" bae4a55b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bae4a55b1fb403f610b4b55a1b6fb3f03e9c2026" Pass -no-pie to GCC Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be default in their GCC packaging. This breaks our abuse of GCC as a linker which requires that we pass -Wl,-r, which is incompatible with PIE (since the former implies that we are generating a relocatable object file and the latter an executable). Test Plan: Validate Reviewers: hvr, austin Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D2691 GHC Trac Issues: #12759 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 20:57:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 20:57:55 -0000 Subject: [GHC] #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together In-Reply-To: <050.2889198c2b0542acc8ba72db59faa9d7@haskell.org> References: <050.2889198c2b0542acc8ba72db59faa9d7@haskell.org> Message-ID: <065.e3fd65f3b387ff7967ea8236c8eb097c@haskell.org> #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together -------------------------------------+------------------------------------- Reporter: SamuelMarks | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Build System | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #12759 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #12759 * milestone: => 8.0.2 Comment: The problem here is that we pass `-Wl,-r` to `gcc` when joining object files and linking libraries. This is incompatible with the implicit `-pie` which the affected gcc versions assume. It turns out that GCC 6 has a `-r` flag which we could use in place of `-Wl,-r` and would do the right thing. Unfortunately it is undocumented so I'm rather reluctant to depend upon it. Really I suspect the correct solution here is to simply use `ld` directly for everything except for the final link (since linking an executable will likely require linking against `libgcc`). However, this is out of scope for 8.0.2. Consequently, I think the next best solution is to simply ensure we pass `-no-pie` to `gcc` when we do not intend on linking an executable. I have done exactly this in Phab:D2691 which has been merged to `master` (bae4a55b1fb403f610b4b55a1b6fb3f03e9c2026) and `ghc-8.0` (). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 21:03:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 21:03:29 -0000 Subject: [GHC] #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together In-Reply-To: <050.2889198c2b0542acc8ba72db59faa9d7@haskell.org> References: <050.2889198c2b0542acc8ba72db59faa9d7@haskell.org> Message-ID: <065.e26b33e14bc948c8023667231345a51d@haskell.org> #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together -------------------------------------+------------------------------------- Reporter: SamuelMarks | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Build System | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #12759 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): What is the plan for binary releases regarding this change? Seeing as the decision about whether to pass `-no-pie` is made at build time, will there be a version available for those whose gcc is too old to support it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 21:22:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 21:22:51 -0000 Subject: [GHC] #12821: Find the incredible vanishing [The improvement story] Message-ID: <046.8f1c0172fb0349cdea42e58509937ad2@haskell.org> #12821: Find the incredible vanishing [The improvement story] -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Somehow we lost Note [The improvement story] in `TcInteract`. There are references to it in `TcInteract` and `TcRnTypes` but the note itself is nowhere to be found. Someone must find it before it reaches the county border! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 21:29:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 21:29:17 -0000 Subject: [GHC] #12821: Find the incredible vanishing [The improvement story] In-Reply-To: <046.8f1c0172fb0349cdea42e58509937ad2@haskell.org> References: <046.8f1c0172fb0349cdea42e58509937ad2@haskell.org> Message-ID: <061.3c6c4a6ab5284377bbb19f947933d1a2@haskell.org> #12821: Find the incredible vanishing [The improvement story] -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It looks like ddbb97d00fdbc5870a4076ed15af8e607b161cb2 is the culprit. Simon, do you think you can clean up the remaining references? Also, it looks like the original note nicely described the goal of improvement and had some useful examples for newcomers. It's not clear that any of the notes that replaced it are quite so approachable to newcomers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 21:29:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 21:29:34 -0000 Subject: [GHC] #12821: Find the incredible vanishing [The improvement story] In-Reply-To: <046.8f1c0172fb0349cdea42e58509937ad2@haskell.org> References: <046.8f1c0172fb0349cdea42e58509937ad2@haskell.org> Message-ID: <061.60ed3b427b6e1d6d67498d3ce1ba1959@haskell.org> #12821: Find the incredible vanishing [The improvement story] -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonpj (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 10 22:20:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 10 Nov 2016 22:20:11 -0000 Subject: [GHC] #12822: Cleanup GHC verbosity flags Message-ID: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> #12822: Cleanup GHC verbosity flags -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple newcomer,flags | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 1) In the discussion of Phab:D2679#77898, Simon Marlow suggested that we make verbosity levels (`-v0`, `-v1`...) work just like optimization levels (`-O0`, `-O1`...), i.e., that we make each verbosity level a collection of verbosity flags. Currently the verbosity level is tested against explicitly in several places in GHC's code. 2) Homogenize verbosity flags: currently, flags that change GHC's reporting have various prefixes: - `-fprint-*` - `-fshow-*` - `-dshow-passes` - `-ddump-*` - `-dppr-*` - `-dverbose-*` Maybe we should homogenize (some of) them by using a common `-v` prefix as in `-vshow-source-paths`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 00:06:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 00:06:26 -0000 Subject: [GHC] #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together In-Reply-To: <050.2889198c2b0542acc8ba72db59faa9d7@haskell.org> References: <050.2889198c2b0542acc8ba72db59faa9d7@haskell.org> Message-ID: <065.3469c823b102fc9d0f0ca60b57e3cf8d@haskell.org> #12755: Build from source fails on Ubuntu 16.10: ld: -r and -pie may not be used together -------------------------------------+------------------------------------- Reporter: SamuelMarks | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Build System | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #12759 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > What is the plan for binary releases regarding this change? Seeing as the decision about whether to pass -no-pie is made at build time, will there be a version available for those whose gcc is too old to support it? Oh dear, right. I suppose this will need to be placed in `settings`. Thanks for pointing that out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 01:52:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 01:52:41 -0000 Subject: [GHC] #12823: Inconsistency in acceptance of equality constraints in different forms Message-ID: <045.17e2d45fdb42780e0f8c0a412e457d55@haskell.org> #12823: Inconsistency in acceptance of equality constraints in different forms -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: GADTs | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, we (correctly) require a language extension to accept a declaration like foo :: a ~ b => f a -> f b foo x = x Suppose I write {{{#!hs {-# LANGUAGE GADTs, UndecidableInstances, ConstraintKinds #-} module A where class a ~ b => Equal a b instance a ~ b => Equal a b type EqualS a b = a ~ b }}} and then {{{#!hs -- No extensions module B where -- This works useEqual :: Equal a b => f a -> f b useEqual x = x -- But this does not useEqualF :: EqualF a b => f a -> f b useEqualF x = x }}} It seems that GHC expands type synonyms, but does not reduce constraints, before deciding whether enough extensions are in play to allow equality constraints. This mismatch feels weird. Is there something about `~` proper, and not `Equal`, that triggers the difficulties with let generalization? If not, I think they should either both work or both fail (probably both fail). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 03:09:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 03:09:19 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.b9d5253522e8b77dcfddbd71d58a745f@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by GordonBGood: @@ -9,1 +9,1 @@ - speed even further as per the method described for "primesieve as per + speed even further as per the method described for "primesieve" as per New description: '''Background:''' I've been intrigued investigating whether GHC can produce code "as fast as Cee (C/C++/Rust/etc.)" by-any-means-possible, and have been using the very tight inner composite culling loops (purely integer operations) of a basic Sieve of Eratosthenes implementation as a test vehicle. '''Synopsis:''' This is a follow-on of the work leading to finding the efficiency problem described in ticket #12798, but involves pushing the speed even further as per the method described for "primesieve" as per [http://primesieve.org/] in the "Highly optimized inner loop" section. '''Description of test code:''' Essentially, this method involves extreme loop unrolling with very imperative code although coded functionally; in the case of the following code it means that, recognizing that for all odd primes (which they all are other than two), and that all word sizes are of an even number of bits, there will be a repeating pattern of composite number culls that repeats every word size number of bits. Thus for a word size of one eight-bit byte, we can unroll to eight composite culls in the body of one loop, with loops cases for the primes modulo 8 of 1, 3, 5, and 7, and for the eight bit start positions (b0..b7) meaning there are four times eight is 32 loop cases. When there are no longer a full eight culls left, the culling reverts to conventional single-cull-per-loop as per the test program of ticket #12798. To do this using GHC we need pointer arithmetic, and the only way to implement pointer arithmetic in GHC is to use the Addr# primitive. GHC/Haskell has one other slight overhead over Cee languages in that we need to move the culling array to a pinned array to avoid having it moved while the culling is going on and then move it back when finished but this takes a negligible amount of time (one percent or so) as compared to the culling. As usual for test programs, the culling operations are repeated in a loop for a number of times to give more accurate timing not influenced by execution not related to the culling. All of this is included in the following code (truncated as to loop coses for inclusion here): {{{#!hs -- EfficiencyBug.hs -- showing that there is a register loop invariant bug in generation of assembler code... -- LLVM shows the bug clearer since the code is generally a little faster... {-# LANGUAGE FlexibleContexts, BangPatterns, MagicHash, UnboxedTuples #-} {-# OPTIONS_GHC -O2 -rtsopts -keep-s-files #-} -- or -O2 -fllvm import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base import GHC.ST ( ST(..) ) import GHC.Exts numLOOPS = 10000 :: Int -- Uses a very simple Sieve of Eratosthenes for fixed 2 ^ 18 range (so one L1 cache size) to prove it. twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soep1 :: () -> [Word32] soep1() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfBts = (256 * 1024) `div` 2 -- to 2^18 + 2 is 128 KBits = 16 KBytes bf <- newArray (0, bfBts - 1) False :: ST s (STUArray s Int Bool) cullb bf cullb bf@(STUArray l u n marr#) = ST $ \s0# -> case getSizeofMutableByteArray# marr# s0# of { (# s1#, n# #) -> let loop t mr# s0# = -- cull a number of times to test timing if t <= 0 then (# s0#, STUArray l u n mr# #) else case getSizeofMutableByteArray# mr# s0# of { (# s1#, n# #) -> case newPinnedByteArray# n# s1# of { (# s2#, marr'# #) -> case copyMutableByteArray# mr# 0# marr'# 0# n# s2# of { s3# -> case unsafeFreezeByteArray# marr'# s3# of { (# s4#, arr# #) -> -- must do this case byteArrayContents# arr# of { adr# -> -- to obtain the addr# here let cullp i@(I# i#) sp# = let !p@(I# p#) = i + i + 3 in let !s@(I# s#) = (p * p - 3) `div` 2 in if s >= n then case copyMutableByteArray# marr'# 0# mr# 0# n# sp# of so# -> (# so#, mr# #) else let !(UArray _ _ _ tarr#) = twos in case readWord64Array# marr# (i# `uncheckedIShiftRL#` 6#) sp# of { (# sp0#, v0# #) -> case (v0# `and#` ((int2Word# 1#) `uncheckedShiftL#` (i# `andI#` 63#))) `eqWord#` (int2Word# 0#) of 0# -> cullp (i + 1) sp0# -- not prime _ -> -- is prime -- most program execution time spent in the following tight loops. -- the following code implments extream loop unrolling... let !pi@(I# pi#) = fromIntegral p in let !sw@(I# sw#) = s `shiftR` 3 in let !sb@(I# sb#) = s .&. 7 in let p1 = sb + pi in let !(I# r1#) = p1 `shiftR` 3 in let p2 = p1 + pi in let !(I# r2#) = p2 `shiftR` 3 in let p3 = p2 + pi in let !(I# r3#) = p3 `shiftR` 3 in let p4 = p3 + pi in let !(I# r4#) = p4 `shiftR` 3 in let p5 = p4 + pi in let !(I# r5#) = p5 `shiftR` 3 in let p6 = p5 + pi in let !(I# r6#) = p6 `shiftR` 3 in let p7 = p6 + pi in let !(I# r7#) = p7 `shiftR` 3 in let !lmt@(I# lmt#) = (fromIntegral n `shiftR` 3) - p7 in let !lmt1# = plusAddr# adr# lmt# in let !strt# = plusAddr# adr# sw# in let !(I# n#) = n in let (# !so#, !sco# #) = case ((((p - 1) `div` 2) .&. 3) `shiftL` 3) + sb of { 0 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 1#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 2#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 4#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 8#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 16#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 32#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 64#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 128#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; 1 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 2#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 4#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 8#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 16#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 32#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 64#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 128#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 1#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; -- and so on for 30 more cases... _ -> (# strt#, sp0# #) {- normally never taken case, all cases covered -} } in let !ns# = ((minusAddr# so# adr#) `uncheckedIShiftL#` 3#) +# sb# in -- extreme loop unrolling ends here; remaining primes culled conventionally... let cull j# sc# = -- very tight inner loop case j# <# n# of 0# -> cullp (i + 1) sc# _ -> let i# = j# `andI#` 31# in let !sh# = indexWord32Array# tarr# i# in -- (1 `shiftL` (j .&. 31))) let w# = j# `uncheckedIShiftRL#` 5# in case readWord32Array# marr'# w# sc# of { (# sc0#, ov# #) -> case writeWord32Array# marr'# w# (ov# `or#` sh#) sc0# of { sc1# -> cull (j# +# pi#) sc1# }} in cull ns# sp0# } in case cullp 0 s4# of (# sp#, mrp# #) -> loop (t - 1) mrp# sp# }}}}} in loop numLOOPS marr# s1# } main = print $ length $ soep1() }}} '''The problem:''' The problem is in the innermost loop of the cases, for which case "0" the following assembly code (using -fllvm) is produced: {{{ seGU_info$def: # BB#0: # %cgRL cmpq %r14, 70(%rbx) jbe .LBB35_1 .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax addq %r14, %rax orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) cmpq 70(%rbx), %rax movq %rax, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx rex64 jmpq *%rcx # TAILCALL }}} One can readily see that the compiler is not lifting the Loop Invariant Code Flow as in initializing the registers to outside the inner loop, meaning there are many register loads from memory which are not necessary. '''Desired results:''' The desired assembly code is something like the following, which is similar to what is produced by Cee (C/C++/Rust/etc.): {{{ seGU_info$def: # BB#0: # %cgRL movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax movq 70(%rbx), %rbx cmpq %r14, %rbx # rbx clobbered here, but old value jbe .LBB35_1 # never used again until replaced after loop .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) addq %rax, %r14 cmpq %rbx, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx # rbx clobbered here anyway rex64 jmpq *%rcx # TAILCALL }}} '''Full testing:''' The actual unrolled loop code including all the case loops is too long to post here, but to verify the result is correct (23000) and the performance, the full actual file is attached here. Due to the magic of modern CPU instruction fusion and Out Of Order (OOE) execution, the code is not as slow as it would indicate by the number of increased instructions, but while it is about twice as fast as when culled conventionally (Intel Skylake), it is about half again as slow as Cee. On an Intel Sky Lake i5-6500 (running at 3.5 GHz for single threading), this takes about one second, about two seconds culled conventionally, but only about 0.6 seconds for Rust/LLVM (with the assembly code output essentially identical to the "desired" code). '''Other back ends and targets:''' Although the code generated by the native NCG has other problems (not moving the loop test to the end of the loop to avoid one jump, and not combining the read and modify and store instructions into the single available instruction), it exhibits the same problem as to not lifting the Loop Invariant Code Flow register initialization. Although this code is x86_64, the problem also applies to x86 code even though the x86 architecture doesn't have enough registers to do this in one loop and needs to be split into two loops culling only four composites per loop, but there still is a significant gain in speed. Although not tested, it probably also applies to other targets such as ARM (which has many general purpose registers). '''Conclusion:''' The use of Addr# primitives is probably not a frequent use case, but as shown here that when one needs their use, they should be efficient. I considered that GHC may intentionally limit the performance of these unsafe primitives to limit their use unless absolutely necessary as in marshalling, something as C# does for the use of unsafe pointers, but surely GHC would not do that as the target programmers are different. '''If this and ticket #12798 were fixed, for this use case the GHC code would be within a percent or two of the performance of Cee.''' -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 03:15:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 03:15:31 -0000 Subject: [GHC] #12823: Inconsistency in acceptance of equality constraints in different forms In-Reply-To: <045.17e2d45fdb42780e0f8c0a412e457d55@haskell.org> References: <045.17e2d45fdb42780e0f8c0a412e457d55@haskell.org> Message-ID: <060.efcfc79a5f003e069f3fd66f528b2ec0@haskell.org> #12823: Inconsistency in acceptance of equality constraints in different forms -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I assume `EqualF` should be `EqualS`. As long as we're allowing the full application of a multiparameter type class in a module with no extensions in the first place (strictly speaking, it should be a syntax error in Haskell 2010), I see no purpose in rejecting either of your functions in module `B`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 03:18:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 03:18:20 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.685c1fb923054cfaa51e7a06525e10d9@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by rwbarton): Note that this is still open because of ticket:12755#comment:4, I guess (`-no-pie` setting should be configurable via settings file). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 04:14:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 04:14:30 -0000 Subject: [GHC] #12823: Inconsistency in acceptance of equality constraints in different forms In-Reply-To: <045.17e2d45fdb42780e0f8c0a412e457d55@haskell.org> References: <045.17e2d45fdb42780e0f8c0a412e457d55@haskell.org> Message-ID: <060.063b22fe05e38a60931594987a10b56a@haskell.org> #12823: Inconsistency in acceptance of equality constraints in different forms -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 rwbarton]: > I assume `EqualF` should be `EqualS`. Indeed. > As long as we're allowing the full application of a multiparameter type class in a module with no extensions in the first place (strictly speaking, it should be a syntax error in Haskell 2010), I see no purpose in rejecting either of your functions in module `B`. My concern: `GADTs` implies `MonoLocalBinds` because (for reasons I don't personally understand) GADTs don't play well with let generalization. Since the `Equal` class and `ExistentialQuantification` are sufficient to simulate GADTs, I would expect them to run into the same inference fragility issues without `MonoLocalBinds`. Am I missing something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 04:50:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 04:50:41 -0000 Subject: [GHC] #12764: Be able to pin a thread to a numa node without fixing a capabiity In-Reply-To: <046.dc00390e27ed7d96b00f47e4a0f77b9e@haskell.org> References: <046.dc00390e27ed7d96b00f47e4a0f77b9e@haskell.org> Message-ID: <061.b10b4d2647f2c1eefa22aa359352ac4f@haskell.org> #12764: Be able to pin a thread to a numa node without fixing a capabiity -------------------------------------+------------------------------------- Reporter: darshan | Owner: darshan Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2637 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"122d826d1d1b7ba6e73866331863fa1e0b3e99ea/ghc" 122d826d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="122d826d1d1b7ba6e73866331863fa1e0b3e99ea" rts: Add api to pin a thread to a numa node but without fixing a capability `rts_setInCallCapability` sets the thread affinity as well as pins the numa node. We should also have the ability to set the numa node without setting the capability affinity. `rts_pinNumaNodeForCapability` function is added and exported via `RtsAPI.h`. Previous callers of `rts_setInCallCapability` should now also call `rts_pinNumaNodeForCapability` to get the same effect as before. Test Plan: ./validate Reviewers: austin, simonmar, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie, niteria Differential Revision: https://phabricator.haskell.org/D2637 GHC Trac Issues: #12764 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 04:50:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 04:50:41 -0000 Subject: [GHC] #12665: Make Read instances for Integral types faster, and make them fail fast In-Reply-To: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> References: <045.cfe1702e815afa54840f2f25ea450e94@haskell.org> Message-ID: <060.7bdf6ffae432411241fa981039333e62@haskell.org> #12665: Make Read instances for Integral types faster, and make them fail fast -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bef7e784d037f720697a215b9e21f13b385e6d3e/ghc" bef7e78/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bef7e784d037f720697a215b9e21f13b385e6d3e" Read parentheses better Instead of pulling a token and looking for `'('` or `')'`, just look for the character itself. This prevents us from lexing every single item twice, once to see if it's a left parenthesis and once to actually parse it. Partially fixes #12665 Make parens faster more aggressively * Strip spaces before parsing, so we never have to strip the same spaces twice. * String parsers together manually, to try to avoid unnecessary closure creation. Test Plan: Validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2630 GHC Trac Issues: #12665 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 04:50:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 04:50:41 -0000 Subject: [GHC] #12388: Don't barf on failures in the RTS linker In-Reply-To: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> References: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> Message-ID: <062.611ea8410024bb24c4d7496d82a84019@haskell.org> #12388: Don't barf on failures in the RTS linker -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2570 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"aa10c67ec5b9cea9d89ecac88f3a22ec873439c2/ghc" aa10c67e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aa10c67ec5b9cea9d89ecac88f3a22ec873439c2" rts/linker: Move loadArchive to new source file Test Plan: Validate Reviewers: DemiMarie, austin, simonmar, erikd Reviewed By: DemiMarie Subscribers: Phyx, thomie, hvr Differential Revision: https://phabricator.haskell.org/D2642 GHC Trac Issues: #12388 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 04:50:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 04:50:41 -0000 Subject: [GHC] #12164: Type signatures in patterns not (yet) handled by Template Haskell In-Reply-To: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> References: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> Message-ID: <060.35886efcd73a1a05a174cff9acc35c54@haskell.org> #12164: Type signatures in patterns not (yet) handled by Template Haskell -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2490 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e8ae4dc8558b5917f6c65ad196859783e90038bd/ghc" e8ae4dc8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e8ae4dc8558b5917f6c65ad196859783e90038bd" Update user's guide after D2490 D2490 added support for type wildcards in TH pattern splices. The user's guide still said that they were not supported, this patch fixes this. Test Plan: build documentation Reviewers: goldfire, austin, mvv, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2686 GHC Trac Issues: #12164 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 04:50:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 04:50:42 -0000 Subject: [GHC] #6088: GeneralizedNewtypeDeriving + TypeFamilies + Equality constraints In-Reply-To: <046.1266b675873dc380465a9fe1f33ad29a@haskell.org> References: <046.1266b675873dc380465a9fe1f33ad29a@haskell.org> Message-ID: <061.4ac5ad661ad7234ced95c1b6b9815356@haskell.org> #6088: GeneralizedNewtypeDeriving + TypeFamilies + Equality constraints -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T6088 Blocked By: | Blocking: Related Tickets: 3046 | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"03e8d26fe0a8f7981a76550118f3c584cad76c47/ghc" 03e8d26f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03e8d26fe0a8f7981a76550118f3c584cad76c47" Prevent GND from inferring an instance context for method-less classes When `GeneralizedNewtypeDeriving` is used with a type class that has no methods, it will generate a redundant context, and as a result, it can trigger warnings when compiled with `-Wredundant-constraints`. This is a simple change in behavior to check beforehand if a class has methods when deriving it with GND, and if it has no methods, avoid inferring the redundant context. Beware that the test for #6088, which used to be expected to fail, now compiles without issue since it doesn't infer a problematic instance context. Thanks to Simon Peyton Jones for doing the necessary refactoring in f05d685ae05ec293083f2fa7ec7ba057fbe64869. Fixes #12814. Test Plan: ./validate Reviewers: goldfire, rwbarton, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2692 GHC Trac Issues: #12814 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 04:50:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 04:50:42 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.ed70ed274433181202a62671ecc47d74@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Phab:D2692 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"03e8d26fe0a8f7981a76550118f3c584cad76c47/ghc" 03e8d26f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03e8d26fe0a8f7981a76550118f3c584cad76c47" Prevent GND from inferring an instance context for method-less classes When `GeneralizedNewtypeDeriving` is used with a type class that has no methods, it will generate a redundant context, and as a result, it can trigger warnings when compiled with `-Wredundant-constraints`. This is a simple change in behavior to check beforehand if a class has methods when deriving it with GND, and if it has no methods, avoid inferring the redundant context. Beware that the test for #6088, which used to be expected to fail, now compiles without issue since it doesn't infer a problematic instance context. Thanks to Simon Peyton Jones for doing the necessary refactoring in f05d685ae05ec293083f2fa7ec7ba057fbe64869. Fixes #12814. Test Plan: ./validate Reviewers: goldfire, rwbarton, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2692 GHC Trac Issues: #12814 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 05:06:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 05:06:22 -0000 Subject: [GHC] #12764: Be able to pin a thread to a numa node without fixing a capabiity In-Reply-To: <046.dc00390e27ed7d96b00f47e4a0f77b9e@haskell.org> References: <046.dc00390e27ed7d96b00f47e4a0f77b9e@haskell.org> Message-ID: <061.5f9571138b6b882bdab00e3d0c6c1e87@haskell.org> #12764: Be able to pin a thread to a numa node without fixing a capabiity -------------------------------------+------------------------------------- Reporter: darshan | Owner: darshan Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2637 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 05:07:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 05:07:02 -0000 Subject: [GHC] #12814: Should GND infer an instance context when deriving method-free classes? In-Reply-To: <050.64605755935b9b77ebba2d41701d372d@haskell.org> References: <050.64605755935b9b77ebba2d41701d372d@haskell.org> Message-ID: <065.349740138258822eae00ab5b5e8e249e@haskell.org> #12814: Should GND infer an instance context when deriving method-free classes? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #12810 | Differential Rev(s): Phab:D2692 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 05:41:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 05:41:57 -0000 Subject: [GHC] #12823: Inconsistency in acceptance of equality constraints in different forms In-Reply-To: <045.17e2d45fdb42780e0f8c0a412e457d55@haskell.org> References: <045.17e2d45fdb42780e0f8c0a412e457d55@haskell.org> Message-ID: <060.74b6f6fcb2956b87aebba93e8bb36c66@haskell.org> #12823: Inconsistency in acceptance of equality constraints in different forms -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Hmm. GHC won't let you pattern match on a GADT in a module without `GADTs` or `TypeFamilies`. But you can emulate the GADT with `Equal` and an existential type as dfeuer says, and then GHC accepts the match and even does the type refinement without complaining. (But not if you use `EqualS`! Then GHC thinks the existential type is a GADT.) {{{#!hs {-# LANGUAGE GADTs #-} module G1 where class a ~ Int => IsInt a instance IsInt Int data X a = IsInt a => C --- module G2 where import G1 f :: X a -> a f C = 7 }}} This doesn't seem like a great situation, but you are allowed to turn off `MonoLocalBinds` explicitly in a module with `GADTs` already, so it's not so terrible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 09:16:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 09:16:26 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.b3fcc2eb1046c773f73f9a6ff1d41c91@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > You can see that the STG code just reflects the original Haskell source code and that the faulty register initialization has not yet been dropped down to within the loop(s), so the problem is not here. The problem is in the generation of the first CMM Aha! Could you possibly make the tiniest possible example that illustrates precisely this point. You can motivate its importance by this thread, but in thinking about how to fix it, it's MUCH easier to grok a small example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 09:22:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 09:22:25 -0000 Subject: [GHC] #12823: Inconsistency in acceptance of equality constraints in different forms In-Reply-To: <045.17e2d45fdb42780e0f8c0a412e457d55@haskell.org> References: <045.17e2d45fdb42780e0f8c0a412e457d55@haskell.org> Message-ID: <060.bd693cb9e5b99f8661f0cf7a8ebae315@haskell.org> #12823: Inconsistency in acceptance of equality constraints in different forms -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree it's a bit odd but I don't see how to do better. Generally, GHC's view is that the language-extension flags apply to the source code you write in the module being compiled; and NOT to the library code that you are implicitly using thereby. Type synonyms are very transparent, and hide nothing, which is a bit in conflict with the above. Perhaps we could make them opaque for the purpose of language-extension tests? I'm sure we'd get different complaints then :-). So I don't see a straightforward way to fix this inconsistency. Yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 11:19:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 11:19:09 -0000 Subject: [GHC] #12824: crashed when install debian on ubuntu 16.06 in Hyper-V VM Message-ID: <046.d05a6258f006cf3eab6706a797e69f20@haskell.org> #12824: crashed when install debian on ubuntu 16.06 in Hyper-V VM -------------------------------------+------------------------------------- Reporter: Qinka95 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When installing the package (debian-3.91.1), ghc(8.0.1) crashed. And output these: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): find_tycon Loc [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} And the full output when installing debian are here: {{{ $ cabal install debian Resolving dependencies... cabal: Entering directory '/tmp/cabal-tmp-31302/debian-3.91.1' Configuring debian-3.91.1... Building debian-3.91.1... Preprocessing library debian-3.91.1... [ 1 of 37] Compiling Debian.UTF8 ( Debian/UTF8.hs, dist/build/Debian/UTF8.o ) [ 2 of 37] Compiling Debian.Version.Internal ( Debian/Version/Internal.hs, dist/build/Debian/Version/Internal.o ) [ 3 of 37] Compiling Debian.Extra.Files ( Debian/Extra/Files.hs, dist/build/Debian/Extra/Files.o ) [ 4 of 37] Compiling Debian.Loc ( Debian/Loc.hs, dist/build/Debian/Loc.o ) [ 5 of 37] Compiling Debian.Pretty ( Debian/Pretty.hs, dist/build/Debian/Pretty.o ) [ 6 of 37] Compiling Debian.Version.Common ( Debian/Version/Common.hs, dist/build/Debian/Version/Common.o ) [ 7 of 37] Compiling Debian.Version.String ( Debian/Version/String.hs, dist/build/Debian/Version/String.o ) [ 8 of 37] Compiling Debian.Version.Text ( Debian/Version/Text.hs, dist/build/Debian/Version/Text.o ) [ 9 of 37] Compiling Debian.Arch ( Debian/Arch.hs, dist/build/Debian/Arch.o ) [10 of 37] Compiling Debian.Time ( Debian/Time.hs, dist/build/Debian/Time.o ) Debian/Time.hs:23:19: warning: [-Wdeprecations] In the use of ‘parseTime’ (imported from Data.Time, but defined in time-1.6.0.1:Data.Time.Format.Parse): Deprecated: "use "parseTimeM True" instead" [11 of 37] Compiling Debian.URI ( Debian/URI.hs, dist/build/Debian/URI.o ) [12 of 37] Compiling Debian.Release ( Debian/Release.hs, dist/build/Debian/Release.o ) [13 of 37] Compiling Debian.Sources ( Debian/Sources.hs, dist/build/Debian/Sources.o ) [14 of 37] Compiling Debian.Control.Common ( Debian/Control/Common.hs, dist/build/Debian/Control/Common.o ) Debian/Control/Common.hs:75:1: warning: [-Wredundant-constraints] • Redundant constraint: ControlFunctions a • In the type signature for: protectFieldText' :: (StringLike a, ListLike a Char, ControlFunctions a) => a -> a Debian/Control/Common.hs:158:1: warning: [-Wredundant-constraints] • Redundant constraint: Eq a • In the type signature for: raiseFields :: Eq a => (a -> Bool) -> Paragraph' a -> Paragraph' a [15 of 37] Compiling Debian.Control.String ( Debian/Control/String.hs, dist/build/Debian/Control/String.o ) [16 of 37] Compiling Debian.Deb ( Debian/Deb.hs, dist/build/Debian/Deb.o ) [17 of 37] Compiling Debian.Apt.Methods ( Debian/Apt/Methods.hs, dist/build/Debian/Apt/Methods.o ) Debian/Apt/Methods.hs:28:1: warning: [-Wdeprecations] Module ‘Control.Monad.Error’ is deprecated: Use Control.Monad.Except instead [18 of 37] Compiling Debian.Version.ByteString ( Debian/Version/ByteString.hs, dist/build/Debian/Version/ByteString.o ) [19 of 37] Compiling Debian.Version ( Debian/Version.hs, dist/build/Debian/Version.o ) [20 of 37] Compiling Debian.Changes ( Debian/Changes.hs, dist/build/Debian/Changes.o ) [21 of 37] Compiling Debian.Relation.Common ( Debian/Relation/Common.hs, dist/build/Debian/Relation/Common.o ) [22 of 37] Compiling Debian.Relation.String ( Debian/Relation/String.hs, dist/build/Debian/Relation/String.o ) [23 of 37] Compiling Debian.Relation.Text ( Debian/Relation/Text.hs, dist/build/Debian/Relation/Text.o ) [24 of 37] Compiling Debian.Relation.ByteString ( Debian/Relation/ByteString.hs, dist/build/Debian/Relation/ByteString.o ) [25 of 37] Compiling Debian.Relation ( Debian/Relation.hs, dist/build/Debian/Relation.o ) [26 of 37] Compiling Debian.Control.ByteString ( Debian/Control/ByteString.hs, dist/build/Debian/Control/ByteString.o ) Debian/Control/ByteString.hs:132:1: warning: [-Wredundant-constraints] • Redundant constraint: ControlFunctions a • In the type signature for: protectFieldText' :: (LL.StringLike a, LL.ListLike a Word8, ControlFunctions a) => a -> a Debian/Control/ByteString.hs:138:7: warning: [-Wredundant-constraints] • Redundant constraint: LL.StringLike a • In the type signature for: dropWhileEnd :: (LL.StringLike a1, LL.ListLike a1 Word8) => (Word8 -> Bool) -> a1 -> a1 In an equation for ‘protectFieldText'’: protectFieldText' s = case LL.lines s of { [] -> LL.empty (l : ls) -> dropWhileEnd (isSpace . chr . fromIntegral) $ LL.unlines $ l : map protect ls } where dropWhileEnd :: (LL.StringLike a, LL.ListLike a Word8) => (Word8 -> Bool) -> a -> a dropWhileEnd func = LL.reverse . LL.dropWhile func . LL.reverse protect :: (LL.StringLike a, LL.ListLike a Word8) => a -> a protect l = maybe LL.empty (\ c -> if isHorizSpace c then l else LL.cons (ord' ' ' :: Word8) l) (LL.find (const True :: Word8 -> Bool) l) .... Debian/Control/ByteString.hs:140:7: warning: [-Wredundant-constraints] • Redundant constraint: LL.StringLike a • In the type signature for: protect :: (LL.StringLike a1, LL.ListLike a1 Word8) => a1 -> a1 In an equation for ‘protectFieldText'’: protectFieldText' s = case LL.lines s of { [] -> LL.empty (l : ls) -> dropWhileEnd (isSpace . chr . fromIntegral) $ LL.unlines $ l : map protect ls } where dropWhileEnd :: (LL.StringLike a, LL.ListLike a Word8) => (Word8 -> Bool) -> a -> a dropWhileEnd func = LL.reverse . LL.dropWhile func . LL.reverse protect :: (LL.StringLike a, LL.ListLike a Word8) => a -> a protect l = maybe LL.empty (\ c -> if isHorizSpace c then l else LL.cons (ord' ' ' :: Word8) l) (LL.find (const True :: Word8 -> Bool) l) .... [27 of 37] Compiling Debian.Control.Text ( Debian/Control/Text.hs, dist/build/Debian/Control/Text.o ) Debian/Control/Text.hs:32:1: warning: [-Wunused-imports] The qualified import of ‘T.reverse’ from module ‘Data.Text’ is redundant [28 of 37] Compiling Debian.Control.Policy ( Debian/Control/Policy.hs, dist/build/Debian/Control/Policy.o ) Debian/Control/Policy.hs:87:5: warning: [-Wunused-top-binds] Defined but not used: ‘control’ [29 of 37] Compiling Debian.Control.Builder ( Debian/Control/Builder.hs, dist/build/Debian/Control/Builder.o ) Debian/Control/Builder.hs:34:1: warning: [-Wunused-imports] The qualified import of ‘Data.Text’ is redundant except perhaps to import instances from ‘Data.Text’ To import instances alone, use: import Data.Text() Debian/Control/Builder.hs:36:1: warning: [-Wunused-imports] The import of ‘fromLazyText’ from module ‘Data.Text.Lazy.Builder’ is redundant Debian/Control/Builder.hs:104:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: dropAround :: forall c item. LL.ListLike c item => (item -> Bool) -> c -> c [30 of 37] Compiling Debian.Control.TextLazy ( Debian/Control/TextLazy.hs, dist/build/Debian/Control/TextLazy.o ) Debian/Control/TextLazy.hs:32:1: warning: [-Wunused-imports] The qualified import of ‘T.reverse’ from module ‘Data.Text.Lazy’ is redundant [31 of 37] Compiling Debian.Control ( Debian/Control.hs, dist/build/Debian/Control.o ) Debian/Control.hs:56:1: warning: [-Wunused-imports] The qualified import of ‘Debian.Control.TextLazy’ is redundant except perhaps to import instances from ‘Debian.Control.TextLazy’ To import instances alone, use: import Debian.Control.TextLazy() [32 of 37] Compiling Debian.Apt.Index ( Debian/Apt/Index.hs, dist/build/Debian/Apt/Index.o ) [33 of 37] Compiling Debian.Report ( Debian/Report.hs, dist/build/Debian/Report.o ) [34 of 37] Compiling Debian.GenBuildDeps ( Debian/GenBuildDeps.hs, dist/build/Debian/GenBuildDeps.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): find_tycon Loc [] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Leaving directory '/tmp/cabal-tmp-31302/debian-3.91.1' Failed to install debian-3.91.1 cabal: Error: some packages failed to install: debian-3.91.1 failed during the building phase. The exception was: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 12:17:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 12:17:44 -0000 Subject: [GHC] #6077: Respect XDG_CONFIG_HOME In-Reply-To: <045.4be78870b39bed231ff23249aec382c8@haskell.org> References: <045.4be78870b39bed231ff23249aec382c8@haskell.org> Message-ID: <060.4336f6c2d9e8316c43ca3718a131aa12@haskell.org> #6077: Respect XDG_CONFIG_HOME -------------------------------------+------------------------------------- Reporter: So8res | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 5966 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gueux): * cc: gueux (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 14:24:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 14:24:53 -0000 Subject: [GHC] #12824: crashed when install debian on ubuntu 16.06 in Hyper-V VM In-Reply-To: <046.d05a6258f006cf3eab6706a797e69f20@haskell.org> References: <046.d05a6258f006cf3eab6706a797e69f20@haskell.org> Message-ID: <061.181d027a3e461315fccd5d1599b316d8@haskell.org> #12824: crashed when install debian on ubuntu 16.06 in Hyper-V VM -------------------------------------+------------------------------------- Reporter: Qinka95 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12130 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12130 Comment: This is a duplicate of #12130 (a bad interaction between `RecordWildCards` and `TemplateHaskell`), and has already been fixed in GHC 8.0.2 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 14:36:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 14:36:34 -0000 Subject: [GHC] #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.4c03b0bd8962faa2f988802251abaa6b@haskell.org> #12808: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by GordonBGood): Replying to [comment:9 simonpj]: > > You can see that the STG code just reflects the original Haskell source code and that the faulty register initialization has not yet been dropped down to within the loop(s), so the problem is not here. The problem is in the generation of the first CMM > > Aha! Could you possibly make the tiniest possible example that illustrates precisely this point. You can motivate its importance by this thread, but in thinking about how to fix it, it's MUCH easier to grok a small example. I can't cut the test program down to just a few lines as I believe that the problem is related to pointers and pointer arithmetic (the Addr# primitive) and thus there is some setup involved in their use in a loop that shows the problems. However, I have boiled the test down to a very simple tail-recursive loop with only one cull operation per loop using an Addr# and an offset that shows the problems; this loop is inside another loop to feed a variable prime "p" to the inner loop so it doesn't get optimized away as constants, and this is inside the setup code to produced the pinned byte array on which the loop works in the following code: {{{#!hs -- SimpleEfficiencyBug {-# LANGUAGE FlexibleContexts, BangPatterns, MagicHash, UnboxedTuples #-} {-# OPTIONS_GHC -O3 -rtsopts -keep-s-files -ddump-stg -ddump-cmm -ddump- opt-cmm -ddump-to-file -dumpdir . #-} -- or -O2 -fllvm -v -dcore-lint -ddump-asm import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base import GHC.ST ( ST(..) ) import GHC.Exts cull :: () -> [Int] cull() = [i | (i, True) <- assocs arr ] where arr = runSTUArray $ do let bfBts = 1 `shiftL` 17 -- 16 Kilobytes worth of bits bf <- newArray (0, bfBts - 1) False :: ST s (STUArray s Int Bool) cullb bf cullb (STUArray l u n marr#) = ST $ \s0# -> -- following is just setup for the loop... case getSizeofMutableByteArray# marr# s0# of { (# s1#, n# #) -> case newPinnedByteArray# n# s1# of { (# s2#, marr'# #) -> case copyMutableByteArray# marr# 0# marr'# 0# n# s2# of { s3# -> case unsafeFreezeByteArray# marr'# s3# of { (# s4#, arr# #) -> -- must do this case byteArrayContents# arr# of { adr# -> -- to obtain the addr# of pinned marr' here let cullp !p@(I# p#) sp# = -- for several prime values if p > 5 then case copyMutableByteArray# marr'# 0# marr# 0# n# sp# of so# -> (# so#, STUArray l u n marr# #) else let !r1@(I# r1#) = ((p .&. 7) + p) `shiftR` 3 in -- register offset value let !(I# szlmt#) = n `div` 8 - r1 in let lmt# = plusAddr# adr# szlmt# in let doit c# s# = -- all the work is done here; herein lies the bugs... case c# `ltAddr#` lmt# of 0# -> s# _ -> case readWord8OffAddr# c# r1# s# of { (# s0#, v0# #) -> case writeWord8OffAddr# c# r1# (v0# `or#` (int2Word# 1#)) s0# of { s1# -> doit (plusAddr# c# p#) s1# }} in case doit adr# sp# of sd# -> cullp (p + 2) sd# in cullp 1 s4# }}}}} main = print $ length $ cull() }}} When compiled with the "-fllvm" compiler flag, the above code produces the following STG code for the inner loop (located by searching for the first "doit1_"): {{{ let { doit1_s7pL [Occ=LoopBreaker] :: GHC.Prim.Addr# -> GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Prim.State# GHC.Prim.RealWorld [LclId, Arity=2, Str=DmdType , Unf=OtherCon []] = sat-only \r srt:SRT:[] [c#_s7pM s#_s7pN] case ltAddr# [c#_s7pM lmt#1_s7pJ] of _ [Occ=Dead] { __DEFAULT -> case readWord8OffAddr# [c#_s7pM r1#_s7pG s#_s7pN] of _ [Occ=Dead] { (#,#) ipv6_s7pQ [Occ=Once] ipv7_s7pR [Occ=Once] -> case or# [ipv7_s7pR 1##] of sat_s7pS { __DEFAULT -> case writeWord8OffAddr# [c#_s7pM r1#_s7pG sat_s7pS ipv6_s7pQ] of s1#1_s7pT [OS=OneShot] { __DEFAULT -> case plusAddr# [c#_s7pM ww_s7pC] of sat_s7pU { __DEFAULT -> doit1_s7pL sat_s7pU s1#1_s7pT; }; }; }; }; 0# -> s#_s7pN; }; } in }}} Which first produces the following CMM code (found by search for "doit1_"): {{{ doit1_s7pL_entry() // [R2, R1] { info_tbl: [(c7Kw, label: doit1_s7pL_info rep:HeapRep 3 nonptrs { Fun {arity: 2 fun_type: ArgSpec 4} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c7Kw: _s7pM::I64 = R2; _s7pL::P64 = R1; goto c7Kp; c7Kp: if ((old + 0) - < SpLim) goto c7Kx; else goto c7Ky; c7Kx: R2 = _s7pM::I64; R1 = _s7pL::P64; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; c7Ky: goto c7Ko; c7Ko: _s7pC::I64 = I64[_s7pL::P64 + 6]; // registers initialized inside loop here _s7pG::I64 = I64[_s7pL::P64 + 14]; _s7pJ::I64 = I64[_s7pL::P64 + 22]; // to here _c7Kr::I64 = _s7pM::I64 < _s7pJ::I64; _s7pO::I64 = _c7Kr::I64; switch [-9223372036854775808 .. 9223372036854775807] _s7pO::I64 { case 0 : goto c7Kv; default: goto c7Ku; } c7Kv: goto c7KG; c7KG: call (P64[(old + 8)])() args: 8, res: 0, upd: 8; c7Ku: goto c7KB; c7KB: _s7pR::I64 = %MO_UU_Conv_W8_W64(I8[_s7pM::I64 + (_s7pG::I64 << 0)]); _s7pR::I64 = _s7pR::I64; _c7KJ::I64 = _s7pR::I64 | 1; _s7pS::I64 = _c7KJ::I64; I8[_s7pM::I64 + (_s7pG::I64 << 0)] = %MO_UU_Conv_W64_W8(_s7pS::I64); _c7KO::I64 = _s7pM::I64 + _s7pC::I64; _s7pU::I64 = _c7KO::I64; _s7pM::I64 = _s7pU::I64; goto c7Ko; } }, }}} then after many optimization passes produces the following optimized CMM code: {{{ ==================== Optimised Cmm ==================== 2016-11-11 13:14:21.2389114 UTC doit1_s7pL_entry() // [R1, R2] { [(c7Kw, doit1_s7pL_info: const 8589934596; const 12884901888; const 9;)] } {offset c7Kw: _s7pM::I64 = R2; _s7pL::P64 = R1; goto c7Ko; c7Ko: switch [-9223372036854775808 .. 9223372036854775807] (_s7pM::I64 < I64[_s7pL::P64 + 22]) { case 0 : goto c7Kv; default: goto c7Ku; } c7Kv: call (P64[Sp])() args: 8, res: 0, upd: 8; c7Ku: _s7pC::I64 = I64[_s7pL::P64 + 6]; // registers initialized inside loop here _s7pG::I64 = I64[_s7pL::P64 + 14]; // and here I8[_s7pM::I64 + _s7pG::I64] = %MO_UU_Conv_W64_W8(%MO_UU_Conv_W8_W64(I8[_s7pM::I64 + _s7pG::I64]) | 1); _s7pM::I64 = _s7pM::I64 + _s7pC::I64; goto c7Ko; } } }}} and finally the following assembly code: {{{ s7pL_info$def: # BB#0: # %c7Kw cmpq %r14, 22(%rbx) jbe .LBB18_2 .align 16, 0x90 .LBB18_1: # %c7Ku # =>This Inner Loop Header: Depth=1 movq 14(%rbx), %rax # registers initialized inside loop here movq 6(%rbx), %rcx # and here addq %r14, %rcx orb $1, (%rax,%r14) cmpq 22(%rbx), %rcx # and an additional unnecessary memory load here by LLVM? movq %rcx, %r14 # extra unnecessary instruction if code reformulated jb .LBB18_1 .LBB18_2: # %c7Kv movq (%rbp), %rax rex64 jmpq *%rax # TAILCALL }}} I find no problems with the STG code, but the problems persist through all of the other codes including the initial CMM code. I have commented on where the problems are in the above codes. I would like to see the optimized CMM code look like the following: {{{ doit1_s7pL_entry() // [R1, R2] { [(c7Kw, doit1_s7pL_info: const 8589934596; const 12884901888; const 9;)] } {offset c7Kw: _s7pM::I64 = R2; _s7pL::P64 = R1; _s7pC::I64 = I64[_s7pL::P64 + 6]; // registers initialized outside loop here _s7pG::I64 = I64[_s7pL::P64 + 14]; // and here goto c7Ko; c7Ko: switch [-9223372036854775808 .. 9223372036854775807] (_s7pM::I64 < I64[_s7pL::P64 + 22]) { case 0 : goto c7Kv; default: goto c7Ku; } c7Kv: call (P64[Sp])() args: 8, res: 0, upd: 8; c7Ku: I8[_s7pM::I64 + _s7pG::I64] = %MO_UU_Conv_W64_W8(%MO_UU_Conv_W8_W64(I8[_s7pM::I64 + _s7pG::I64]) | 1); _s7pM::I64 = _s7pM::I64 + _s7pC::I64; goto c7Ko; } } }}} which should produce the following desired assembly code: {{{ s7pL_info$def: # BB#0: # %c7Kw movq 14(%rbx), %rax # registers initialized outside loop here movq 6(%rbx), %rcx # and here movq 22(%rbx), %rbx # and here cmpq %r14, %rbx jbe .LBB18_2 .align 16, 0x90 .LBB18_1: # %c7Ku # =>This Inner Loop Header: Depth=1 orb $1, (%rax,%r14) addq %rcx, %r14 cmpq %rbx, %rcx # use a register for comparison jb .LBB18_1 .LBB18_2: # %c7Kv movq (%rbp), %rax rex64 jmpq *%rax # TAILCALL }}} The above assembly code is about as good as it gets in any language, and GHC should be able to produce this, at least with the LLVM backend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 15:55:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 15:55:26 -0000 Subject: [GHC] #12825: ghc panic on ppc64el, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI Message-ID: <044.632ebd0cd498a6c31622b890d3f61cd2@haskell.org> #12825: ghc panic on ppc64el, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI ---------------------------------+--------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+--------------------------------- {{{ [331 of 332] Compiling Agda.Interaction.EmacsTop ( src/full/Agda/Interaction/EmacsTop.hs, dist- ghc/build/Agda/Interaction/EmacsTop.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for powerpc64le-unknown-linux): applyTypeToArgs Expression: $w$cgmapQl2 stdin LineBuffering s_aJ4 Type: forall r_a2gyr r'_a2gys. (r_a2gyr -> r'_a2gys -> r_a2gyr) -> r_a2gyr -> (forall d_a2gyt. Data d_a2gyt => d_a2gyt -> r'_a2gys) -> [ModulePragma] -> ModuleName -> r_a2gyr Args: [stdin, LineBuffering, s_aJ4] 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 Nov 11 16:04:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 16:04:30 -0000 Subject: [GHC] #12774: bkpcabal02 test fails on OS X In-Reply-To: <046.8383b3019ab3994d2e0b07c8047aa068@haskell.org> References: <046.8383b3019ab3994d2e0b07c8047aa068@haskell.org> Message-ID: <061.8b9f5611dfd4c95c0002005e7b35e4b6@haskell.org> #12774: bkpcabal02 test fails on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 16:04:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 16:04:42 -0000 Subject: [GHC] #12774: bkpcabal02 test fails on OS X In-Reply-To: <046.8383b3019ab3994d2e0b07c8047aa068@haskell.org> References: <046.8383b3019ab3994d2e0b07c8047aa068@haskell.org> Message-ID: <061.171480b3dd66c633be767af260e1c039@haskell.org> #12774: bkpcabal02 test fails on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 16:18:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 16:18:42 -0000 Subject: [GHC] #12822: Cleanup GHC verbosity flags In-Reply-To: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> References: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> Message-ID: <060.1a7b9934a9e824944b1ab2bdfa50493f@haskell.org> #12822: Cleanup GHC verbosity flags -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | newcomer,flags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): +1 for efforts in this direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 16:59:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 16:59:21 -0000 Subject: [GHC] #12826: TyVar ASSERT failure in type family checking: T12041 Message-ID: <046.9d0fa2858f11e126141a89fb401b8d81@haskell.org> #12826: TyVar ASSERT failure in type family checking: T12041 -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In HEAD, if you build the compiler with -DDEBUG, test `indexed- types/should_fail/T12041` fails thus {{{ +ghc: panic! (the 'impossible' happened) + (GHC version 8.1.20161109 for x86_64-unknown-linux): + ASSERT failed! + i_axb + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:: in :Outputable + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:: in :TcType + Call stack: + CallStack (from HasCallStack): + prettyCurrentCallStack, called at compiler/utils/Outputable.hs:: in :Outputable + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcType.hs:: in :TcType }}} A `TyVar` is showing up where a `TcTyVar` is expected. I'm pretty certain this is harmless in a production compiler, but reflects an infelicity somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 18:17:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 18:17:22 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.99ecc571b8c552a89ba78721d6a376c2@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"d421a7e22e0be3de32376970b8c38ec308f959da/ghc" d421a7e2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d421a7e22e0be3de32376970b8c38ec308f959da" Pass -no-pie to GCC Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be default in their GCC packaging. This breaks our abuse of GCC as a linker which requires that we pass -Wl,-r, which is incompatible with PIE (since the former implies that we are generating a relocatable object file and the latter an executable). This is a second attempt at D2691. This attempt constrasts with D2691 in that it preserves the "does gcc support -no-pie" flag in settings, allowing this to be reconfigured by `configure` during installation of a binary distribution. Thanks for @rwbarton for drawing attention to this issue. Test Plan: Validate Reviewers: austin, hvr, erikd Reviewed By: erikd Subscribers: thomie, rwbarton, erikd Differential Revision: https://phabricator.haskell.org/D2693 GHC Trac Issues: #12759 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 20:40:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 20:40:13 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.ad71a6239c77c635baa7a36e6bedda26@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.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 Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 2591a4b94903d4f9d9348a92599a74aacf5eda66. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 20:40:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 20:40:50 -0000 Subject: [GHC] #12732: GHC bug In-Reply-To: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> References: <051.b665aa081a9b0ecc708855a5741d83e8@haskell.org> Message-ID: <066.5322c032d84bb03a7edac4db49cac327@haskell.org> #12732: GHC bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as 4227f3ea715960cc272a525f37e5d67ba232ae24. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 20:41:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 20:41:20 -0000 Subject: [GHC] #12763: Incorrect behavior with empty functional dependencies In-Reply-To: <047.270f76781eaf61ddb7db1183cbaa2fe1@haskell.org> References: <047.270f76781eaf61ddb7db1183cbaa2fe1@haskell.org> Message-ID: <062.4594f085fc0626e071d6b16f076be368@haskell.org> #12763: Incorrect behavior with empty functional dependencies -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T12763 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 8719d871bac848ee10e7455b5821a18dabd48b5b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 20:41:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 20:41:52 -0000 Subject: [GHC] #12771: GHCi incorrectly favors static libraries over import libraries In-Reply-To: <044.697549dd86183293500a27a6383cbe15@haskell.org> References: <044.697549dd86183293500a27a6383cbe15@haskell.org> Message-ID: <059.8770c01043074dc3673772a7c808d6fe@haskell.org> #12771: GHCi incorrectly favors static libraries over import libraries -----------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: T12771 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2651 Wiki Page: | -----------------------------+---------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 95b6affcf2c03495d6635c80bfa3c8636f684363. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 20:42:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 20:42:28 -0000 Subject: [GHC] #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" In-Reply-To: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> References: <044.2731a5fed9f03db02ca7ed017a0f14e1@haskell.org> Message-ID: <059.a3ef706051a9ef132e2c8e0ae01232e0@haskell.org> #12788: While using Data.Aeson.TH, "Irrefutable pattern failed for pattern sel_id : _" -------------------------------------+------------------------------------- Reporter: jchia | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as b72b7c8a2e23196a7d5e1d72dbb8f1b790545cda. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 20:42:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 20:42:51 -0000 Subject: [GHC] #12797: Default Rules stop working when providing some constraints In-Reply-To: <046.3e265c62039d77b084607215464a4e41@haskell.org> References: <046.3e265c62039d77b084607215464a4e41@haskell.org> Message-ID: <061.8f736fbed77d560dd85a6ba8c5ae07b3@haskell.org> #12797: Default Rules stop working when providing some constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12797 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 28c62bb588f7026d9985afe235cbeec5e3fd9a76. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 20:43:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 20:43:23 -0000 Subject: [GHC] #12768: 8.0.2 derives invalid code when class method is constrained by itself In-Reply-To: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> References: <046.56bc6d546dc8ddd9b0cdf93b2aa8676a@haskell.org> Message-ID: <061.e727c7e3dd659983787dab8fad90cffd@haskell.org> #12768: 8.0.2 derives invalid code when class method is constrained by itself -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as 411bd2dfed3d6cfe73cd0e4521acee67f18a8fe7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 20:49:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 20:49:48 -0000 Subject: [GHC] #12811: GHC tells me to use RankNTypes when it's already enabled In-Reply-To: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> References: <050.c324058c91d84c3808a7540ed03afeaf@haskell.org> Message-ID: <065.0e5146c68694481516cd356193bfafa0@haskell.org> #12811: GHC tells me to use RankNTypes when it's already enabled -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #11669 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11669 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 20:50:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 20:50:52 -0000 Subject: [GHC] #11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int" In-Reply-To: <051.ef9fc6a373cf8eba53b7bf79d29ca288@haskell.org> References: <051.ef9fc6a373cf8eba53b7bf79d29ca288@haskell.org> Message-ID: <066.5b3878c7335f6829660bcb1057a9d402@haskell.org> #11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: drobnik Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #3155, #12811 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * related: #3155 => #3155, #12811 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 22:33:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 22:33:05 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.431d33d684177243d3ec7290814a2342@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => danharaj -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 23:24:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 23:24:18 -0000 Subject: [GHC] #10986: GHC should delete all temporary files it creates in /tmp In-Reply-To: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> References: <044.1681438585b48fcd6c17fa0b77a432bd@haskell.org> Message-ID: <059.4badc747ba99bc553312929da5171fc3@haskell.org> #10986: GHC should delete all temporary files it creates in /tmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2324 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: I'm going to bump this off to 8.2. The fact that GCC 6, which fixes the root cause of this issue, is gradually becoming available the pressure to hack around it in GHC is rather relieved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 23:34:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 23:34:15 -0000 Subject: [GHC] #12021: Type variable escapes its scope In-Reply-To: <046.130748221ef7180f1063edfb1f33f5e9@haskell.org> References: <046.130748221ef7180f1063edfb1f33f5e9@haskell.org> Message-ID: <061.260aee66265e963bf90b7911ded72e67@haskell.org> #12021: Type variable escapes its scope -------------------------------------+------------------------------------- Reporter: ttuegel | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1-rc4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: Punting off to 8.0.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 23:35:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 23:35:09 -0000 Subject: [GHC] #12737: T12227 is failing on ghc-8.0 In-Reply-To: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> References: <045.0ea1cfebd1260afa6de135f4f7b4ff86@haskell.org> Message-ID: <060.a68d89df2e81d6630563b6f3dda6a3ad@haskell.org> #12737: T12227 is failing on ghc-8.0 -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: Visual Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: Unfortunately this will need to be resolved in 8.0.3, if at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 23:38:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 23:38:07 -0000 Subject: [GHC] #12816: Link error with GOLD linker In-Reply-To: <045.624e6d1d1f17d355af2801ec56e977b0@haskell.org> References: <045.624e6d1d1f17d355af2801ec56e977b0@haskell.org> Message-ID: <060.89c29716c9382b0d0aaae85ce1f140d1@haskell.org> #12816: Link error with GOLD linker -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.1 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2695 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2695 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 23:39:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 23:39:19 -0000 Subject: [GHC] #7679: Regression in -fregs-graph performance In-Reply-To: <047.9e26897513125de7441d596a4b30ee54@haskell.org> References: <047.9e26897513125de7441d596a4b30ee54@haskell.org> Message-ID: <062.3cd9acfda1d9497f9d2e78df43103e5c@haskell.org> #7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => Comment: This isn't an immediate priority (although tjakway has expressed interest in picking it up). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 23:41:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 23:41:21 -0000 Subject: [GHC] #12757: Compiled program segfaults at -O1 In-Reply-To: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> References: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> Message-ID: <057.3759a3e25334939183a271cc8caada7d@haskell.org> #12757: Compiled program segfaults at -O1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11312, #12585 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: #11158 has been resolved. The fix was merged to `ghc-8.0` as 967dd5c9f59e532fe9d6484888a2bae7d02fba11. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 23:42:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 23:42:17 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.c12286ed443dbe29b454617360bb84f1@haskell.org> #12759: Latest Debian GCC breaks GHC -----------------------------+---------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as d421a7e22e0be3de32376970b8c38ec308f959da. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 23:42:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 23:42:59 -0000 Subject: [GHC] #11959: Importing doubly exported pattern synonym and associated pattern synonym panics In-Reply-To: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> References: <046.6ec5a340ae5bc3bfa0a1a054dcc8ecc7@haskell.org> Message-ID: <061.1001f2ab885f134f8c9b8f73a4edd749@haskell.org> #11959: Importing doubly exported pattern synonym and associated pattern synonym panics -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2132, Wiki Page: | Phab:D2133 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: Bumping off to 8.0.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 11 23:44:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 11 Nov 2016 23:44:52 -0000 Subject: [GHC] #12100: GHC 8.0.1 build segmentation fault in haddock In-Reply-To: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> References: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> Message-ID: <062.7dc19123e432e83e5f4094f7c9b64720@haskell.org> #12100: GHC 8.0.1 build segmentation fault in haddock -------------------------------------+------------------------------------- Reporter: ilovezfs | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11744, #11951 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: Bumping off to 8.0.3 pending feedback from the submitter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 00:01:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 00:01:29 -0000 Subject: [GHC] #12820: Regression around pattern synonyms and higher-rank types In-Reply-To: <047.8ff9e83595f6e43eb23a94e0b79eda39@haskell.org> References: <047.8ff9e83595f6e43eb23a94e0b79eda39@haskell.org> Message-ID: <062.b9d30550bef929c1810e8d56d43a5e29@haskell.org> #12820: Regression around pattern synonyms and higher-rank types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What makes you say it's correct? Consier {{{ f :: String -> Int f ( (\_ -> id) -> (x :: forall a. a->a) ) = 3 }}} This too is rejected with {{{ T12820.hs:10:20: error: * Couldn't match expected type `a0 -> a0' with actual type `forall a. a -> a' * When checking that the pattern signature: forall a. a -> a fits the type of its context: a0 -> a0 In the pattern: x :: forall a. a -> a In the pattern: (\ _ -> id) -> (x :: forall a. a -> a) }}} Suppose we are inferring the type of `f -> p`. W could either * Infer the type of `f`, and use that to check the type of pattern `p`, or * Infer the type of `p`, and use that to check the type of `f` (actually it only fixes teh result type of `f` but still. We use the first alternative, but perhpas the second makes more sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 00:34:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 00:34:27 -0000 Subject: [GHC] #12827: RTS linker: handle 64-bit symbol table in archives Message-ID: <045.060ac6e251408a198497a7d49be67fae@haskell.org> #12827: RTS linker: handle 64-bit symbol table in archives -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: linker | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D2697 | Wiki Page: -------------------------------------+------------------------------------- The RTS linker should skip 64-bit symbol table entries in archives just like it skips 32-bit ones. See the original report thread on ghc-devs: https://mail.haskell.org/pipermail/ghc-devs/2016-November/013210.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 00:34:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 00:34:43 -0000 Subject: [GHC] #12827: RTS linker: handle 64-bit symbol table in archives In-Reply-To: <045.060ac6e251408a198497a7d49be67fae@haskell.org> References: <045.060ac6e251408a198497a7d49be67fae@haskell.org> Message-ID: <060.375313e958e10281a70503af9c448f6c@haskell.org> #12827: RTS linker: handle 64-bit symbol table in archives -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: linker Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2697 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 01:50:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 01:50:41 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2312828=3A_Generalize_functions_from_Data?= =?utf-8?b?Lk1heWJlICjigJhjYXRNYXliZXPigJksIOKAmG1hcE1heWJl4oCZ?= =?utf-8?q?=29?= Message-ID: <051.dbb4ef05364e6c4421b04dd57fb22742@haskell.org> #12828: Generalize functions from Data.Maybe (‘catMaybes’, ‘mapMaybe’) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Opening a ticket for discussion. As mentioned in [https://www.reddit.com/r/haskell/comments/2y2pe5/shouldnt_ftp_propagate_changes_over_the_entire/cp6vpb4/ this comment], more functions can be generalized to `Foldable` {{{#!hs catMaybes :: Foldable f => f (Maybe a) -> [a] mapMaybe :: Foldable f => (a -> Maybe b) -> (f a -> [b]) listToMaybe :: Foldable f => f a -> Maybe a }}} I think `catMaybes` and `mapMaybe` are fine candidates. The comment offers more extreme changes, {{{#!hs catMaybes :: (Foldable f, Foldable g) => Foldable f => f (g a) -> [a] mapMaybes :: (Foldable f, Foldable g) => (a -> f b) -> (f a -> [b]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 01:51:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 01:51:50 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312828=3A_Generalize_functions_from_?= =?utf-8?b?RGF0YS5NYXliZSAo4oCYY2F0TWF5YmVz4oCZLCDigJhtYXBNYXli?= =?utf-8?b?ZeKAmSk=?= In-Reply-To: <051.dbb4ef05364e6c4421b04dd57fb22742@haskell.org> References: <051.dbb4ef05364e6c4421b04dd57fb22742@haskell.org> Message-ID: <066.13ba04d7eb4005114d62e6520917a80b@haskell.org> #12828: Generalize functions from Data.Maybe (‘catMaybes’, ‘mapMaybe’) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -16,1 +16,1 @@ - mapMaybes :: (Foldable f, Foldable g) => (a -> f b) -> (f a -> [b]) + mapMaybe :: (Foldable f, Foldable g) => (a -> f b) -> (f a -> [b]) New description: Opening a ticket for discussion. As mentioned in [https://www.reddit.com/r/haskell/comments/2y2pe5/shouldnt_ftp_propagate_changes_over_the_entire/cp6vpb4/ this comment], more functions can be generalized to `Foldable` {{{#!hs catMaybes :: Foldable f => f (Maybe a) -> [a] mapMaybe :: Foldable f => (a -> Maybe b) -> (f a -> [b]) listToMaybe :: Foldable f => f a -> Maybe a }}} I think `catMaybes` and `mapMaybe` are fine candidates. The comment offers more extreme changes, {{{#!hs catMaybes :: (Foldable f, Foldable g) => Foldable f => f (g a) -> [a] mapMaybe :: (Foldable f, Foldable g) => (a -> f b) -> (f a -> [b]) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 01:54:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 01:54:27 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312828=3A_Generalize_functions_from_?= =?utf-8?b?RGF0YS5NYXliZSAo4oCYY2F0TWF5YmVz4oCZLCDigJhtYXBNYXli?= =?utf-8?b?ZeKAmSk=?= In-Reply-To: <051.dbb4ef05364e6c4421b04dd57fb22742@haskell.org> References: <051.dbb4ef05364e6c4421b04dd57fb22742@haskell.org> Message-ID: <066.2100e3c8ac0e783f9ec06bbba984c4cc@haskell.org> #12828: Generalize functions from Data.Maybe (‘catMaybes’, ‘mapMaybe’) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -15,1 +15,1 @@ - catMaybes :: (Foldable f, Foldable g) => Foldable f => f (g a) -> [a] + catMaybes :: (Foldable f, Foldable g) => f (g a) -> [a] New description: Opening a ticket for discussion. As mentioned in [https://www.reddit.com/r/haskell/comments/2y2pe5/shouldnt_ftp_propagate_changes_over_the_entire/cp6vpb4/ this comment], more functions can be generalized to `Foldable` {{{#!hs catMaybes :: Foldable f => f (Maybe a) -> [a] mapMaybe :: Foldable f => (a -> Maybe b) -> (f a -> [b]) listToMaybe :: Foldable f => f a -> Maybe a }}} I think `catMaybes` and `mapMaybe` are fine candidates. The comment offers more extreme changes, {{{#!hs catMaybes :: (Foldable f, Foldable g) => f (g a) -> [a] mapMaybe :: (Foldable f, Foldable g) => (a -> f b) -> (f a -> [b]) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 02:15:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 02:15:44 -0000 Subject: =?utf-8?b?W0dIQ10gIzEyODI5OiBNdWx0aWxpbmUgaW5wdXQgKOKAmDpzZXQg?= =?utf-8?q?+m=E2=80=99=29_terminated_by_trailing_whitespace?= Message-ID: <051.a109ce7a74c6e43c42aebe16ca0ed026@haskell.org> #12829: Multiline input (‘:set +m’) terminated by trailing whitespace -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set +m Prelude> let Prelude| a :: Int Prelude| a = 5 Prelude| Prelude> }}} works fine with [https://downloads.haskell.org/~ghc/master/users- guide/ghci.html#multiline-input multiline input], but if you add one trailing space it immediately terminates the input {{{ Prelude> let Prelude| a :: Int␣ :11:1: error: The type signature for ‘a’ lacks an accompanying binding }}} I don't know if this is the desired behavior but this means I can't copy/paste code into GHCi that has a trailing whitespace. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 03:32:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 03:32:45 -0000 Subject: [GHC] #12812: Debugging functions should throw warnings In-Reply-To: <051.eab9c65f72de3691a7e42c099484ab94@haskell.org> References: <051.eab9c65f72de3691a7e42c099484ab94@haskell.org> Message-ID: <066.a84fa7992dd2ee56204321f8d61c9e32@haskell.org> #12812: Debugging functions should throw warnings -------------------------------------+------------------------------------- Reporter: siddhanathan | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2cfbee896be349d16238c044475c7c15cfb9b3f2/ghc" 2cfbee89/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2cfbee896be349d16238c044475c7c15cfb9b3f2" rts: Fix build when linked with gold As reported in #12812, the runtime system fails to build when linked with gold due to a missing dependency on libpthread. Additionally, rts/package.conf.in uses the WORD_SIZE_IN_BITS macro defined by MachDeps.h, which it does not #include. Fix this. Test Plan: Validate with gold linker Reviewers: hsyl20, austin, erikd, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2695 GHC Trac Issues: #12816 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 03:32:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 03:32:45 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.22fd54eafdcbe86eb1acb219a0660097@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7eae862a5af185e918aa29d63a7a9484292513e4/ghc" 7eae862a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7eae862a5af185e918aa29d63a7a9484292513e4" ghc-pkg: Munge dynamic library directories Otherwise we end up looking in the wrong place for dynamic libraries on Windows. This addresses a regression introduced by D2611. See #12479. Test Plan: validate across platforms Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2640 GHC Trac Issues: #12479 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 03:32:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 03:32:45 -0000 Subject: [GHC] #12816: Link error with GOLD linker In-Reply-To: <045.624e6d1d1f17d355af2801ec56e977b0@haskell.org> References: <045.624e6d1d1f17d355af2801ec56e977b0@haskell.org> Message-ID: <060.aee877ab19e932c2b921ed63ee26446f@haskell.org> #12816: Link error with GOLD linker -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.1 (Linking) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2695 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2cfbee896be349d16238c044475c7c15cfb9b3f2/ghc" 2cfbee89/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2cfbee896be349d16238c044475c7c15cfb9b3f2" rts: Fix build when linked with gold As reported in #12812, the runtime system fails to build when linked with gold due to a missing dependency on libpthread. Additionally, rts/package.conf.in uses the WORD_SIZE_IN_BITS macro defined by MachDeps.h, which it does not #include. Fix this. Test Plan: Validate with gold linker Reviewers: hsyl20, austin, erikd, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2695 GHC Trac Issues: #12816 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 03:39:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 03:39:47 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312828=3A_Generalize_functions_from_?= =?utf-8?b?RGF0YS5NYXliZSAo4oCYY2F0TWF5YmVz4oCZLCDigJhtYXBNYXli?= =?utf-8?b?ZeKAmSk=?= In-Reply-To: <051.dbb4ef05364e6c4421b04dd57fb22742@haskell.org> References: <051.dbb4ef05364e6c4421b04dd57fb22742@haskell.org> Message-ID: <066.de65814ade4d7ef4fb177f1e4306c341@haskell.org> #12828: Generalize functions from Data.Maybe (‘catMaybes’, ‘mapMaybe’) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: The libraries list is the proper place for this kind of discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 03:49:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 03:49:16 -0000 Subject: [GHC] #12816: Link error with GOLD linker In-Reply-To: <045.624e6d1d1f17d355af2801ec56e977b0@haskell.org> References: <045.624e6d1d1f17d355af2801ec56e977b0@haskell.org> Message-ID: <060.05c393c4be270eed3253c671c6a9307d@haskell.org> #12816: Link error with GOLD linker -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.1 (Linking) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2695 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as b622017eb8b71655f9a04ad4804aee0d0e1abd41. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 03:50:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 03:50:05 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.19ba486d826dd5c9cf410e7ab10c97d7@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): comment:51 merged to `ghc-8.0` as e7017ca8b02ad7abb7c6cd9100e44fb8a215985f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 05:12:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 05:12:38 -0000 Subject: [GHC] #12807: GHC is too verbose by default (source/object paths) In-Reply-To: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> References: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> Message-ID: <060.bee39920dc1328dde30778d8acee60ad@haskell.org> #12807: GHC is too verbose by default (source/object paths) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2679 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"587dcccfdfa7a319e27300a4f3885071060b1f8e/ghc" 587dcccf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="587dcccfdfa7a319e27300a4f3885071060b1f8e" Make default output less verbose (source/object paths) Reviewers: simonmar, mpickering, austin, bgamari Reviewed By: bgamari Subscribers: mpickering, nomeata, thomie Differential Revision: https://phabricator.haskell.org/D2679 GHC Trac Issues: #12807 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 06:38:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 06:38:45 -0000 Subject: [GHC] #12830: ARM crosscompile panic Message-ID: <047.3fdea1a051432822f033c3c087bc879e@haskell.org> #12830: ARM crosscompile panic -------------------------------------+------------------------------------- Reporter: skovalev | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: arm, | Operating System: Unknown/Multiple crosscompile, panic | Type of failure: Compile-time Architecture: arm | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While building yesod-based project for ARM architecture I have faced with error: {{{ ghc: panic! (the 'impossibel' happened) (GHC version 8.0.1 for arm-unknown-linux): fint_tycon Block [] }}} My yesod packages (inside cabal-sandbox on path `.cabal-sandbox/lib/arm- linux-ghc-8.0.1`): * yesod-1.4.3 * yesod-auth-1.4.13.5 * yesod-core-1.4.25 * yesod-form-1.4.8 * yesod-newsfeed-1.6.4 * yesod-persistent-1.4.0.6 * yesod-static-1.5.0.5 My building machine is `Debian 4.7.8-1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 06:39:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 06:39:27 -0000 Subject: [GHC] #12830: ARM crosscompile panic In-Reply-To: <047.3fdea1a051432822f033c3c087bc879e@haskell.org> References: <047.3fdea1a051432822f033c3c087bc879e@haskell.org> Message-ID: <062.65b06375e3f3534b20ee97773aca9553@haskell.org> #12830: ARM crosscompile panic -------------------------------------+------------------------------------- Reporter: skovalev | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: arm, | crosscompile, panic Operating System: Linux | Architecture: arm Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by skovalev): * os: Unknown/Multiple => Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 06:44:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 06:44:00 -0000 Subject: [GHC] #12831: Fulltext search SQL error in Trac Message-ID: <047.07e781ecb355c1a9d8abfc5da1b4d2b1@haskell.org> #12831: Fulltext search SQL error in Trac -------------------------------------+------------------------------------- Reporter: skovalev | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have faced with `Trac` errors while searching next queries: * `ghc: panic!` * `the 'impossible' happened` * `Report execution failed` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 06:45:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 06:45:33 -0000 Subject: [GHC] #12831: Fulltext search SQL error in Trac In-Reply-To: <047.07e781ecb355c1a9d8abfc5da1b4d2b1@haskell.org> References: <047.07e781ecb355c1a9d8abfc5da1b4d2b1@haskell.org> Message-ID: <062.9fcdc15d74509e2351e304193ac1d6c9@haskell.org> #12831: Fulltext search SQL error in Trac -------------------------------------+------------------------------------- Reporter: skovalev | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by skovalev): * Attachment "trac-error.jpg" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 09:30:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 09:30:45 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.6add72d23097cc16d18595acec99fe3c@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alkar): Replying to [comment:33 bgamari]: > As expected disabling parallel GC with `+RTS -qg` drastically reduces system time due to reduced synchronization overhead. Wow! Just tried `+RTS -N -qg` and brings performance back in the sane world! Now it's something like {{{ real 0m0.269s user 0m0.232s sys 0m0.104s }}} That is, 30-40% slower than without `-N`. A real-life example of a program where I'd want a long single thread computation with `-N` turned on is a faster analog of `fgrep -f patterns.txt input1 ... inputN`: 1. Read all lines from `patterns.txt` into a set. 2. In parallel for each input file, `filter (\str -> member str set) . lines` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 19:38:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 19:38:47 -0000 Subject: [GHC] #12807: GHC is too verbose by default (source/object paths) In-Reply-To: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> References: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> Message-ID: <060.957acdc5763ddd338bff04abf63113a4@haskell.org> #12807: GHC is too verbose by default (source/object paths) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2679 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 22:14:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 22:14:14 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.ae7d46fe7363f0e22d2efc6977e40a93@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:34 alkar]: > A real-life example of a program where I'd want a long single thread computation with `-N` turned on is a faster analog of `fgrep -f patterns.txt input1 ... inputN`: > > 1. Read all lines from `patterns.txt` into a set. > 2. In parallel for each input file, `filter (\str -> member str set) . lines` I'm afraid I don't understand; this would be a multi-threaded computation, would it not? In general there are very real costs to synchronization, especially across cores on large machines. The performance hit that you report above sounds a bit high and it would be nice to bring it down. Perhaps you could do some digging to see where this time is going? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 22:28:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 22:28:42 -0000 Subject: [GHC] #12832: GHC infers too simplified contexts Message-ID: <046.c1f3ff2a9ca4d830d3e52f2f57c4f3ec@haskell.org> #12832: GHC infers too simplified contexts -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm almost sure it was working well in GHC 7.*. Let's consider this simple example: {{{ module Main where import Prelude class Monad m => Foo m class Monad m => Bar m class Monad m => Baz m data IM a data I impossible = error "impossible" class Test m a where test :: a -> m () instance {-# OVERLAPPABLE #-} (Foo m, Bar m, Baz m) => Test m a where test _ = return () instance {-# OVERLAPPABLE #-} Test IM a where test = impossible class Run m a where run :: a -> m () main :: IO () main = return () }}} it compiles and runs fine. What should happen when we add the following def? {{{ instance Run m Int where run = test }}} We SHOULD get an error that there is `No instance for (Test m Int) arising from a use of ‘test’`. Instead we get very strange one `No instance for (Foo m) arising from a use of ‘test’.` If we add it, we get the next one `No instance for (Bar m) arising from a use of ‘test’.` etc ... If we comment out the first overlappable instance, we get proper error about missing `Test m Int` context. In fact if we add context `Test m Int` it works in every case, only the inferred error is just wrong. This is a serious problem and here is why. Imagine that we create an API for end-user and we give him the `test` function. Moreover, we know that expanding the context would not bring any further info unless `m` is known. If we create such "impossible" instances like in the example, user will get a very simple error message about a missing context. Right now user gets a big error stack about missing expanded contexts instead of simple one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 22:35:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 22:35:29 -0000 Subject: [GHC] #12832: GHC infers too simplified contexts In-Reply-To: <046.c1f3ff2a9ca4d830d3e52f2f57c4f3ec@haskell.org> References: <046.c1f3ff2a9ca4d830d3e52f2f57c4f3ec@haskell.org> Message-ID: <061.fe2c216ae9532f491c43318f13194f8b@haskell.org> #12832: GHC infers too simplified contexts -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by danilo2: @@ -5,0 +5,5 @@ + + {-# LANGUAGE FlexibleInstances #-} + {-# LANGUAGE MultiParamTypeClasses #-} + {-# LANGUAGE EmptyDataDecls #-} + New description: I'm almost sure it was working well in GHC 7.*. Let's consider this simple example: {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE EmptyDataDecls #-} module Main where import Prelude class Monad m => Foo m class Monad m => Bar m class Monad m => Baz m data IM a data I impossible = error "impossible" class Test m a where test :: a -> m () instance {-# OVERLAPPABLE #-} (Foo m, Bar m, Baz m) => Test m a where test _ = return () instance {-# OVERLAPPABLE #-} Test IM a where test = impossible class Run m a where run :: a -> m () main :: IO () main = return () }}} it compiles and runs fine. What should happen when we add the following def? {{{ instance Run m Int where run = test }}} We SHOULD get an error that there is `No instance for (Test m Int) arising from a use of ‘test’`. Instead we get very strange one `No instance for (Foo m) arising from a use of ‘test’.` If we add it, we get the next one `No instance for (Bar m) arising from a use of ‘test’.` etc ... If we comment out the first overlappable instance, we get proper error about missing `Test m Int` context. In fact if we add context `Test m Int` it works in every case, only the inferred error is just wrong. This is a serious problem and here is why. Imagine that we create an API for end-user and we give him the `test` function. Moreover, we know that expanding the context would not bring any further info unless `m` is known. If we create such "impossible" instances like in the example, user will get a very simple error message about a missing context. Right now user gets a big error stack about missing expanded contexts instead of simple one. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 12 22:36:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 12 Nov 2016 22:36:19 -0000 Subject: [GHC] #12832: GHC infers too simplified contexts In-Reply-To: <046.c1f3ff2a9ca4d830d3e52f2f57c4f3ec@haskell.org> References: <046.c1f3ff2a9ca4d830d3e52f2f57c4f3ec@haskell.org> Message-ID: <061.130546c44ec539aa1f75e425ab26cf8a@haskell.org> #12832: GHC infers too simplified contexts -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by danilo2: @@ -5,1 +5,1 @@ - + {-# LANGUAGE NoMonomorphismRestriction #-} New description: I'm almost sure it was working well in GHC 7.*. Let's consider this simple example: {{{ {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE EmptyDataDecls #-} module Main where import Prelude class Monad m => Foo m class Monad m => Bar m class Monad m => Baz m data IM a data I impossible = error "impossible" class Test m a where test :: a -> m () instance {-# OVERLAPPABLE #-} (Foo m, Bar m, Baz m) => Test m a where test _ = return () instance {-# OVERLAPPABLE #-} Test IM a where test = impossible class Run m a where run :: a -> m () main :: IO () main = return () }}} it compiles and runs fine. What should happen when we add the following def? {{{ instance Run m Int where run = test }}} We SHOULD get an error that there is `No instance for (Test m Int) arising from a use of ‘test’`. Instead we get very strange one `No instance for (Foo m) arising from a use of ‘test’.` If we add it, we get the next one `No instance for (Bar m) arising from a use of ‘test’.` etc ... If we comment out the first overlappable instance, we get proper error about missing `Test m Int` context. In fact if we add context `Test m Int` it works in every case, only the inferred error is just wrong. This is a serious problem and here is why. Imagine that we create an API for end-user and we give him the `test` function. Moreover, we know that expanding the context would not bring any further info unless `m` is known. If we create such "impossible" instances like in the example, user will get a very simple error message about a missing context. Right now user gets a big error stack about missing expanded contexts instead of simple one. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 04:34:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 04:34:25 -0000 Subject: [GHC] #12833: GHCi Message-ID: <051.4ded213ac1a58670bab81411457b3c2f@haskell.org> #12833: GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In multiline mode you can define a multi-line Haskell function: {{{ Prelude> :set +m Prelude> let Prelude| f :: Int -> Int Prelude| f 0 = 0 Prelude| f n = n - 1 Prelude| Prelude> }}} Is there a reason why it couldn't work with other things like {{{ Prelude> :set -XPatternSynonyms Prelude> let Prelude| pattern A = 'A' Prelude| :27:1: error: Illegal pattern synonym declaration for ‘A’ Pattern synonym declarations are only valid at top level }}} {{{ Prelude> let Prelude| data A Prelude| = B Prelude| | C Int Prelude| :30:1: error: parse error (possibly incorrect indentation or mismatched brackets) }}} {{{ Prelude> let Prelude| type A = Int Prelude| :48:1: error: parse error (possibly incorrect indentation or mismatched brackets) }}} couldn't work, similar to how they work with `:{` and `:}`: {{{ Prelude> :{ Prelude| data A Prelude| = B Prelude| | C Int Prelude| :} Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 07:27:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 07:27:23 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.4c82c953c7a28bd8d9cb928eb0147e53@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alkar): Here is a difference between outputs for `+RTS -s` and `+RTS -N -qg -s`: https://i.imgur.com/8S5brky.png In my grep-like example, the first step is single-threaded (in the sense that I don't do any forkIO): > 1. Read all lines from patterns.txt into a set. And the pattern file can be quite large (this is why I'm doing it in a single process instead of multiprocessing), so the less penalty I get by using `-N` the better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 11:17:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 11:17:15 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.62bae176907127ff4fb595785d13849e@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:18 rwbarton]: > > But currently GHC's dynamic linker mimics the behavior of the (static) RTS linker and would load `libz.so` before it loads `libHSzlib<...>.so`. > > Do you know why this is? In `compiler/ghci/Linker.hs` `linkPackage` all dependencies of a package are linked before we even learn whether the package is in a shared library or an archive. That is probably the reason, but I don't know for sure. > If we could just not do this, it might fix this issue, right? Yes, that would fix this issue. > > I'm going to reopen this but mark as infoneeded, though I don't mind much if it ends up being closed again. Hmm, should I prepare a patch that implements the fix described here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 14:04:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 14:04:27 -0000 Subject: [GHC] #12834: GHC panic: while printing Non type-variable argument Message-ID: <045.71ca96c4130d88715bb92629825dd9d0@haskell.org> #12834: GHC panic: while printing Non type-variable argument -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE GADTs, TypeFamilies, DataKinds, TypeOperators, MultiParamTypeClasses, UndecidableInstances, UndecidableSuperClasses, FlexibleInstances, PolyKinds, KindSignatures #-} import GHC.Exts (Constraint) newtype I a = I a data NP :: (k -> *) -> [k] -> * where Nil :: NP f '[] (:*) :: f x -> NP f xs -> NP f (x ': xs) infixr 5 :* class (AllF f xs, SListI xs) => All (f :: k -> Constraint) (xs :: [k]) instance (AllF f xs, SListI xs) => All f xs data SList :: [k] -> * where SNil :: SList '[] SCons :: SListI xs => SList (x ': xs) class SListI (xs :: [k]) where -- | Get hold of the explicit singleton (that one can then -- pattern match on). sList :: SList xs instance SListI '[] where sList = SNil instance SListI xs => SListI (x ': xs) where sList = SCons -- | Type family used to implement 'All'. -- type family AllF (c :: k -> Constraint) (xs :: [k]) :: Constraint type instance AllF _c '[] = () type instance AllF c (x ': xs) = (c x, All c xs) semigroup :: All ((~) (Maybe Int)) xs => NP I xs -> NP I xs -> NP I xs semigroup = undefined }}} Causes {{{ ghc-failure-all.hs:37:14: error: • Non type-variable argumentghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): print_equality ~ }}} If `AllF` is used directly in the definition of `sappend`, there is no error whatsoever. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 14:40:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 14:40:37 -0000 Subject: [GHC] #9214: UNPACK support for sum types In-Reply-To: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> References: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> Message-ID: <062.a35e209582c2143d097e82adf35b163b@haskell.org> #9214: UNPACK support for sum types -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: osa1 Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1540 Wiki Page: UnpackedSumTypes | Phab:D1559 Phab:D2259 -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) * differential: Phab:D1540 Phab:D1559 => Phab:D1540 Phab:D1559 Phab:D2259 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 14:42:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 14:42:36 -0000 Subject: [GHC] #12834: GHC panic: while printing Non type-variable argument In-Reply-To: <045.71ca96c4130d88715bb92629825dd9d0@haskell.org> References: <045.71ca96c4130d88715bb92629825dd9d0@haskell.org> Message-ID: <060.eeeec73dd2666727365a313657477fbf@haskell.org> #12834: GHC panic: while printing Non type-variable argument -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12401 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by phadej): * status: new => closed * resolution: => duplicate * related: => #12401 * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 16:06:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 16:06:11 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.e269ab6ed3d4338006e0ba7aecb7059a@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:36 alkar]: > > 1. Read all lines from patterns.txt into a set. > > And the pattern file can be quite large (this is why I'm doing it in a single process instead of multiprocessing), so the less penalty I get by using `-N` the better. Keep in mind that this doesn't necessarily mean that you need a single process. With the coming 8.2 release it will be possible to share large data structures like your patterns set in a single `mmap`'d shared memory block using compact regions. Given the challenges of ensuring good scaling with our garbage collector you may want to look into this approach. That being said, it would be great if someone (perhaps you!) could look into why the system time numbers you report are so high. 30% runtime hit on a program which uses only one capability and no parallel GC seems quite high. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 20:21:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 20:21:00 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.a5da94246cf046640e669fe85fa141cd@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Note that this bug was "fixed" in https://git.haskell.org/ghc.git/commitdiff/f4a14d6c535bdf52b19f441fe185ea13d62fdc24 (see https://ghc.haskell.org/trac/ghc/ticket/12785) by replacing `substTy` with `substTyUnchecked` in `new_meta_tv_x` (TcMType.hs). See below. Here is my understanding of the problem. The panic happens for example for this call: {{{ :set -XPolyKinds class C a where f :: a b c :type f }}} Unique names have been simplified for readability. The original type (all skolem variables) is the following: {{{ ∀ {kf} {kh} (a9 ∷ kf → kh → ★). C kf kh a9 ⇒ ∀ (ba ∷ kf) (cb ∷ kh). a9 ba cb }}} The outer call to deeply instantiate substitutes `kf -> kj, kh -> kk, a9 -> al` where the new variables are all tau. Theta becomes `C kj kk al` and we call `deeplyinstantiate` now on `∀ (ba ∷ kj) (cb ∷ kk). al ba cb` where it attempts to substitute `ba -> bp, cb -> cq` Substitutions are created by `newMetaTyVars` which is defined as follows. {{{ newMetaTyVars = mapAccumLM newMetaTyVarX emptyTCvSubst -- emptyTCvSubst has an empty in-scope set, but that's fine here -- Since the tyvars are freshly made, they cannot possibly be -- captured by any existing for-alls. }}} Note the comment: `kj` and `kk` are free variables in the range of the upcoming substitutions but are not part of the in-scope set. They were however "freshly made" in the outer call. Now `newMetaTyVarX` calls `new_meta_tv_x` which includes this line (before SPJ's change): {{{ kind = substTy subst (tyVarKind tv) }}} Note that `subst` at this point contains the substitutions made prior to the current one, and so is originally empty. So `substTy` succeeds on `ba -> bp` (with kind `kj`), and `bp` and `kj` are added to the in-scope set. However on the second attempt `cb -> cq` (with kind `kk`), since `subst` is now non-empty, `substTy` calls `checkValidSubst` with arguments `subst` and `[kk]`. `checkValidSubst` does two checks, the second of which (`tysColsFVsInScope`) fails. This checks that `kk` is in the in-scope set which consists of `{kj, bp}`, and thus the panic. Although I understand the problem, I don't know the best way to fix it. Certainly retaining `kk` and the others in the in-scope set for the recursive call to `deeplyInstantiate` would be sufficient, but I'm not sure why it's necessary. No real substitution is being done for `kk` at this point, so it is not clear why we need to check the substitution invariant. And even if there was a substitution since the variables are fresh there should no risk of capture during alpha-renaming. While I was investigating this, SPJ made the change mentioned at the top of this note, which is: {{{ kind = substTyUnchecked subst (tyVarKind tv) -- Unchecked because we call newMetaTyVarX from -- tcInstBinderX, which is called from tc_infer_args -- which does not yet take enough trouble to ensure -- the in-scope set is right; e.g. Trac #12785 trips -- if we use substTy here }}} This indicates that there is a more wide-spread problem, so I don't want to make any changes that would break something else. I'm happy to investigate fixing the larger problem, however. In any case I'd appreciate some guidance at this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 22:21:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 22:21:24 -0000 Subject: [GHC] #12822: Cleanup GHC verbosity flags In-Reply-To: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> References: <045.4d9fca09f9ab247dee7b220b1a06e9a9@haskell.org> Message-ID: <060.1cf2e12033dc0f4a7489ca94159c19c7@haskell.org> #12822: Cleanup GHC verbosity flags -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | newcomer,flags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 22:25:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 22:25:23 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.93261df64216a80588e5e34a80245cbb@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549, #12024, #12697, | #12510 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6c0f10fac767c49b65ed71e8eb8e78ca4f9062d5/ghc" 6c0f10f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c0f10fac767c49b65ed71e8eb8e78ca4f9062d5" Kill Type pretty-printer Here we consolidate the pretty-printing logic for types in IfaceType. We need IfaceType regardless and the printer for Type can be implemented in terms of that for IfaceType. See #11660. Note that this is very much a work-in-progress. Namely I still have yet to ponder how to ease the hs-boot file situation, still need to rip out more dead code, need to move some of the special cases for, e.g., `*` to the IfaceType printer, and need to get it to validate. That being said, it comes close to validating as-is. Test Plan: Validate Reviewers: goldfire, austin Subscribers: goldfire, thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2528 GHC Trac Issues: #11660 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 22:36:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 22:36:45 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.0d04676e550bbae01f87f2fbb99c97bc@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12550, #12447, | Differential Rev(s): Phab:D2528 #11786, #11549, #12024, #12697, | #12510 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: It has been done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 22:59:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 22:59:25 -0000 Subject: [GHC] #12024: GHC leaks GHC.Prim.~# into type In-Reply-To: <051.7eb6150e403ea080535783c5107e00b5@haskell.org> References: <051.7eb6150e403ea080535783c5107e00b5@haskell.org> Message-ID: <066.176744703ab2a146812cc42508658871@haskell.org> #12024: GHC leaks GHC.Prim.~# into type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T12024 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => T12024 * status: new => patch Comment: This has been fixed with #11660. Testcase in Phab:D2702. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 22:59:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 22:59:56 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.52eae94b4535f76a0af23b5cd501bac2@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: This has been fixed along with #11660. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 23:20:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 23:20:12 -0000 Subject: [GHC] #12834: GHC panic: while printing Non type-variable argument In-Reply-To: <045.71ca96c4130d88715bb92629825dd9d0@haskell.org> References: <045.71ca96c4130d88715bb92629825dd9d0@haskell.org> Message-ID: <060.857adcafc593151eaf55952f791440da@haskell.org> #12834: GHC panic: while printing Non type-variable argument -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12041 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: #12401 => #12041 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 23:43:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 23:43:41 -0000 Subject: [GHC] #11219: Implement fine-grained `-Werror=...` facility In-Reply-To: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> References: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> Message-ID: <057.93eb8e0b49535c58cfeb4cf20b25bf88@haskell.org> #11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11796 | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by zyla): * Attachment "fine-grained-werror.patch" added. Implementation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 13 23:44:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 13 Nov 2016 23:44:33 -0000 Subject: [GHC] #11219: Implement fine-grained `-Werror=...` facility In-Reply-To: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> References: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> Message-ID: <057.28065a179d8bc4322d9347a9d26e44ea@haskell.org> #11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11796 | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by zyla): I started working on this, patch attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 04:46:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 04:46:42 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.5d2911df9acbbbdbd65fd31560709460@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2554, Wiki Page: | Phab:D2605 -------------------------------------+------------------------------------- Comment (by akio): My patch (Phab:D2605) causes some compiler perf regressions. This happens because {{{ f x = ... "foo"# ... }}} now gets transformed into {{{ foo = "foo"# f x = ... foo ... }}} and this means a larger code size. For example, on `perf/compiler/T1969`, the `peak_megabytes_allocated` goes from 63 to 68 (a 8% increase), the code size (in terms of the `Term` component of `CoreStats`) goes from 12603 to 13271 (a 10% increase), and this is fully explained by the above effect, which increases the code size by 2 for each top-level string literal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 07:09:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 07:09:02 -0000 Subject: [GHC] #12830: ARM crosscompile panic In-Reply-To: <047.3fdea1a051432822f033c3c087bc879e@haskell.org> References: <047.3fdea1a051432822f033c3c087bc879e@haskell.org> Message-ID: <062.12212e08f3c7f298c4614f2e668ee20b@haskell.org> #12830: ARM crosscompile panic -------------------------------------+------------------------------------- Reporter: skovalev | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: arm, | crosscompile, panic Operating System: Linux | Architecture: arm Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by skovalev): I have succeed with **ghc-7.10.3-10** and **cabal 1.22**. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 08:35:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 08:35:42 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.e86858025c28d8868128af9034990519@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2554, Wiki Page: | Phab:D2605 -------------------------------------+------------------------------------- Comment (by simonpj): > this means a larger code size. Why?? In both cases I'd ultimately expect to see a top-level machine-code label for a literal string, and a reference to that label in the compiled code. I see no reason for increased code size, or increased bytes- allocated. Can you explain? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 13:26:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 13:26:06 -0000 Subject: [GHC] #12835: ghc: panic! (the 'impossible' happened) - find_tycon Message-ID: <049.4cfcbf64ed66fc1ccc0556df2b0d2146@haskell.org> #12835: ghc: panic! (the 'impossible' happened) - find_tycon -------------------------------------+------------------------------------- Reporter: mrijkeboer | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ stack build server-0.0.0.1: build -- While building package server-0.0.0.1 using: /home/martijn/.stack/setup-exe-cache/x86_64-linux/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:server exe:server --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/martijn/server/.stack- work/logs/server-0.0.0.1.log Preprocessing library server-0.0.0.1... [20 of 20] Compiling Application ( src/Application.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Application.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): find_tycon YesodSubRunnerEnv [] 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 Nov 14 13:32:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 13:32:25 -0000 Subject: [GHC] #12835: ghc: panic! (the 'impossible' happened) - find_tycon In-Reply-To: <049.4cfcbf64ed66fc1ccc0556df2b0d2146@haskell.org> References: <049.4cfcbf64ed66fc1ccc0556df2b0d2146@haskell.org> Message-ID: <064.3c4bd085d671559e53437673b7cd19ce@haskell.org> #12835: ghc: panic! (the 'impossible' happened) - find_tycon -------------------------------------+------------------------------------- Reporter: mrijkeboer | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate Comment: I'm fairly sure this is a duplicate but without any reproduction instructions there is no way for me to verify this! Please reopen this ticket with [https://ghc.haskell.org/trac/ghc/wiki/ReportABug#Fulldescription:whatinformationtoprovideinthebodyofyourbugreport more details] if it isn't fixed in the 8.0.2 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 13:56:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 13:56:46 -0000 Subject: [GHC] #12820: Regression around pattern synonyms and higher-rank types In-Reply-To: <047.8ff9e83595f6e43eb23a94e0b79eda39@haskell.org> References: <047.8ff9e83595f6e43eb23a94e0b79eda39@haskell.org> Message-ID: <062.111ddd7422b2c4c93ab89ec9ff3bc9a8@haskell.org> #12820: Regression around pattern synonyms and higher-rank types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Fair enough. But the problem persists even with a type signature on the pattern: {{{ pattern P x <- (((\ _ -> id) :: forall b c. b -> c -> c) -> x) }}} Interestingly, adding the type signature fails in GHC 8.0.1 as well as HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 14:43:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 14:43:46 -0000 Subject: [GHC] #12455: Compact Regions In-Reply-To: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> References: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> Message-ID: <062.00f3f02dd91c3e76f94f7883757b86de@haskell.org> #12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"55d535da10dd63bbaf03fb176ced7179087cd0d4/ghc" 55d535d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="55d535da10dd63bbaf03fb176ced7179087cd0d4" Remove CONSTR_STATIC Summary: We currently have two info tables for a constructor * XXX_con_info: the info table for a heap-resident instance of the constructor, It has type CONSTR, or one of the specialised types like CONSTR_1_0 * XXX_static_info: the info table for a static instance of this constructor, which has type CONSTR_STATIC or CONSTR_STATIC_NOCAF. I'm getting rid of the latter, and using the `con_info` info table for both static and dynamic constructors. For rationale and more details see Note [static constructors] in SMRep.hs. I also removed these macros: `isSTATIC()`, `ip_STATIC()`, `closure_STATIC()`, since they relied on the CONSTR/CONSTR_STATIC distinction, and anyway HEAP_ALLOCED() does the same job. Test Plan: validate Reviewers: bgamari, simonpj, austin, gcampax, hvr, niteria, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2690 GHC Trac Issues: #12455 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 14:50:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 14:50:40 -0000 Subject: [GHC] #11219: Implement fine-grained `-Werror=...` facility In-Reply-To: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> References: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> Message-ID: <057.567d002cbb1387cb004852544c39c206@haskell.org> #11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11796 | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Wonderful! We usually review patches by using Phabricator, as it makes code review (and ultimately landing the patch) far simpler. Do you mind uploading your patch as a Diff by following the directions in this [https://ghc.haskell.org/trac/ghc/wiki/Phabricator wiki page]? I'd be happy to assist if you have any questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 16:08:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 16:08:46 -0000 Subject: [GHC] #11219: Implement fine-grained `-Werror=...` facility In-Reply-To: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> References: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> Message-ID: <057.05055406e3ee647656a8282be3095acf@haskell.org> #11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11796 | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by zyla): Sure! The patch is at https://phabricator.haskell.org/D2706 now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 17:13:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 17:13:14 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.ec3d7b78a6edb6a20ce68c50c8cc25a6@haskell.org> #12759: Latest Debian GCC breaks GHC -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12755, #11834 | Differential Rev(s): Phab:D2707 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * differential: => Phab:D2707 * resolution: fixed => * related: => #12755, #11834 Comment: It seems that the `configure` check introduced previously isn't robust enough due to some GCC silliness. Prior to 4.8 GCC apparently only warns when faced with an unknown flag, exiting with exit code 0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 18:04:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 18:04:29 -0000 Subject: [GHC] #12773: Data.Functor.Classes instances for ZipList In-Reply-To: <051.45ef1ecec509b2c0184a30a9bc246f2a@haskell.org> References: <051.45ef1ecec509b2c0184a30a9bc246f2a@haskell.org> Message-ID: <066.fd56539554f69d723b81d3c1c36e8c93@haskell.org> #12773: Data.Functor.Classes instances for ZipList -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): No hurry. I'll leave this ticket open so this doesn't get forgotten, thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 18:16:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 18:16:22 -0000 Subject: [GHC] #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries In-Reply-To: <051.7b4be1b0be287b220192621968128bf6@haskell.org> References: <051.7b4be1b0be287b220192621968128bf6@haskell.org> Message-ID: <066.f4147295020840a7db698dff77fd735c@haskell.org> #12772: (type f1 ~> f2 = forall a. f1 a -> f2 a) to core libraries -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * status: new => closed * resolution: => invalid Comment: Created [https://mail.haskell.org/pipermail/libraries/2016-November/027414.html thread]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 19:10:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 19:10:36 -0000 Subject: [GHC] #10771: Installation of Ivory - Static flags have not been initialised In-Reply-To: <045.799f67bd688340da6719146f693d4e1e@haskell.org> References: <045.799f67bd688340da6719146f693d4e1e@haskell.org> Message-ID: <060.7a91fb2f0735e3233a301654d211a95a@haskell.org> #10771: Installation of Ivory - Static flags have not been initialised -------------------------------------+------------------------------------- Reporter: stiege | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 19:13:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 19:13:50 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.cd9bf58ea23784858bb3c414b569a3c1@haskell.org> #12759: Latest Debian GCC breaks GHC -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12755, #11834 | Differential Rev(s): Phab:D2707 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"011af2bf448c28db68a55293abaa5b294f170e37/ghc" 011af2b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="011af2bf448c28db68a55293abaa5b294f170e37" configure: Verify that GCC recognizes -no-pie flag It seems like GCC versions prior to 4.8 exit with code 0 when faced with an unrecognized flag. Silly compilers. Test Plan: Validate Reviewers: hvr, austin, ggreif Reviewed By: ggreif Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2707 GHC Trac Issues: #12759 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 19:30:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 19:30:07 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.f1cdf0853b6a1d2e1d6eaf75a729fc75@haskell.org> #12759: Latest Debian GCC breaks GHC -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12755, #11834 | Differential Rev(s): Phab:D2707 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged to `ghc-9.0` as 5c468247c39d885dfc4bf717ed9e0b01c478ef41. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 19:44:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 19:44:27 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.36e5c53dc607e1c24669f4dcb07bf8f2@haskell.org> #12759: Latest Debian GCC breaks GHC -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12755, #11834 | Differential Rev(s): Phab:D2707 Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): @bgamari, you did mean 8.0 didn't you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 20:26:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 20:26:28 -0000 Subject: [GHC] #12836: stack build command failing on creating new yesod-sqlite project Message-ID: <045.ab7e4c8d4c3e5c618a9c704de6e8ad54@haskell.org> #12836: stack build command failing on creating new yesod-sqlite project ----------------------------------------+--------------------------------- Reporter: v0d1ch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Configuring yesod-auth-1.4.13.5... Building yesod-auth-1.4.13.5... Preprocessing library yesod-auth-1.4.13.5... [ 1 of 12] Compiling Yesod.PasswordStore ( Yesod/PasswordStore.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/PasswordStore.o ) Yesod/PasswordStore.hs:166:31: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Integral b0) arising from a use of ‘^’ at Yesod/PasswordStore.hs:166:31 (Num b0) arising from the literal ‘32’ at Yesod/PasswordStore.hs:166:32-33 In the first argument of ‘(-)’, namely ‘2 ^ 32’ In the first argument of ‘(*)’, namely ‘(2 ^ 32 - 1)’ In the second argument of ‘(>)’, namely ‘(2 ^ 32 - 1) * hLen’ Yesod/PasswordStore.hs:419:1: Warning: Defined but not used: ‘toStrict’ Yesod/PasswordStore.hs:422:1: Warning: Defined but not used: ‘fromStrict’ [ 2 of 12] Compiling Yesod.Auth.Message ( Yesod/Auth/Message.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Message.o ) Yesod/Auth/Message.hs:23:1: Warning: The import of ‘mappend’ from module ‘Data.Monoid’ is redundant Yesod/Auth/Message.hs:698:1: Warning: Defined but not used: ‘croatianMessage’ Yesod/Auth/Message.hs:459:1: Warning: Pattern match(es) are overlapped In an equation for ‘finnishMessage’: finnishMessage Password = ... Yesod/Auth/Message.hs:459:1: Warning: Pattern match(es) are non-exhaustive In an equation for ‘finnishMessage’: Patterns not matched: CurrentPassword [ 3 of 12] Compiling Yesod.Auth.Routes ( Yesod/Auth/Routes.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth/Routes.o ) [ 4 of 12] Compiling Yesod.Auth ( Yesod/Auth.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Yesod/Auth.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/l0/kb14zym51tn31vfsr4bmf_yr0000gp/T/ghc18354_0/libghc_21.dylib, 5): no suitable image found. Did find: /var/folders/l0/kb14zym51tn31vfsr4bmf_yr0000gp/T/ghc18354_0/libghc_21.dylib: malformed mach-o: load commands size (35808) > 32768 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 Nov 14 20:35:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 20:35:32 -0000 Subject: [GHC] #12836: stack build command failing on creating new yesod-sqlite project In-Reply-To: <045.ab7e4c8d4c3e5c618a9c704de6e8ad54@haskell.org> References: <045.ab7e4c8d4c3e5c618a9c704de6e8ad54@haskell.org> Message-ID: <060.ad2b22aac72d0557fc9d23dcd5c36f2d@haskell.org> #12836: stack build command failing on creating new yesod-sqlite project ---------------------------------+---------------------------------------- Reporter: v0d1ch | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Duplicate of #12479. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 21:41:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 21:41:26 -0000 Subject: [GHC] #12837: KnownNat and KnownSymbol should be abstract Message-ID: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> #12837: KnownNat and KnownSymbol should be abstract -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following patent nonsense: {{{#!hs {-# LANGUAGE FlexibleInstances #-} import GHC.TypeLits instance KnownNat n }}} This is accepted (albeit with a warning about the missing `natSing` method). I think it should be rejected, as should an instance of `KnownSymbol`. Compare doing the same thing with `Typeable`, which says: {{{ Class ‘Typeable’ does not support user-specified instances }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 22:20:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 22:20:03 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.564a05423c004c69af8a6ab0b049c422@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I think comment:32 should have fixed this. Comment:32 was merged to `ghc-8.0` as 8008d27c09ce36f368ab562f3f821f666d99f519. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 22:21:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 22:21:15 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.246198223bcf1822aec5b6e18ed32387@haskell.org> #12759: Latest Debian GCC breaks GHC -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12755, #11834 | Differential Rev(s): Phab:D2707 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): @erikd, nope, 9.0. Fixing tomorrows compilers today! ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 22:42:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 22:42:02 -0000 Subject: [GHC] #12777: reify yields the wrong type in the presence of functional dependencies In-Reply-To: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> References: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> Message-ID: <071.83bb0ab923e148c744022ada81352d2d@haskell.org> #12777: reify yields the wrong type in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2659 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: Mathieu would like to see this for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 23:08:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 23:08:35 -0000 Subject: [GHC] #12827: RTS linker: handle 64-bit symbol table in archives In-Reply-To: <045.060ac6e251408a198497a7d49be67fae@haskell.org> References: <045.060ac6e251408a198497a7d49be67fae@haskell.org> Message-ID: <060.57d22381184b1a3e878fc70f265325e9@haskell.org> #12827: RTS linker: handle 64-bit symbol table in archives -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: linker Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2697 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1b336d9064514219f370a4a12d7019f23393600e/ghc" 1b336d9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1b336d9064514219f370a4a12d7019f23393600e" Skip 64-bit symbol tables This patch makes the RTS linker skip 64-bit symbol table entries. See https://mail.haskell.org/pipermail/ghc-devs/2016-November/013210.html Test Plan: validate Reviewers: austin, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: osa1, thomie Differential Revision: https://phabricator.haskell.org/D2697 GHC Trac Issues: #12827 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 23:09:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 23:09:04 -0000 Subject: [GHC] #12827: RTS linker: handle 64-bit symbol table in archives In-Reply-To: <045.060ac6e251408a198497a7d49be67fae@haskell.org> References: <045.060ac6e251408a198497a7d49be67fae@haskell.org> Message-ID: <060.2bd8d02cad324ae901e7f90cd190cdf2@haskell.org> #12827: RTS linker: handle 64-bit symbol table in archives -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: fixed | Keywords: linker Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2697 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as ce66c24ac91ff7893dc91f31292bcebc60df4924. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 23:09:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 23:09:53 -0000 Subject: [GHC] #12568: Release hsc2hs new version to Hackage In-Reply-To: <046.f48bd8f5388597261197cf95bdd58cab@haskell.org> References: <046.f48bd8f5388597261197cf95bdd58cab@haskell.org> Message-ID: <061.614a2633ac07d2a4151009868aa9b5ee@haskell.org> #12568: Release hsc2hs new version to Hackage -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: `hsc2hs` 0.68.1 has been released to Hackage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 14 23:43:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 14 Nov 2016 23:43:58 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.35b97c77498cf0096e5aa4ddcc058c45@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2554, Wiki Page: | Phab:D2605 -------------------------------------+------------------------------------- Comment (by akio): Replying to [comment:17 simonpj]: > > this means a larger code size. > > Why?? In both cases I'd ultimately expect to see a top-level machine- code label for a literal string, and a reference to that label in the compiled code. I see no reason for increased code size, or increased bytes-allocated. Sorry, I meant a larger size of the core. Presumably the compiler needs to use more memory to store a larger syntax tree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 00:46:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 00:46:20 -0000 Subject: [GHC] #12838: On iOS, sys_icache_invalidate called with an end pointer instead of a size Message-ID: <045.f0f60f1b8f6940f5ddfc0f0c47f72313@haskell.org> #12838: On iOS, sys_icache_invalidate called with an end pointer instead of a size ----------------------------------------+--------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Keywords: | Operating System: Other Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The second argument of sys_icache_invalidate takes a size, but Storage.c passes an end pointer instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 00:47:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 00:47:03 -0000 Subject: [GHC] #12838: On iOS, sys_icache_invalidate called with an end pointer instead of a size In-Reply-To: <045.f0f60f1b8f6940f5ddfc0f0c47f72313@haskell.org> References: <045.f0f60f1b8f6940f5ddfc0f0c47f72313@haskell.org> Message-ID: <060.a1673d351e504c36df23b8938b1f64ae@haskell.org> #12838: On iOS, sys_icache_invalidate called with an end pointer instead of a size -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by shlevy): Patch already ready, just combining it with a few other build fixes and will push all at once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 00:49:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 00:49:59 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.7026801ebd9269d8c749e24b94766c55@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * differential: => Phab:D2709 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 01:10:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 01:10:07 -0000 Subject: [GHC] #12839: mmap functions not properly guarded by RTS_LINKER_USE_MMAP in Linker.c Message-ID: <045.69adb6886a9a658800cb9730d6801890@haskell.org> #12839: mmap functions not properly guarded by RTS_LINKER_USE_MMAP in Linker.c -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System (Linker) | Keywords: | Operating System: Other Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A few uses of munmap etc. are inside of C conditional statements (e.g. `if (RTS_LINKER_USE_MMAP && oc->imageMapped)`) instead of CPP conditional statements, causing compilation failure on systems that don't use MMAP -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 01:10:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 01:10:45 -0000 Subject: [GHC] #12839: mmap functions not properly guarded by RTS_LINKER_USE_MMAP in Linker.c In-Reply-To: <045.69adb6886a9a658800cb9730d6801890@haskell.org> References: <045.69adb6886a9a658800cb9730d6801890@haskell.org> Message-ID: <060.926df96875397994d1e42ec4f34f64f1@haskell.org> #12839: mmap functions not properly guarded by RTS_LINKER_USE_MMAP in Linker.c -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 (Linker) | Resolution: | Keywords: Operating System: Other | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by shlevy): Patch already ready, just combining it with a few other build fixes and will push all at once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 01:32:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 01:32:34 -0000 Subject: [GHC] #12840: GHC-internal triplets passed to sub-project configure scripts Message-ID: <045.2e2c224d7fdf415c0b1a95252433ab8a@haskell.org> #12840: GHC-internal triplets passed to sub-project configure scripts -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In some cases GHC normalizes the target triplet passed to configure to a value that is not a valid autoconf target. #12487 mistakenly changed the build to pass these triplets to sub-project configure scripts, such as that for 'base', causing a configure error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 01:33:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 01:33:12 -0000 Subject: [GHC] #12840: GHC-internal triplets passed to sub-project configure scripts In-Reply-To: <045.2e2c224d7fdf415c0b1a95252433ab8a@haskell.org> References: <045.2e2c224d7fdf415c0b1a95252433ab8a@haskell.org> Message-ID: <060.3246266b6c7d877e8eabe8f47addb302@haskell.org> #12840: GHC-internal triplets passed to sub-project configure scripts -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by shlevy): Patch already ready, just combining it with a few other build fixes and will push all at once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 07:25:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 07:25:21 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.f1f1ec47fc5994d66575a6e73d94b1ab@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): I'd like to make an incremental attempt towards improving the aesthetics. Specifically, I wish to: - Add colors in a style similar to Clang/GCC. - Allow the color to be turned on and off via `-fdiagnostics- color=(always|auto|no)`. - Implement auto detection of color support (`auto`). - Display one line of code extracted from the original source code, along with a marker indicating the location of the error. So the final result should look like this, but with the usual white-on- black terminal colors: {{{ #!html
/home/rf/revad.hs:26:1: warning: [-Wunused-top-binds]
     Defined but not used: ‘add
 add = Func $ \ (x, y) ->
 ^~~
 
}}} Here is an attempt at implementing the first two objectives: https://github.com/ghc/ghc/compare/master...Rufflewind:diagnostics-color -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 09:30:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 09:30:50 -0000 Subject: [GHC] #8472: Primitive string literals prevent optimization In-Reply-To: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> References: <043.b9228517bae58807966ca84ad2e4035c@haskell.org> Message-ID: <058.8d011d5cdacbc7923e836a0b21c99782@haskell.org> #8472: Primitive string literals prevent optimization -------------------------------------+------------------------------------- Reporter: akio | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2554, Wiki Page: | Phab:D2605 -------------------------------------+------------------------------------- Comment (by simonpj): Oh OK, now I understand. I think that's fine: * peak allocation is very vulnerable to the moment at which major gc runs. * "Term" component of core-stats is fine. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 09:41:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 09:41:37 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.62c613d155271fceca7babb101330958@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): I would like to use terminfo to detect color support, but that would require pulling in `terminfo` as a dependency (it is already a boot package fortunately). Is this a good idea? If so, how do I even add a dependency to this build system? (Specifically, for `main/DynFlags.hs`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 10:10:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 10:10:21 -0000 Subject: [GHC] #12455: Compact Regions In-Reply-To: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> References: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> Message-ID: <062.df65c9a36a0297aa14d30448ed6f12cd@haskell.org> #12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"98f975961b9db2c2f308295c303028b97bc3239b/ghc" 98f9759/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="98f975961b9db2c2f308295c303028b97bc3239b" Hopefully fix build on OS X Summary: It looks like I broke the OS X build with 55d535da10dd, hopefully this should fix it. Test Plan: Harbourmaster Reviewers: austin, bgamari, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2705 GHC Trac Issues: #12455 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 10:58:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 10:58:59 -0000 Subject: [GHC] #12830: ARM crosscompile panic In-Reply-To: <047.3fdea1a051432822f033c3c087bc879e@haskell.org> References: <047.3fdea1a051432822f033c3c087bc879e@haskell.org> Message-ID: <062.7c6a58af033df5041400f5810a8de94e@haskell.org> #12830: ARM crosscompile panic -------------------------------------+------------------------------------- Reporter: skovalev | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: arm, | crosscompile, panic Operating System: Linux | Architecture: arm Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: Looks like #12130. Do re-open if not. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 12:43:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 12:43:43 -0000 Subject: [GHC] #12826: TyVar ASSERT failure in type family checking: T12041 In-Reply-To: <046.9d0fa2858f11e126141a89fb401b8d81@haskell.org> References: <046.9d0fa2858f11e126141a89fb401b8d81@haskell.org> Message-ID: <061.86d8290a24c29c353ed9ffcaebd00d84@haskell.org> #12826: TyVar ASSERT failure in type family checking: T12041 -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"642adec4da8df4ae39b884b30c47284a3c9d0f30/ghc" 642adec4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="642adec4da8df4ae39b884b30c47284a3c9d0f30" Mark T12041 as expect_broken with -DDEBUG (#12826) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 14:43:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 14:43:29 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.5db48c1955b83c576110bdd5e3027c48@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't know whether or not it is a good idea, but it should just be a matter of editing `compiler/ghc.cabal.in`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 15:24:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 15:24:26 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.61b2ae6bd632c095cba57252b559c19c@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Right, as rwbarton said, this is just a matter of editing the cabal file, which is generated by `autoconf` from `compiler/ghc.cabal.in`. Note that you will need to rerun `./boot` (or just edit `compiler/ghc.cabal` manually`) after doing this. It sounds like you have a reasonable start, Rufflewind. I would love it if someone pick up the proposal that I began laying out in comment:3. I think this would allow us to avoid baking too many formatting decisions into the compiler (which strikes me as something that we would regret) and instead defer them to the consumer of the message (which may very well be `ghc`'s own compiler driver). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 18:27:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 18:27:04 -0000 Subject: [GHC] #12841: Remove or explain target triple normalization Message-ID: <045.b7dcd7bcb594e17160dbfb7d1d3dae75@haskell.org> #12841: Remove or explain target triple normalization -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently during configure, GHC normalizes the triple passed e.g. with --target. It's not clear why this happens, and it has caused problems in the past (See #12840, #12487), so we should probably either just remove the GHC triples altogether or add some explanations for why they're around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 18:55:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 18:55:08 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.40ad976028bfb8803829ba2a57cb2636@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Preventing StaticPtrs from being unpacked is not necessary. Turns out that there is a bug in the code that floats out static pointers. The identifier of the following binding is not exported and it should. {{{ lvl_sG5 :: forall a_aEy. StaticPtr (a_aEy -> Bool) lvl_sG5 = \ (@ a_aEy) -> GHC.StaticPtr.StaticPtr @ (a_aEy -> Bool) 13520098690657238824## 6110703080284699228## lvl_sG4 (g @ a_aEy) }}} Having the id as exported, prevents the simplifier from removing it, which is what we want. However, our minimal example still fails linting. The problem is this line in `Main.hs`: {{{ let T s = sg :: T (Bool -> Bool) }}} Which gets translated to {{{ s :: StaticPtr (Bool -> Bool) s = case sg of T dt_d2bM dt_d2bN dt_d2bO dt_d2bP -> GHC.StaticPtr.StaticPtr dt_d2bM dt_d2bN dt_d2bO dt_d2bP }}} which the linter rejects because it contains an occurrence of the StaticPtr data constructor which cannot be floated. Note that this occurrence is harmless, since it is not created by a `static` form and does not correspond to an entry in the Static Pointer Table. Nonetheless, the linter is confused, and I don't know yet how to help it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 21:17:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 21:17:43 -0000 Subject: [GHC] #12619: Allow users guide to be built independently from GHC In-Reply-To: <046.2df188325e9671498d5d7f855d704a92@haskell.org> References: <046.2df188325e9671498d5d7f855d704a92@haskell.org> Message-ID: <061.87647bf5b424d3551d84fbbba2f356ff@haskell.org> #12619: Allow users guide to be built independently from GHC -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -4,1 +4,1 @@ - Moreover, this would make our [http://ghc.readthedocs.org/|readthedocs] + Moreover, this would make our [[http://ghc.readthedocs.org/|readthedocs]] New description: At HIW 2016 it was suggested that this would greatly reduce the friction to contributing users guide fixes. Moreover, this would make our [[http://ghc.readthedocs.org/|readthedocs]] mirror significantly easier to maintain. -- Comment (by bgamari): This would perhaps be made easier by #11654. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 15 21:24:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 15 Nov 2016 21:24:23 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.a519c34b50f9a0c95817358c0950d478@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by danharaj): * differential: => Phab:D2714 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 00:44:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 00:44:33 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.d6e8398164307e027a011682c1510ba0@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Fixed the id of the floated binding in master {{{ commit 31d5b6efa24985d0a8be5354e6a9a38e016db0ff Author: Facundo Domínguez Date: Tue Nov 15 21:39:40 2016 -0300 fixup! Stop the simplifier from removing StaticPtr binds. diff --git a/compiler/simplCore/SetLevels.hs b/compiler/simplCore/SetLevels.hs index fc55564..f2f373d 100644 --- a/compiler/simplCore/SetLevels.hs +++ b/compiler/simplCore/SetLevels.hs @@ -1115,7 +1115,8 @@ newLvlVar lvld_rhs is_bot rhs_ty = exprType de_tagged_rhs mk_id uniq -- See Note [Grand plan for static forms] in SimplCore. - | isJust (collectStaticPtrSatArgs lvld_rhs) + | isJust $ collectStaticPtrSatArgs $ snd $ collectTyBinders $ + deTagExpr lvld_rhs = mkExportedVanillaId (mkSystemVarName uniq (mkFastString "static_ptr")) rhs_ty | otherwise }}} It remains fixing the core linter now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 04:08:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 04:08:39 -0000 Subject: [GHC] #12744: Register Allocator Unit Tests In-Reply-To: <046.cdcf9b0043696316368f9dfb406d0a24@haskell.org> References: <046.cdcf9b0043696316368f9dfb406d0a24@haskell.org> Message-ID: <061.eeb68c133f1e2edd019248cb4ba69de4@haskell.org> #12744: Register Allocator Unit Tests -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: task | Status: new Priority: lowest | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12745 | Differential Rev(s): Phab:D2638 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0e5865294fb810afa15b20e489e1791ead7643fa/ghc" 0e58652/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e5865294fb810afa15b20e489e1791ead7643fa" Test for unnecessary register spills Reviewers: mainland, simonmar, michalt, bgamari, austin Reviewed By: bgamari Subscribers: simonpj, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2638 GHC Trac Issues: #12744, #12745 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 04:08:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 04:08:39 -0000 Subject: [GHC] #12745: Compile cmm file for register allocator stats In-Reply-To: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> References: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> Message-ID: <061.4f060892364384b4c98896a2b084b733@haskell.org> #12745: Compile cmm file for register allocator stats -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: task | Status: new Priority: lowest | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12744 | Differential Rev(s): Phab:D2638 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0e5865294fb810afa15b20e489e1791ead7643fa/ghc" 0e58652/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e5865294fb810afa15b20e489e1791ead7643fa" Test for unnecessary register spills Reviewers: mainland, simonmar, michalt, bgamari, austin Reviewed By: bgamari Subscribers: simonpj, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2638 GHC Trac Issues: #12744, #12745 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 04:08:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 04:08:39 -0000 Subject: [GHC] #12839: mmap functions not properly guarded by RTS_LINKER_USE_MMAP in Linker.c In-Reply-To: <045.69adb6886a9a658800cb9730d6801890@haskell.org> References: <045.69adb6886a9a658800cb9730d6801890@haskell.org> Message-ID: <060.8f8fc65d5f4ac579688a30eae720a761@haskell.org> #12839: mmap functions not properly guarded by RTS_LINKER_USE_MMAP in Linker.c -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 (Linker) | Resolution: | Keywords: Operating System: Other | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a637eeb7a1852adfd99b06d2c0a3496e4f238a0c/ghc" a637eeb7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a637eeb7a1852adfd99b06d2c0a3496e4f238a0c" Don't use mmap symbols when !RTS_LINKER_USE_MMAP Some usages of symbols from sys/mman.h are guarded by RTS_LINKER_USE_MMAP by C conditionals, not CPP conditionals. Since those branches are dead anyway when !RTS_LINKER_USE_MMAP, we just stub out the relevant symbols rather than increasing CPP branching. Fixes #12839. Reviewers: simonmar, austin, bgamari, erikd Reviewed By: simonmar, bgamari, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2710 GHC Trac Issues: #12839 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 04:08:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 04:08:39 -0000 Subject: [GHC] #12838: On iOS, sys_icache_invalidate called with an end pointer instead of a size In-Reply-To: <045.f0f60f1b8f6940f5ddfc0f0c47f72313@haskell.org> References: <045.f0f60f1b8f6940f5ddfc0f0c47f72313@haskell.org> Message-ID: <060.cb9effab4393233c4c866d788e6276f4@haskell.org> #12838: On iOS, sys_icache_invalidate called with an end pointer instead of a size -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0135188fecfc679a498093f8fc5f665d706fa4cb/ghc" 0135188/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0135188fecfc679a498093f8fc5f665d706fa4cb" Storage.c: Pass a size to sys_icache_invalidate The previous code passed an end pointer, but the interface takes a size instead. Fixes #12838. Reviewers: austin, erikd, simonmar, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2711 GHC Trac Issues: #12838 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 04:28:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 04:28:47 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.2cabefcaaa463e346671bc8ce68b6ec6@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): > Display one line of code extracted from the original source code, along with a marker indicating the location of the error. So this (“caret diagnostic” is what Clang calls them) is the one I'm a bit stuck on. In order to print a line in the original source file, I would need to read a file, i.e. perform `IO`. This is not possible with `ErrUtils.mkLocMessageAnn`, AFAICT. I thought of a workaround, but it would require a small tweak to `Doc`: I need to add an atom for `CaretDiagnostic` containing the `RealSrcInfo`, and then read the original source file in `printDoc`. However, I feel that this is a bit hacky. IMO, there should really be two layers in the system: - A `Message` type stores each individual diagnostic message unit along with an associated `SrcLoc` and any other useful information in their original format (e.g. fragments of the AST). - `Doc` should remain as a simple, textual output device with fancy formatting (no support for embedded ASTs). (It does need to understand colors and bold though, as their widths must be treated as zero.) The rendering function `[Message] -> IO Doc` would support `IO`, and this is where the caret diagnostics can be constructed, and it would also provide all the necessary information for `Doc` deduce alignment correctly. Hence, IMO the debate over how to represent ASTs should focus on the `Message` type, not `Doc`. That being said, even if this idea does work, I'm not sure I have the time to work on a major refactor right now, so I might go with the hacky solution for the time being. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 04:45:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 04:45:27 -0000 Subject: [GHC] #12842: DatatypeContexts in data types and data families Message-ID: <051.a5226eb89408bf6a4e54d3af5ae4ee50@haskell.org> #12842: DatatypeContexts in data types and data families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Does datatype contexts only apply for non-phantom variables? Figured I'd ask {{{#!hs {-# Language DatatypeContexts, TypeFamilies #-} -- F :: Foo a b data (a ~ b) => Foo a b = F }}} and {{{#!hs {-# Language DatatypeContexts, KindSignatures, DatatypeContexts, DataKinds, TypeFamilies #-} data N = O | S N -- FO :: Fin (S n) n' O data family Fin (n::N) (a::N) (b::N) data instance (n ~ n') => Fin (S n) n' O = FO }}} It surprised me to see the first two of these (yes I know, datatype contexts): {{{#!hs -- F :: x -> Foo x x data (a ~ b) => Foo a b = F a -- F :: x -> Foo x x data (a ~ b) => Foo a b = F b -- F :: x -> x -> Foo x x data (a ~ b) => Foo a b = F a b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 06:28:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 06:28:42 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.01fa1f0f80fefdfd30ac5afa8fa4f27f@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): The changes have been staged to Phabricator, in case anyone wants to review: - https://phabricator.haskell.org/D2716 - https://phabricator.haskell.org/D2717 - https://phabricator.haskell.org/D2718 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 06:53:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 06:53:44 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.a877b61d3d4244bea6a887fcb540ab35@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): One more clue: INLINE vs. (INLINABLE + inline for each call) produce different code --- at the least the binary size differs, the one with INLINE yields bigger exes; possibly also slower, but I haven't pumped the difference enough to make sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 07:11:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 07:11:14 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ Message-ID: <054.387101971e684cfe92badff94537620a@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ [14 of 15] Compiling TieKnot ( GameDefinition/TieKnot.hs, dist/build/LambdaHack/LambdaHack-tmp/TieKnot.dyn_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $ 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: 8813 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} when compiling in profiling mode the following commit (tons of INLINE and INLINABLE to ensure specialization and a couple more to debug irregularities in the output of the profiler) https://github.com/LambdaHack/LambdaHack/commit/842070fe78f07e2fb0bce829505dcfa8465ef40f Steps to reproduce: {{{ 1. make configure-prof 2. cabal build }}} when I instead do {{{ cabal build --ghc-option=-fsimpl-tick-factor=200 }}} it compiles, though when I touch only `GameDefinition/Main.hs` I always get {{{ ~/r/LambdaHack$ cabal build --ghc-option=-fsimpl-tick-factor=200 Building LambdaHack-0.5.1.0... Preprocessing library LambdaHack-0.5.1.0... Preprocessing executable 'LambdaHack' for LambdaHack-0.5.1.0... [15 of 15] Compiling Main ( GameDefinition/Main.hs, dist/build/LambdaHack/LambdaHack-tmp/Main.dyn_o ) The interface for ‘TieKnot’ Declaration for tieKnot Unfolding of tieKnot: Iface id out of scope: standardKeys1 [15 of 15] Compiling Main ( GameDefinition/Main.hs, dist/build/LambdaHack/LambdaHack-tmp/Main.p_o ) The interface for ‘TieKnot’ Declaration for tieKnot Unfolding of tieKnot: Iface id out of scope: standardKeys1 Linking dist/build/LambdaHack/LambdaHack ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 11:46:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 11:46:25 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.b14e5e7aa758fc28ee2e09f89dfbbda7@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * differential: Phab:D2709 => Phab:D2709 Phab:D2720 Comment: Found a fix for the linter. It introduces a twin data constructor StaticPtrInternal which is used exclusively when desugaring the static form. This avoids confusion when unpacking inserts occurrences of the StaticPtr constructor in the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 12:03:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 12:03:19 -0000 Subject: [GHC] #10614: Show constraints in ``Found hole...'' In-Reply-To: <047.e629c8600a92660c55de2127511a14cd@haskell.org> References: <047.e629c8600a92660c55de2127511a14cd@haskell.org> Message-ID: <062.acf62a16d2589d0d720f88e22c88db9b@haskell.org> #10614: Show constraints in ``Found hole...'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zyla): +1 for class constraints. This comes up a lot when working with existentials. Consider this (contrived) example: {{{#!hs {-# LANGUAGE GADTs #-} data AnyShow where AnyShow :: Show a => a -> AnyShow foo :: AnyShow -> String foo (AnyShow x) = _ }}} GHC currently (8.1.20161115) gives the following message: {{{ foo.hs:6:19: error: • Found hole: _ :: p Where: ‘p’ is a rigid type variable bound by the inferred type of foo :: AnyShow -> p at foo.hs:6:1-19 • In the expression: _ In an equation for ‘foo’: foo (AnyShow x) = _ • Relevant bindings include x :: a (bound at foo.hs:6:14) foo :: AnyShow -> p (bound at foo.hs:6:1) }}} The situation is even worse here than in OP's example, since `a` appears out of nowhere, and `Show a` isn't mentioned. But I think the decision whether to include them isn't that hard - we could have both `-fprint-equality-constraints` and `-fprint-class- constraints`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 14:43:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 14:43:25 -0000 Subject: [GHC] #12838: On iOS, sys_icache_invalidate called with an end pointer instead of a size In-Reply-To: <045.f0f60f1b8f6940f5ddfc0f0c47f72313@haskell.org> References: <045.f0f60f1b8f6940f5ddfc0f0c47f72313@haskell.org> Message-ID: <060.aa8d4298513b524d050fd11cbd95e7c2@haskell.org> #12838: On iOS, sys_icache_invalidate called with an end pointer instead of a size -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: fixed | Keywords: Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 14:43:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 14:43:53 -0000 Subject: [GHC] #12839: mmap functions not properly guarded by RTS_LINKER_USE_MMAP in Linker.c In-Reply-To: <045.69adb6886a9a658800cb9730d6801890@haskell.org> References: <045.69adb6886a9a658800cb9730d6801890@haskell.org> Message-ID: <060.74056cafd5aa8ee4ae453a2a6677aaf9@haskell.org> #12839: mmap functions not properly guarded by RTS_LINKER_USE_MMAP in Linker.c -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 (Linker) | Resolution: fixed | Keywords: Operating System: Other | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 15:07:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 15:07:57 -0000 Subject: [GHC] #12842: DatatypeContexts in data types and data families In-Reply-To: <051.a5226eb89408bf6a4e54d3af5ae4ee50@haskell.org> References: <051.a5226eb89408bf6a4e54d3af5ae4ee50@haskell.org> Message-ID: <066.d75d49af0a99f23a2f9b0641f8dc9b1c@haskell.org> #12842: DatatypeContexts in data types and data families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Data type contexts are a mis-feature, since removed. I'm not sure what your question is, but I think we could consign data type contexts to history. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 15:13:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 15:13:23 -0000 Subject: [GHC] #11832: Allow reify to yield types in the current declaration group In-Reply-To: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> References: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> Message-ID: <071.3fc81c74a81f1e986893d94b72b6f914@haskell.org> #11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2286 Wiki Page: | Phab:D2519 TemplateHaskell/Reify | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: Bumping off to 8.0.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 15:28:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 15:28:34 -0000 Subject: [GHC] #11832: Allow reify to yield types in the current declaration group In-Reply-To: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> References: <056.c55a5c5fc06f6b4965766fc5bf61b445@haskell.org> Message-ID: <071.6d4e64b4bcbb97b892278c1693ed38f9@haskell.org> #11832: Allow reify to yield types in the current declaration group -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.3 Resolution: fixed | Keywords: reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2286 Wiki Page: | Phab:D2519 TemplateHaskell/Reify | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: patch => closed * resolution: => fixed Comment: Closing this as we now have #12818 to track patch D2519. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 15:32:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 15:32:39 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.c3caf6dcae0a4456d6e7d15abe3fc651@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Rev(s): Phab:D1130, #7666, #8809 | Phab:D1132 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * owner: thomie => * resolution: fixed => Comment: Re-opening, because we'd really like to start using the real `pretty` library for GHC. It just needs someone to finish the work Thomas started! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 15:34:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 15:34:23 -0000 Subject: [GHC] #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` In-Reply-To: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> References: <045.0d6bd344b086b712375d48496c897cf9@haskell.org> Message-ID: <060.cc405b9968757a2ed3b9dc53f9dc9ca6@haskell.org> #10735: Smooth out the differences between `compiler/utils/Pretty.hs` and `libraries/pretty` -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1062, #1176, | Differential Rev(s): Phab:D1130, #7666, #8809 | Phab:D1132 Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I've made some notes about this for my convenience: https://github.com/niteria/notes/blob/master/PrettyPrintingGHC.md#problems, it summarizes some issues around this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 15:48:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 15:48:54 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.c4f7ecba4cba55b0ea798fc91fb8b7f1@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could you try to say, in a precise way, what the patch is seeking to achieve; what programs will typecheck that don't now, with a number of examples; and what program won't typecheck despite the patch? This is a long thread and I'm really very lost. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 16:19:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 16:19:43 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.7b2c52cb3a74d7feda181f3e44408def@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by sweirich): * cc: sweirich (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 16:25:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 16:25:32 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.202819aa465883514864faa1df2b4623@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sweirich): * cc: sweirich (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 18:35:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 18:35:35 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.bee237aa51af795a156bc87aaa31588c@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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Capturing some email on ghc-devs: From @alanz I am currently working on #3384, with the intent of ensuring that parse (ppr (parse source)) == parse source I have hit the issue where `foo :: (Int)` has the parens reflected in the original parsed AST, but the types pretty printer goes to a lot of trouble to remove any parens not required to interpret the meaning of the type. So the question is, should the default ppr faithfully reproduce the source that was parsed to generate the given AST, or simplify it? From a round-tripping perspective I prefer the former, but there are other use cases where the current behaviour is preferred. If the original is preferred, it can perhaps be enabled via a flag to the pretty printer, but before doing that I want to see if it actually matters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 18:37:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 18:37:56 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.cad63eaf43d9d26ff2287aab1ea288db@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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Email response from Richard Eisenberg I'm afraid I've lost track of where this discussion took place (does someone else remember seeing it?), but I've advocated for faithful reproduction in the past. In particular, the pretty-printers for HsSyn should, in my opinion, never add or remove parentheses. There is a problem here, though: sometimes HsSyn is produced within GHC (for example, in the implementation of `deriving`, or in splicing TH, among a few other spots). This HsSyn can get away with missing parentheses, because it's built as an unambiguous AST. But if the pretty- printer is always faithful, then pretty-printing such an AST will produce an unparsable string. Perhaps the answer is that the generated code should be generous with parentheses -- essentially moving the paren-adding code from today's pretty-printer to the generation sites. Bottom line here: I fully support this direction of travel, but it's not without bumps in the road. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 19:14:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 19:14:58 -0000 Subject: [GHC] #12842: DatatypeContexts in data types and data families In-Reply-To: <051.a5226eb89408bf6a4e54d3af5ae4ee50@haskell.org> References: <051.a5226eb89408bf6a4e54d3af5ae4ee50@haskell.org> Message-ID: <066.7e9e44b3a5c74d43c9ff4e34c7f56d28@haskell.org> #12842: DatatypeContexts in data types and data families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Yeah I know they're going to be removed, I just would have thought that given {{{#!hs data (a ~ b) => a :~: b = Refl }}} the type of `Refl` should be `Refl :: (a ~ b) => a :~: b` similar to {{{#!hs data a :~: b where Refl :: a :~: a }}} I'll close -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 19:15:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 19:15:34 -0000 Subject: [GHC] #12842: DatatypeContexts in data types and data families In-Reply-To: <051.a5226eb89408bf6a4e54d3af5ae4ee50@haskell.org> References: <051.a5226eb89408bf6a4e54d3af5ae4ee50@haskell.org> Message-ID: <066.fcd7e0f0a4be076d601ccb0edcef3951@haskell.org> #12842: DatatypeContexts in data types and data families -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 19:30:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 19:30:40 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.c95048d1ada1c793210b1b1467d2e841@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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): The current AST does not allow faithful reproduction of a context with extra parens around it. So {{{#!hs foo :: (Show a) => a -> String }}} and {{{#!hs foo :: ((Show a)) => a -> String }}} produce the same AST fragment. `ghc-exactprint` works around this by using the API Annotations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 20:22:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 20:22:40 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.b0d6669744cbf929c280f508cbd8e2f4@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 20:24:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 20:24:14 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.3f2ad94da96f82d7c4b39ad8c5581adb@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 21:38:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 21:38:05 -0000 Subject: [GHC] #12844: No Skolem Info with PartialTypeSignatures Message-ID: <047.2c635f7d8f9e46b10ebe3b29b92a477c@haskell.org> #12844: No Skolem Info with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program triggers a panic: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} barWraper :: ('(r,r') ~ Head rngs, Foo rngs) => FooData rngs barWraper = bar bar :: (_) => FooData rngs bar = foo data FooData rngs class Foo xs where foo :: (Head xs ~ '(r,r')) => FooData xs type family Head (xs :: [k]) where Head (x ': xs) = x }}} {{{ > ghci NoSkolem.hs [1 of 1] Compiling Main ( NoSkolem.hs, NoSkolem.o ) NoSkolem.hs:8:13: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): No skolem info: k_aYV[sk] }}} I haven't tested with 8.0.2 or head. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 21:43:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 21:43:35 -0000 Subject: [GHC] #12845: -XPartialTypeSignatures results in unbound variables Message-ID: <047.fe1a80c8e93b6a208be7bf5baa2818e3@haskell.org> #12845: -XPartialTypeSignatures results in unbound variables -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code fails to compile, but I think it should. {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} import Data.Proxy data Foo (m :: Bool) type family Head (xs :: [(Bool, Bool)]) where Head (x ': xs) = x type family Bar (x :: Bool) (y :: Bool) :: Bool -- to trigger the bug, r and r' cannot *both* appear on the RHS broken :: forall r r' rngs . ('(r,r') ~ Head rngs, Bar r r' ~ 'True, _) => Foo r -> Proxy rngs -> () broken x _ = let y = requireBar x :: Foo r' in () requireBar :: (Bar m m' ~ 'True) => Foo m -> Foo m' requireBar = undefined }}} The error is: {{{ > ghci UnboundVar.hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( UnboundVar.hs, interpreted ) UnboundVar.hs:18:1: error: • Could not deduce: Bar r r'0 ~ 'True from the context: ('(r, r') ~ Head rngs, Bar r r' ~ 'True, Bar r r' ~ 'True) bound by the inferred type for ‘broken’: ('(r, r') ~ Head rngs, Bar r r' ~ 'True, Bar r r' ~ 'True) => Foo r -> Proxy rngs -> () at UnboundVar.hs:18:1-49 The type variable ‘r'0’ is ambiguous • When checking that the inferred type broken :: forall (r :: Bool) (r' :: Bool) (rngs :: [(Bool, Bool)]). Bar r r' ~ 'True => Foo r -> Proxy rngs -> () is as general as its (partial) signature broken :: forall (r :: Bool) (r' :: Bool) (rngs :: [(Bool, Bool)]). ('(r, r') ~ Head rngs, Bar r r' ~ 'True, Bar r r' ~ 'True) => Foo r -> Proxy rngs -> () }}} If I remove the partial type signature (i.e., remove the `_` constraint from `broken`), then GHC happily accepts the code. I'm not sure why adding a `_` introduces ambiguity; it seems GHC is forgetting that `r'` is bound by the `forall` (and that `-XScopedTypeVariables` is enabled). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 16 22:31:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 16 Nov 2016 22:31:02 -0000 Subject: [GHC] #9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing. In-Reply-To: <045.57a3cba5fea4ade3aa4122b02fda65ee@haskell.org> References: <045.57a3cba5fea4ade3aa4122b02fda65ee@haskell.org> Message-ID: <060.212ac4a9e0200a3bc21e39f526b57f90@haskell.org> #9940: GHCi crashes when I hold down control-c for a short time, and then hold down any key that would normally result in typing. -------------------------------------+------------------------------------- Reporter: Dingus | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: crash, | control-c Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #4245, #10737, | Differential Rev(s): #11175 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I can still reproduce this on GHC 8.0.1 (although I had to try a few times.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 00:33:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 00:33:12 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.12c13dc9ef9b74d0c35d9736fd9e6242@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2657 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * differential: => phab:D2657 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 00:34:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 00:34:48 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.af4b1fdeb874e495d55818e0bda0a641@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, some time ago I actually tried quickly prototyping the ideas laid out in comment:3. The branch can be found [[https://github.com/ghc/ghc/compare/master...bgamari:error|here]]. The only slightly annoying issue with the approach is that it requires adding an index to all mentions of `Doc`, leading to a rather difficult to rebase branch. That being said, I really don't think there's a whole lot of work here if we agree that this is the right approach. If someone was motivated, I'm rather confident that we could get the painful refactoring changes into the tree within the space of a weekend. Of course, the dynamically-typed alternative proposed by Richard in comment:9 is also still on the table. However, I suspect we'd rather want `Doc` to look like, {{{#!hs data Doc = forall a. (Typeable a, Outputable a) => Embed a | Empty | ... }}} to ensure that the consumer can always, at very least, output a human readable representation of the payload. It's not clear which of these options is preferrable; I'll admit that the dynamically-typed option feels a bit like we are trading precision and long-term maintainability for some temporary convenience, but perhaps this is too pessimistic a view. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 01:29:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 01:29:58 -0000 Subject: [GHC] #12846: On Windows, runtime linker can't find function defined in GHC's RTS Message-ID: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> #12846: On Windows, runtime linker can't find function defined in GHC's RTS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is an annoyance I discovered when working with the [https://github.com/rrnewton/haskell- lockfree/tree/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic-primops atomic-primops] package on Windows. Here is a simplified test case: {{{#!hs module Main (main) where foreign import ccall unsafe "store_load_barrier" storeLoadBarrier :: IO () main :: IO () main = do putStrLn "1" storeLoadBarrier putStrLn "2" }}} Compiling and running this program works without issue. But when run as GHCi bytecode, it fails. I've reproduced this with GHC 8.0.1 and HEAD (but based on [https://github.com/rrnewton/haskell-lockfree/pull/38 this], the issue is likely much older than 8.0.1). {{{ $ runghc Bug.hs Bug.hs: ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: store_load_barrier This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} To work around this issue, `atomic-primops` currently links against [https://github.com/rrnewton/haskell- lockfree/blob/0ea12fc141c6bd4762773a1adc2f005de068369c/atomic- primops/cbits/RtsDup.c#L52-L69 a separate C file] that contains an exact duplicate of the `store_load_barrier` function from GHC's RTS when build on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 01:48:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 01:48:15 -0000 Subject: [GHC] #12846: On Windows, runtime linker can't find function defined in GHC's RTS In-Reply-To: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> References: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> Message-ID: <065.a0160b4fccc88d3304eabcb5bce68529@haskell.org> #12846: On Windows, runtime linker can't find function defined in GHC's RTS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): The symbol is missing from `RtsSymbols.c`. It was added to the headers but never added to the internal symbol table. We don't load an RTS package when using the runtime linker, we just manually inject the list of symbols we expect to be there. This isn't a problem just for Windows, it effects all platforms using the runtime linker. It's just that Linux defaults to using the system loader. Ideally we'd need a way to keep these two lists in sync... I'll have a think about how to solve this once and for all.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 02:01:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 02:01:39 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.bb6919ac53dca50a3c3f50efa0b3b3b1@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) Comment: This looks nice, I don't know what the plans are, but I'd love for us to stop diverging on Windows support for stuff like this (VT100 escape sequences are supported fine on Windows 10 builds 10586 and later, or any console with ANSICON, ConEMU or xterm such as the standard MSYS2 console). I can help with the detection if you don't know how. I'll also be pushing an update to the `Win32` package which adds a function `isVT100ConsoleSupported`. The definition can be in-lined and used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 03:01:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 03:01:32 -0000 Subject: [GHC] #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 Message-ID: <042.ae1a4a171fe54fc9b54d80da6024e345@haskell.org> #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Other Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From IRC: I have a module that takes around 10 seconds to compile on ghc --make -O2, but only around 3 seconds on ghci -fobject-code -O2. > bgamari: that is surprising I've put the -v timing output of the two cases into https://gist.github.com/nh2/e9bc4732111bfe422d8e606c10f8f0ac I'm comparing the 2 files with `meld` for spotting differences easily. Check e.g. `Result size of Tidy Core` which seems to have 3x as many terms for ghc, and `Simplifier [Mymodule]` doesn't seem to run in ghci The first time terms are different is at `Desugar, the first time a factor 3 comes in is after `Specialize`. > bgamari: wow, it sounds like the simplifier isn't getting run as aggressively in GHCi I'm running this on Ubuntu 16.04 inside nix (but happens the same way outside nix). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 03:15:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 03:15:02 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.95f5e990a5dcf165ec168d027346daf1@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by danharaj): Hi, The motivation of this patch is that the compiler can produce more efficient code if the constraint solver used top-level instance declarations to solve constraints that are currently solved givens and their superclasses. In particular, as it currently stands, the compiler imposes a performance penalty on the common use-case where superclasses are bundled together for user convenience. The performance penalty applies to constraint synonyms as well. This example illustrates the issue: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleContexts, FunctionalDependencies #-} module A where import Data.Monoid class (Monoid w, Monad m) => MonadWriter w m | m -> w where tell :: w -> m () f :: MonadWriter Any m => [Any] -> m () f xs = tell (mconcat xs) }}} This produces the following core on GHC 8.0.2 by running `ghc A.hs -ddump- simpl -dsuppress-idinfo`: {{{ f :: forall (m_aJV :: * -> *). MonadWriter Any m_aJV => [Any] -> m_aJV () f = \ (@ (m_aZM :: * -> *)) ($dMonadWriter_aZN :: MonadWriter Any m_aZM) (eta_B1 :: [Any]) -> tell @ Any @ m_aZM $dMonadWriter_aZN (mconcat @ Any (A.$p1MonadWriter @ Any @ m_aZM $dMonadWriter_aZN) eta_B1) }}} With the patch, the code produced: {{{ f :: forall (m :: * -> *). MonadWriter Any m => [Any] -> m () f = \ (@ (m :: * -> *)) ($dMonadWriter_a12F :: MonadWriter Any m) (xs_aLg :: [Any]) -> tell @ Any @ m $dMonadWriter_a12F (mconcat @ Any Data.Monoid.$fMonoidAny xs_aLg) }}} The performance gains possible are perhaps more starkly present in the following example from the comment thread, which here I have compiled also with `-O2`: {{{#!hs {-# LANGUAGE ConstraintKinds, MultiParamTypeClasses, FlexibleContexts #-} module B where class M a b where m :: a -> b type C a b = (Num a, M a b) f :: C Int b => b -> Int -> Int f _ x = x + 1 }}} Output without the patch: {{{ f :: forall b_arz. C Int b_arz => b_arz -> Int -> Int f = \ (@ b_a1EB) ($d(%,%)_a1EC :: C Int b_a1EB) _ (eta1_B1 :: Int) -> + @ Int (GHC.Classes.$p1(%,%) @ (Num Int) @ (M Int b_a1EB) $d(%,%)_a1EC) eta1_B1 B.f1 }}} Output with the patch: {{{ f :: forall b. C Int b => b -> Int -> Int f = \ (@ b) _ _ (x_azg :: Int) -> case x_azg of { GHC.Types.I# x1_a1DP -> GHC.Types.I# (GHC.Prim.+# x1_a1DP 1#) } }}} However, there is a reason why the solver does not simply try to solve such constraints with top-level instances. If the solver finds a relevant instance declaration in scope, that instance may require a context that can't be solved for. As pointed out in the thread, a good example of this is: {{{ f :: Ord [a] => ... f x = ..Need Eq [a]... }}} If we have `instance Eq a => Eq [a]` in scope and we tried to use it, we would be left with the obligation to solve the constraint `Eq a`, which we cannot. So the patch must be conservative in its attempt to use an instance declaration to solve the constraint we're interested in. The rule I have applied is as was previously mentioned in the comment thread: The solver gives up on using an instance declaration to solve a given constraint if doing so would produce more work to be done; we make no attempt even if the new constraints are also solvable with instances. Precisely: The intent of the patch is to only attempt to solve constraints of the form `C t1 ... tn` and only with instances with no context. This example illustrates the conservative behavior: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, FlexibleContexts, FunctionalDependencies #-} module C where class Eq a => C a b | b -> a where m :: b -> a f :: C [Int] b => b -> Bool f x = m x == [] }}} The core output without the patch: {{{ f :: forall b_a1ka. C [Int] b_a1ka => b_a1ka -> Bool f = \ (@ b_a1rX) ($dC_a1rY :: C [Int] b_a1rX) (eta_B1 :: b_a1rX) -> == @ [Int] (C.$p1C @ [Int] @ b_a1rX $dC_a1rY) (m @ [Int] @ b_a1rX $dC_a1rY eta_B1) (GHC.Types.[] @ Int) }}} The core output with the patch: {{{ f :: forall b. C [Int] b => b -> Bool f = \ (@ b) ($dC_a1sq :: C [Int] b) (eta_B1 :: b) -> == @ [Int] (C.$p1C @ [Int] @ b $dC_a1sq) (m @ [Int] @ b $dC_a1sq eta_B1) (GHC.Types.[] @ Int) }}} Even though we also have an instance for `Eq Int` in scope, the solver does not even try. The impact of this patch on typeability is simple: there should be no change whatsoever. Every program considered well-typed without the patch should remain well-typed with it, and every program considered ill-typed without the patch should remain ill-typed. There is a possible change in semantics with this patch because the solver is now choosing different solutions for certain constraints, however there should be no difference in behavior up to confluence of proofs. There is a possible interaction with overlapping instances and my intent was to preserve the current behavior of overlapping instances exactly. I expect that code that uses Incoherent Instances could see a change in behavior with this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 03:41:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 03:41:15 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.dc8dff2c64b6823c4de08d961e774302@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): Replying to [comment:32 Phyx-]: > This looks nice, I don't know what the plans are, but I'd love for us to stop diverging on Windows support for stuff like this (VT100 escape sequences are supported fine on Windows 10 builds 10586 and later, or any console with ANSICON, ConEMU or xterm such as the standard MSYS2 console). I can help with the detection if you don't know how. I'll also be pushing an update to the `Win32` package which adds a function `isVT100ConsoleSupported`. The definition can be in-lined and used. I omitted support for Windows because I wanted to do it via `SetConsoleTextAttribute`, which would require further changes to `Doc` and its friends. I didn't realize it was still possible to `ENABLE_VIRTUAL_TERMINAL_PROCESSING` though − I had assumed it was a legacy feature that MS wanted to go away. That being said, the [https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on- ubuntu-on-windo/suggestions/15617610--re-enable-enable-virtual-terminal- processing-by change in 10586 was actually a mistake]. It is still necessary to manually `ENABLE_VIRTUAL_TERMINAL_PROCESSING`. Actually, for `Win32` it would be really nice to have `GetConsoleMode`. Then it'd be possible to color detection on Windows (heavily inspired by LLVM): {{{#!c DWORD mode = 0; HANDLE handle = GetStdHandle(STD_ERROR_HANDLE); if (handle == INVALID_HANDLE_VALUE) { return 0; } if (GetConsoleMode, &mode) == 0) { return 0; } return 1; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 03:44:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 03:44:38 -0000 Subject: [GHC] #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 In-Reply-To: <042.ae1a4a171fe54fc9b54d80da6024e345@haskell.org> References: <042.ae1a4a171fe54fc9b54d80da6024e345@haskell.org> Message-ID: <057.1ba050af6bf0c44fc9fa0ad521fb798d@haskell.org> #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Other | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Although you don't say so explicitly, you seem to be invoking `ghci` and then running `:set -fforce-recomp -fobject-code -O2 -v` at the prompt. Does the same happen with `ghci -fforce-recomp -fobject-code -O2 -v`? This could be because of #9370, where decisions about whether to inline a function are effectively made when reading the interface file in which the function is defined; and at that point you may not have `-O2` set yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 04:49:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 04:49:26 -0000 Subject: [GHC] #12848: Reduce long-term memory usage of GHCi Message-ID: <047.67e660d21ca1bf05a200182e30500999@haskell.org> #12848: Reduce long-term memory usage of GHCi ---------------------------------------+-------------------------- Reporter: arybczak | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+-------------------------- If you take moderately sized Haskell project (let's use lens as an example) and decide to work with it using `cabal repl`, memory usage of GHCi becomes a bit problematic after a few code reloads. I compared 7.10.3 and 8.0.1 using the following steps: 1. Start GHCi with `cabal repl`. 2. Wait for all modules to load, check memory usage with `htop`. 3. Issue `find . -name '*.hs' -exec touch {} +` in src directory. 4. Issue `:r` in GHCi so it reloads all modules. 5. Repeat (3) and (4) four more times. Results: '''GHC 7.10.3''' * After `cabal repl`: 874MB * After reloading all modules (1st): 1304MB * After reloading all modules (2nd): 1763MB * After reloading all modules (3rd): 2216MB * After reloading all modules (4th): 2672MB * After reloading all modules (5th): 3121MB Basically, every time modules are reloaded memory usage increases by ~450MB, which is definitely not fun. '''GHC 8.0.1''' * After `cabal repl`: 1322MB * After reloading all modules (1st): 2144MB * After reloading all modules (2nd): 2201MB * After reloading all modules (3rd): 2208MB * After reloading all modules (4th): 2212MB * After reloading all modules (5th): 2213MB Here the initial memory usage is much higher as with 7.10.3 and there is a sharp increase after first full reload, but then it more or less plateaus. I presume this change is the result of 6ae616f5be1db6da8bc0c5e36736a76cfea46844 - upfront memory usage is probably higher due to more things being forced (and the fact that memory usage doesn't increase indefinitely is great). However, I'm still concerned about the spike after the first reload - would it be possible to get rid of (or at least decrease) it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 05:32:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 05:32:32 -0000 Subject: [GHC] #12042: Infinite loop with type synonyms and hs-boot In-Reply-To: <045.2af2d998455883876e6ff4ff050c9c9d@haskell.org> References: <045.2af2d998455883876e6ff4ff050c9c9d@haskell.org> Message-ID: <060.f66aaaf58be49f857b9a6f1870ee1d85@haskell.org> #12042: Infinite loop with type synonyms and hs-boot -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: | backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2656 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"31398fbc6d9ee0bd95de64b08becc38faf188972/ghc" 31398fbc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="31398fbc6d9ee0bd95de64b08becc38faf188972" Test for type synonym loops on TyCon. Summary: Previously, we tested for type synonym loops by doing a syntactic test on the literal type synonym declarations. However, in some cases, loops could go through hs-boot files, leading to an infinite loop (#12042); a similar situation can occur when signature merging. This commit replaces the syntactic test with a test on TyCon, simply by walking down all type synonyms until we bottom out, or find we've looped back. It's a lot simpler. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2656 GHC Trac Issues: #12042 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 06:40:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 06:40:32 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.388670653e692e6b152d20e4450bfd55@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Yeah, you might still be required to manually turn on `ENABLE_VIRTUAL_TERMINAL_PROCESSING` and possibly `DISABLE_NEWLINE_AUTO_RETURN` If you get into modifying GHCi to have fancy stuff too. That build is still significant since it's the one that brought native support in `conhost` for VT100 escape sequences. But yeah checking the flag on the buffer is what should be done, but because there's a large number of people using `ANSICON` we should check that too. VT100 support used to be only in the dos driver `ansi.sys` which is what is deprecated. You couldn't use it in Windows but the docs all referred to it. But I'm happy to hear you plan on some Windows love too :). I wouldn't bother going down the road of `SetConsoleTextAttribute`. Unless we want to support the Pre Windows 10 era for this. That said, the design in comment:9 is the perfect way to make this easy to do. You just have a custom renderer then that interprets the `Doc`. Yeah the patch will add `GetConsoleMode` and `SetConsoleMode`, but while they'll be usable for user program, the bootstrap process of GHC doesn't allow you to use libraries not available on the bootstrapping compiler. So you'd have to duplicate the code to inside GHC until a few releases down the road where we can undo the duplication. You'll end up with something like: {{{ isVT100ConsoleSupported :: IO Bool isVT100ConsoleSupported = do isANSIcon <- fmap (maybe False ((/="" ) . map toLower)) $ lookupEnv "ANSICON" isConEmu <- fmap (maybe False ((=="on" ) . map toLower)) $ lookupEnv "ConEmuANSI" isTerm <- fmap (maybe False ((=="xterm") . map toLower)) $ lookupEnv "TERM" hOut <- getStdHandle sTD_OUTPUT_HANDLE outMode <- with 64 $ \ c_mask -> do failIfFalse_ "GetConsoleMode" $ c_GetConsoleMode hOut c_mask peek c_mask return $ or [ isANSIcon , isConEmu , isTerm , let flag = outMode .&. eNABLE_VIRTUAL_TERMINAL_PROCESSING in flag == eNABLE_VIRTUAL_TERMINAL_PROCESSING ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 09:39:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 09:39:36 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.f323ccd4d07a4da32c5118eb5899dabe@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm delighted to see activity on the "better error messages" front. Thank you! There are two separate lines of thought here: 1. Using colour etc in `SDoc`, in a way that is portable across platforms. This seems to be non-trivial (comment:33 and comment:34), but it's non- controversial and it'd be great to have. I think Phab:D2716 and Phab:D2717 are about this. 2. Some infrastructure to allow more info to be displayed in error messages. That's what Phab:D2718 is about. I suggest we split (2) into a separate ticket. On (1) let's just do it. On the (2) front, I confess that I'm not keen on the approach shown in Phab:D2718, which allows an `SDoc` to contain an I/O action. It smells wrong in principle to me; it would fork GHC away from our goal of using the Hackage `pretty` library (#10735); and I think we can do better. I would love to make progress on adopting David Christiansen's idea for pretty printing, which he calls "A pretty printer that says what it means": * [https://www.youtube.com/watch?v=m7BBCcIDXSg Video], * [https://hackerfall.com/story/a-pretty-printer-that-says-what-it-means Blog post] * [https://wiki.haskell.org/wikiupload/4/4c/Hiw-2015-david- christiansen.pdf Slides] * [https://github.com/david-christiansen/hindent Git repo for hindent, an extensible Haskell pretty printer] That's what Ben is alluding to in comment:31. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 10:14:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 10:14:20 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.354c29d0c90f9c24736c6ac6cb818171@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by simonpj): Facundo, your work has exposed some woolly thinking on my part, and I think we need to take a step back to revisit some of our earlier design decisions. I fear that we are now piling hack upon hack and accumulating technical debt that we will later regret. In particular, the desire to accomodate references to local closed defintitions (seee Trac #11656) has led to a raft of unexpected complexity: * We need the `tcg_static_wc` stuff anyway. * The `FloatOut` pass needs special extra stuff, and must always be run. * Similary the SPT construction needs to find all those top-level `StaticPtr` applications. * Now we discover that sometimes nested `StaticPtr` is fine, which leads to further complexity in your patch. All this sounds fragile. We see all the uses of `static` so it seems odd to have to rediscover them when we are constructing the SPT. How important is #11656, really? After all, you can always write those local closed defns at top level! If we recanted on that we could: * Do all the floating work in the type checker (we are doing it alrady with `tcg_static_wc`, prettty much) * And then we'd be done! This seems attractive to me. When in a hole, stop digging! There's always a tradeoff between compiler complexity and language expressiveness. Yes we ''can'' do everything. But life is short, and if we spend time doing X it means we don't have time to Y. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 10:33:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 10:33:41 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.f6cd29454dcfc6a32bf5339fb861cb4b@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That is an admirably clear explanation, thank you. Could you please add it (suitably edited) as a `Note` in the code? I think I buy the idea in principle. But do we have "in the wild" example(s) of where it makes a perceptible difference? Will anyone notice/care? I don't think the implementation is right, I'm afraid, but I'll comment on Phab. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 10:35:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 10:35:03 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.b8e874e688c08a97d065b4b947b28dc2@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS: about incoherence, you could simply disable this optimisation if the user says `-XIncoherentInstances`, which is relatively rare. That would seem plausible to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 11:08:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 11:08:13 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.5b7676dd70f395dbe6d87cc213efcd21@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2657 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Patch looks mostly good thanks! You did not address my remarks about the other uses of `nubAvails`: > So an alternative, perhaps better, would be to rewrite nubAvails to use code very like the above function, so that each Name in the [AvailInfo] takes linear time to add. That's be more robust I guess. > Finally, the other use of nubAvails is in RnNames.findImportUsage. I think extendImportMap could return a [GRE] as the second element of its result pair, instead of [AvailInfo], and then we could use gresToAvailInfo again; but this time we'd need to worry about duplicates. Indeed you added a brand-new call to `nubAvails`! Couldn't we just apply the same medicine to `nubAvails`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 11:26:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 11:26:27 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.4c27879be4df961d53d2777aabb39a4b@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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Let me just say: the current status quo of `HsSyn` is not a matter of careful design, and I'm quite open to moving it around. For example, we should fix comment:10 by fixing `HsSyn`! If I don't comment much it's because I'm happy to see progress here, but busy; not because I'm resisting it :-). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 13:42:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 13:42:44 -0000 Subject: [GHC] #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 In-Reply-To: <042.ae1a4a171fe54fc9b54d80da6024e345@haskell.org> References: <042.ae1a4a171fe54fc9b54d80da6024e345@haskell.org> Message-ID: <057.90b15552ee1c8d36317b4f3eebab3c1b@haskell.org> #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Other | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:1 rwbarton]: > you seem to be invoking `ghci` and then running `:set -fforce-recomp -fobject-code -O2 -v` I am. Your guess seems right, if I start ghci on the command line with these flags, it's just as slow as ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 13:43:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 13:43:12 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.501b8148811317521fbf4881094197a3@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 13:55:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 13:55:59 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.0750be16b4708d7079bbb03a983d2fa6@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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Shayan-Najd): * cc: Shayan-Najd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 14:02:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 14:02:43 -0000 Subject: [GHC] #12845: -XPartialTypeSignatures results in unbound variables In-Reply-To: <047.fe1a80c8e93b6a208be7bf5baa2818e3@haskell.org> References: <047.fe1a80c8e93b6a208be7bf5baa2818e3@haskell.org> Message-ID: <062.a0c3cda17801aa0fb3234bfb5d43c37a@haskell.org> #12845: -XPartialTypeSignatures results in unbound variables -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): If I'm reading this right, this appears to work in GHC HEAD: {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.1.20161010: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:16:70: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘() :: Constraint’ • In the type signature: broken :: forall r r' rngs. ('(r, r') ~ Head rngs, Bar r r' ~ True, _) => Foo r -> Proxy rngs -> () Ok, modules loaded: Main. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 14:14:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 14:14:00 -0000 Subject: [GHC] #12702: Don't warn about redundant constraints for necessary In-Reply-To: <047.cc981f71763ded67bdb12dbf587461a5@haskell.org> References: <047.cc981f71763ded67bdb12dbf587461a5@haskell.org> Message-ID: <062.6531fa315278f6792024c1c103adc97b@haskell.org> #12702: Don't warn about redundant constraints for necessary -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.0.2 Comment: I can't reproduce the warning on GHC 8.0.2. Sadly, this test case requires lots of `singletons` machinery, which is darn-near impossible to boil down to a simple test case. I'm going to just close this as being fixed in 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 15:18:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 15:18:42 -0000 Subject: [GHC] #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) In-Reply-To: <048.d4deec05c6f31ed2d01747b4defade16@haskell.org> References: <048.d4deec05c6f31ed2d01747b4defade16@haskell.org> Message-ID: <063.03c14e2fe1003d8a702cf9997cade8cd@haskell.org> #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2726 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D2726 * milestone: => 8.2.1 Comment: I've submitted a patch for this, as discussed at https://mail.haskell.org/pipermail/libraries/2016-November/027396.html. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 15:41:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 15:41:34 -0000 Subject: [GHC] #10614: Show constraints in ``Found hole...'' In-Reply-To: <047.e629c8600a92660c55de2127511a14cd@haskell.org> References: <047.e629c8600a92660c55de2127511a14cd@haskell.org> Message-ID: <062.cece2f92c5f3cc2771bcac671bb00a79@haskell.org> #10614: Show constraints in ``Found hole...'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:3 zyla]: > +1 for class constraints. This comes up a lot when working with existentials. Consider this (contrived) example: +1 not so contrived, I have encountered it and more complex examples -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 16:04:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 16:04:13 -0000 Subject: [GHC] #12840: GHC-internal triplets passed to sub-project configure scripts In-Reply-To: <045.2e2c224d7fdf415c0b1a95252433ab8a@haskell.org> References: <045.2e2c224d7fdf415c0b1a95252433ab8a@haskell.org> Message-ID: <060.933c49b3ba2cfb8f750d27497af992bb@haskell.org> #12840: GHC-internal triplets passed to sub-project configure scripts -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9a4983dab9893f616db1c9be551ff9112084f887/ghc" 9a4983da/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9a4983dab9893f616db1c9be551ff9112084f887" Pass autoconf triplets to sub-project configures Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D2713 GHC Trac Issues: #12840 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 16:04:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 16:04:13 -0000 Subject: [GHC] #12777: reify yields the wrong type in the presence of functional dependencies In-Reply-To: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> References: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> Message-ID: <071.c234ca3ead5d06d026fa4b4a1123e110@haskell.org> #12777: reify yields the wrong type in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: template- | haskell reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2659 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"231a3ae1644403c1f295e993105c4346d0db22db/ghc" 231a3ae1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="231a3ae1644403c1f295e993105c4346d0db22db" Have reify work for local variables with functional dependencies. It turned out that finalizers were run too early and information resulting from simplifying constraints was not available. This patch runs finalizers after a first call to simplifyTop, and then calls simplifyTop a second time to deal with constraints that could result from running the finalizers. Fixes T12777 Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari, austin Reviewed By: simonpj Subscribers: mpickering, mboes, thomie Differential Revision: https://phabricator.haskell.org/D2659 GHC Trac Issues: #12777 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 16:04:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 16:04:13 -0000 Subject: [GHC] #8321: improve basic block layout on LLVM backend by predicting stack/heap checks In-Reply-To: <047.6404a13417433923604862bc63a62420@haskell.org> References: <047.6404a13417433923604862bc63a62420@haskell.org> Message-ID: <062.7ddc1b6cf34efc82400e1a7a36fbf40c@haskell.org> #8321: improve basic block layout on LLVM backend by predicting stack/heap checks -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | 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 Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"20fb781ed1825578c5428ff4ae408be034c6a1d8/ghc" 20fb781e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="20fb781ed1825578c5428ff4ae408be034c6a1d8" LLVM generate llvm.expect for conditional branches This patch adds likeliness annotations to heap and and stack checks and modifies the llvm codegen to recognize those to help it generate better code. So with this patch ``` ... if ((Sp + 8) - 24 < SpLim) (likely: False) goto c23c; else goto c23d; ... ``` roughly generates: ``` %ln23k = icmp ult i64 %ln23j, %SpLim_Arg %ln23m = call ccc i1 (i1, i1) @llvm.expect.i1( i1 %ln23k, i1 0 ) br i1 %ln23m, label %c23c, label %c23d ``` Note the call to `llvm.expect` which denotes the expected result for the comparison. Test Plan: Look at assembler code with and without this patch. If the heap-checks moved out of the way we are happy. Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: michalt, thomie Differential Revision: https://phabricator.haskell.org/D2688 GHC Trac Issues: #8321 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 16:04:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 16:04:13 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.e194772b11f0f5df8a7624723860ce8c@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4d4f3533e6ec8698f8af30977c81f17eed1f6970/ghc" 4d4f3533/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4d4f3533e6ec8698f8af30977c81f17eed1f6970" testsuite: Rip out hack for #12554 @Phyx is working on correctly fixing (pun intended) the underlying issue that prompted this hack. It turns out that `timeout` it the culprit. Moreover, this hack breaks on msys python builds, which don't export `WindowsError`. Test Plan: Validate on Windows with `msys` python. Reviewers: Phyx, austin Subscribers: thomie, Phyx Differential Revision: https://phabricator.haskell.org/D2724 GHC Trac Issues: #12554 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 19:20:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 19:20:05 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.f2b8694ad7964f1ea1c0499f170ce517@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Hello Simon, #11656 is needed for programming in the large, similarly to how local definitions avoid polluting the top-level namespace of a module with many functions that relate to its very internals, which would make it harder to maintain it. Of the points you raise, the first three are what we designed it to be from the start. But I agree that the mechanism for the linter to discern static forms is more involved than expected. We might review this mechanism, but I feel it would be excessive to disregard support for local definitions because of linting. As an example of how the namespace pollution prevented using static pointers, I offer a use case where StaticPtrs were used to persist and share the states of a state machine. If static forms did not support local definitions, then a module with many state machines with many states and events each would have to bear a lot of "internal" top-level functions. {{{ -- | This module defines state machines whose state can be serialized -- and execution can be resumed later. It uses the package distributed- closure -- to create the closures. {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE StaticPointers #-} {-# LANGUAGE TypeSynonymInstances #-} module Main where import Control.Distributed.Closure import Control.Monad import GHC.StaticPtr -- | A state can be final, in which case it yields a result, or it provides -- a computation which yields the next state. -- -- The Closure type is used to keep track of the current state, and it -- can be persisted or sent to other nodes for subsequent execution. -- -- In this implementation machines have a single push-button. Transitions are -- done at the user request. It would be possible to extend it to react to -- other events. newtype MState m a = MState (Closure (m (NextState m a))) type NextState m a = Either (MState m a) a -- | @anbncn@ is a state machine which recognizes words in the set -- @{ a^n b^n c^n | n <- [1..] }@. -- -- It yields the amount of repetitions @n@ found in the input. anbncn :: MState IO Int anbncn = MState $ mkClosure (static as) 0 where as :: Int -> IO (NextState IO Int) as an = do x <- getChar return $ case x of 'a' -> Left $ MState $ mkClosure (static as) (an + 1) 'b' | an > 0 -> Left $ MState $ mkClosure (static bs) (an, 1) _ -> Right 0 bs :: (Int, Int) -> IO (NextState IO Int) bs (an, bn) = do x <- getChar return $ case x of 'b' -> Left $ MState $ mkClosure (static bs) (an, bn + 1) 'c' | an == bn -> Left $ MState $ mkClosure (static cs) (an, 1) _ -> Right 0 cs :: (Int, Int) -> IO (NextState IO Int) cs (an, cn) = do x <- getChar return $ case x of 'c' | an == cn + 1 -> Right $ cn + 1 | otherwise -> Left $ MState $ mkClosure (static cs) (an, cn + 1) _ | an == cn -> Right cn | otherwise -> Right 0 -- Make one transition. pushButton :: MState m a -> m (NextState m a) pushButton (MState c) = unclosure c -- Make all transitions of the state machine. runStateMachine :: Monad m => MState m a -> m a runStateMachine = pushButton >=> either runStateMachine return main :: IO () main = do putStrLn "start typing a, b or c" n <- runStateMachine anbncn putStrLn $ "The amount of repetitions is " ++ show n -- | Produces a closure from a static pointer and a serializable value. mkClosure :: Static (Serializable a) => StaticPtr (a -> b) -> a -> Closure b mkClosure sp a = closure sp `cap` cpure closureDict a instance Static (Serializable Int) where closureDict = closure $ static Dict instance Static (Serializable (Int, Int)) where closureDict = closure $ static Dict }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 20:24:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 20:24:26 -0000 Subject: [GHC] #7983: Bug in hsc2hs --cross-safe In-Reply-To: <049.3ff36c949c6061d8d14e6939f732b877@haskell.org> References: <049.3ff36c949c6061d8d14e6939f732b877@haskell.org> Message-ID: <064.fb68d465b89a8c2a00c02b15462139ac@haskell.org> #7983: Bug in hsc2hs --cross-safe -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): There seem to be two issues here. 1. The program is accepted by `hsc2hs --cross-safe` even though it's rejected by `hsc2hs --cross-compile`. 2. The program is rejected by `hsc2hs --cross-compile` for reasons that seem to have to do with the use of doubles. The ticket seems to have been intended to be about 1, since it's titled "Bug in `hsc2hs --cross-safe`". In general this has nothing to do with the weirdness of point 2. For example, you could write something clearly non- constant like `(#const getpid())`. hsc2hs will accept this in direct mode, which is okay I think; but it certainly won't work in cross-compiling mode, so `hsc2hs --cross-safe` should reject it too. I think this should be easy to implement: just include the output of `CrossCodegen.outValidityCheck` in the direct code generation path as well, if `--cross-safe` is enabled. I will create a separate ticket for point 2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 20:31:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 20:31:59 -0000 Subject: [GHC] #12849: hsc2hs trouble with floating-point constants in cross-compilation mode Message-ID: <047.46c01c39d34e38098ebb27c55a6af53b@haskell.org> #12849: hsc2hs trouble with floating-point constants in cross-compilation mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Split off from #7983. GCC 4.6 rejects some uses of floating-point constants in the declaration of a local static array. From ticket:7983#comment:5: > This is caused by a regression in GCC from gcc-4.4 to gcc-4.6: ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46028 > > {{{ > $ cat Test_hsc_test0.c > void _hsc2hs_test1() > { > static int test_array[(89.) > 0 ? 2 : 1]; > } > > $ /usr/bin/gcc-4.4 -c ./Test_hsc_test0.c > > $ /usr/bin/gcc-4.6 -c ./Test_hsc_test0.c > ./Test_hsc_test0.c: In function ‘_hsc2hs_test1’: > ./Test_hsc_test0.c:3:16: error: storage size of ‘test_array’ isn’t constant > }}} This means that (if your C compiler is affected by this issue) hsc2hs can't handle {{{ (#const 89.) }}} in cross-compilation mode. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 20:37:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 20:37:03 -0000 Subject: [GHC] #7983: Bug in hsc2hs --cross-safe In-Reply-To: <049.3ff36c949c6061d8d14e6939f732b877@haskell.org> References: <049.3ff36c949c6061d8d14e6939f732b877@haskell.org> Message-ID: <064.bbb6975fc0056b1015d0dffb873e6d04@haskell.org> #7983: Bug in hsc2hs --cross-safe -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Created #12849. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 21:01:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 21:01:58 -0000 Subject: [GHC] #12846: On Windows, runtime linker can't find function defined in GHC's RTS In-Reply-To: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> References: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> Message-ID: <065.448d2dd0eddf418b4ad03687fb42d3ee@haskell.org> #12846: On Windows, runtime linker can't find function defined in GHC's RTS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2727 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: => Phab:D2727 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 21:07:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 21:07:40 -0000 Subject: [GHC] #12849: hsc2hs trouble with floating-point constants in cross-compilation mode In-Reply-To: <047.46c01c39d34e38098ebb27c55a6af53b@haskell.org> References: <047.46c01c39d34e38098ebb27c55a6af53b@haskell.org> Message-ID: <062.6e27d7a514df6581be1891e5e2e0b5fa@haskell.org> #12849: hsc2hs trouble with floating-point constants in cross-compilation mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I did some experiments with {{{ gcc (Debian 5.3.1-6) 5.3.1 20160114 }}} which also has this issue and {{{ Debian clang version 3.6.2-3 (tags/RELEASE_362/final) (based on LLVM 3.6.2) }}} which does not. There seems to be a class of what appear to be constant expressions involving floating-point constants which has the following behavior: * If used as the size of a local static array, gcc gives an error like `storage size of ‘x’ isn’t constant`. * If used as the size of a global array, gcc gives a ''warning'' `variably modified ‘x’ at file scope`. But it's not fatal, and clearly gcc must know the actual size of the array. Very strange! (If the size of a global array is not a constant expression at all, then gcc gives the same message but as an ''error''.) The simplest example of such an expression I found was `(int)(1.0 + 1)`. Clang seems to have no problem with floating-point numbers in constant expressions. So, if we can switch to use global arrays instead of local static arrays for the tests, and ignore these `variably modified` warnings from gcc, we should be able to handle constant expressions involving floating-point numbers correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 21:10:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 21:10:13 -0000 Subject: [GHC] #12849: hsc2hs trouble with floating-point constants in cross-compilation mode In-Reply-To: <047.46c01c39d34e38098ebb27c55a6af53b@haskell.org> References: <047.46c01c39d34e38098ebb27c55a6af53b@haskell.org> Message-ID: <062.063fcab389e2f98eb19ea2d139a3463d@haskell.org> #12849: hsc2hs trouble with floating-point constants in cross-compilation mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): A separate issue about hsc2hs and floating-point types: the argument to `#const` gets cast to `long` in direct mode. The hsc2hs manual alludes to this, but does not state it explicitly. So for example, `#const (-1.9)` produces the output `-1`. We should state this explicitly in the manual, and also insert a cast to `long` in the cross-compilation code path to ensure that it matches the direct code path output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 21:50:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 21:50:50 -0000 Subject: [GHC] #8321: improve basic block layout on LLVM backend by predicting stack/heap checks In-Reply-To: <047.6404a13417433923604862bc63a62420@haskell.org> References: <047.6404a13417433923604862bc63a62420@haskell.org> Message-ID: <062.852b7043fccbd1a2fc07f9ff59fcfb44@haskell.org> #8321: improve basic block layout on LLVM backend by predicting stack/heap checks -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (LLVM) | 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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 22:05:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 22:05:42 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.fadd81d2e06437c3fc046e57558320f9@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2613 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): bgamari notes that the cabal08 test will need to be adjusted once we fix this properly. We dropped the test for GHC 8.0 since it wasn't really testing something meaningful. The Cabal change is here https://github.com/haskell/cabal/pull/4008 but Duncan objected to computing ABI hashes on every build, so the patch is in limbo right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 17 22:58:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 17 Nov 2016 22:58:47 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.037e80cd3bd909a2db03fd347bc0e279@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by goldfire): Your analysis is spot on. Thank you! The problem is (as you may have suspected) that comment on `newMetaTyVars`. It's just plain wrong. The problem is that we must always obey '''The substitution invariant''' from the eponymous Note in !TyCoRep: {{{ When calling (substTy subst ty) it should be the case that the in-scope set in the substitution is a superset of both: * The free vars of the range of the substitution * The free vars of ty minus the domain of the substitution }}} `new_meta_tv_x` takes care to make sure, as it's building the substitution, that the first point is obeyed. But no one is handling the second point!j Perhaps it was envisioned that `nwMetaTyVars` would be called only on a '''closed''' sequence of tyvars. But the function doesn't say that, and evidently it's not true. (I doubt it ever was!) So it seems the answer is to add an `InScopeSet` parameter to `newMetaTyVars` that should contain the free variables of the type being instantiated. Does that help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 00:05:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 00:05:47 -0000 Subject: [GHC] #12850: Panic with unboxed integers and ghci Message-ID: <047.0ea5f00888799dccd8ce378372f99f9b@haskell.org> #12850: Panic with unboxed integers and ghci -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Attempting to load the following file in ghci causes a panic in getIdFromTrivialExpr. Tested in GHC 8.0.1 and HEAD. {{{ {-# LANGUAGE ExplicitForAll, MagicHash, KindSignatures #-} import GHC.Types (RuntimeRep(..), TYPE) f :: forall (x :: TYPE 'IntRep). x -> x f x = x g = () where h = f 0# }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 04:35:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 04:35:54 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.8f0dbffe57de71b35fb200e0dda5597c@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The patch that Simon was referring to in comment:4 was eefe86d96d40697707c3ddfb9973a30a1897241f. Unfortunately this doesn't fix the issue which described by this ticket; the typechecker still rejects the program given in the ticket description. Richard and I discussed this a few weeks ago and came to a solution which looks something like this, {{{#!patch diff --git a/compiler/typecheck/TcPatSyn.hs b/compiler/typecheck/TcPatSyn.hs index 5c62121..62724c8 100644 --- a/compiler/typecheck/TcPatSyn.hs +++ b/compiler/typecheck/TcPatSyn.hs @@ -13,6 +13,7 @@ module TcPatSyn ( tcInferPatSynDecl, tcCheckPatSynDecl ) where import HsSyn +import TcHsSyn( checkForRepresentationPolymorphism ) import TcPat import Type( mkTyVarBinders, mkEmptyTCvSubst , tidyTyVarBinders, tidyTypes, tidyType ) @@ -312,6 +313,9 @@ tc_patsyn_finish lname dir is_infix lpat' arg_tys = tidyTypes env2 arg_tys' pat_ty = tidyType env2 pat_ty' + -- Check that the arguments aren't representationally polymorphic + ; mapM_ (checkForRepresentationPolymorphism empty) arg_tys + ; traceTc "tc_patsyn_finish {" $ ppr (unLoc lname) $$ ppr (unLoc lpat') $$ ppr (univ_tvs, req_theta, req_ev_binds, req_dicts) $$ diff --git a/compiler/typecheck/TcTyClsDecls.hs b/compiler/typecheck/TcTyClsDecls.hs index c009bc9..9335676 100644 --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -2296,6 +2296,9 @@ checkValidDataCon dflags existential_ok tc con -- Check all argument types for validity ; checkValidType ctxt (dataConUserType con) + -- Check for representationally polymorphic fields + ; mapM_ (checkForRepresentationPolymorphism empty) (dataConOrigArgTys con) + -- Extra checks for newtype data constructors ; when (isNewTyCon tc) (checkNewDataCon con) diff --git a/compiler/typecheck/TcValidity.hs b/compiler/typecheck/TcValidity.hs index 6cc40a5..c9f3bda 100644 --- a/compiler/typecheck/TcValidity.hs +++ b/compiler/typecheck/TcValidity.hs @@ -487,8 +487,6 @@ check_type _ _ _ (TyVarTy _) = return () check_type env ctxt rank (FunTy arg_ty res_ty) = do { check_type env ctxt arg_rank arg_ty - ; when (representationPolymorphismForbidden ctxt) $ - checkForRepresentationPolymorphism empty arg_ty ; check_type env ctxt res_rank res_ty } where (arg_rank, res_rank) = funArgResRank rank }}} Unfortunately this still doesn't fix the Core Lint issues that inevitably pop up when you try to use such a type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 08:44:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 08:44:14 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.66a6f719eb26aae420f0c0170ca8818c@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think our new paper [https://www.microsoft.com/en- us/research/publication/levity-polymorphism/ Levity polymorphism] shows how to fix this. Richard is working on the implementation. Are you stuck on this? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 08:49:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 08:49:58 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore Message-ID: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: regression | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sorry for chiming in so late, I didn't notice #12807 and I didn't build GHC HEAD for several days, otherwise I would have cried out loud sooner. I'm deliberately declaring this a regression since I consider this a bad default. And not for the mere fact that change is bad ;-) Don't get me wrong, I can see usefulness in the `-fno-show-source-paths` feature (although I consider it inconsistent, see below), but it's a bad default because in my workflows I rely on seeing the source-path ''by default'', and I see no way to restore this as the default behaviour of GHC short of patching GHC. {{{ [1 of 1] Compiling Control.Concurrent.STMSupply (.hs -> .o) }}} First of all, if we drop filepaths, then please drop them completely, either I need more information about which `.hs` file was used as source, or I don't need it at all, so this ` (.hs -> .o)` suffix is just noise to me; not the least because the `-> .o` part carries almost no information for me. If the premise of `-fno-show-source-paths` is that we know how we called GHC and thereby know what is being compiled, showing `(.hs -> .o)` is pointless. Morever, `-f(no-)show-source-paths` is a lie/misnomer, as it doesn't only control the *source* path display, but *also* the *output* path display! Also, when invoking GHC, and pass it multiple include folders, sometimes GHC picks up the wrong module (or rather one I didn't intend), having it print the source file path by default has been a big timesaver to me, detecting when I was barking up the wrong source-file while figuring out why stuff didn't work. Finally, this also breaks my shell-based workflow because I'm used to copy'n'paste filepaths from GHC's output, especially for longer source- paths where tab-completing my way to the source path is too tedious. This is just the first impression I got while being exposed to this UI change today, there may be other regressions I'd notice when having to use this for longer. So, in summary I propose to - Make `-fshow-source-paths` the default again - drop the `(.hs->.o)` suffix in `-fno-show-show-source-paths` - consider a better name; actually, I can see cases where you want to omit only the output-path display (since it's imho often less interesting to know the output files names; even though sometimes you may want to know it since it can be affected in a non-obvious way by output-dir flags), e.g. maybe - Have `-f(no-)show-source-paths` control the source-path display - Have `-f(no-)show-output-paths` control the output-path display - As a compromise, consider `-fshow-source-paths -fno-show-output- paths` becoming the new default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 08:50:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 08:50:36 -0000 Subject: [GHC] #12846: On Windows, runtime linker can't find function defined in GHC's RTS In-Reply-To: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> References: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> Message-ID: <065.0bc9fc7d697a20c6fdea4b4ac8cfae0d@haskell.org> #12846: On Windows, runtime linker can't find function defined in GHC's RTS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2727 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"94d1221cfb31188990738e7f7cbb3ae0a30c9f98/ghc" 94d1221/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="94d1221cfb31188990738e7f7cbb3ae0a30c9f98" Add missing SMP symbols to RT linker. Summary: Add some missing symbols that we export from the public headers but forgot to include in the runtime linker's symbol table. This is a bit of a unsatifactory patch, since we have a bit of a cat and mouse game going. We should find a way to automate this. But I know of no good solutions at the moment that won't add all rts symbols (including those we don't have an extern declaration for.). So for now, just add the ones reported missing. Test Plan: inplace/bin/ghc-stage2.exe --interactive Reviewers: RyanGlScott, austin, erikd, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2727 GHC Trac Issues: #12846 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 08:58:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 08:58:54 -0000 Subject: [GHC] #12850: Panic with unboxed integers and ghci In-Reply-To: <047.0ea5f00888799dccd8ce378372f99f9b@haskell.org> References: <047.0ea5f00888799dccd8ce378372f99f9b@haskell.org> Message-ID: <062.27b2e0e548272bfe114c6bce8b9fdbf5@haskell.org> #12850: Panic with unboxed integers and ghci -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ezyang (added) Comment: GHC shouldn't panic, but is GHCi supposed to handle unboxed values, these days? I've lost track. Edward in 11ff1df8 made some changes to `getIdFromTrivialExpr`. Edward might you look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 09:18:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 09:18:30 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.c9e08104b0a066375e1bb0db2934ab19@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by simonpj): Well, maybe. There is a complexity-budget cost that I remain anxious about. If you want to pursue the current line, let's not introduce a "twin" data constructor. Rather, how about this: * Make `(static e)` expand into the ordinary function call `makeStatic e` * Make the float-out pass spot those calls (instead of spotting the `StaticPtr` data constructor) and float them to the top. * Make the SPT construction spot those calls, gather them into a table, generate a GUID or whatever for each, and allocate a `StaticPtr` data consructor for each. That way all the magic of building `StaticPtr` constructors is in one place. Would that work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 10:44:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 10:44:47 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.b1e188a3ce6f18ddab74f17e4a2d896d@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): I agree that this change throws away useful information while keeping in not so useful one. I would do it simpler though: If verbose, show information as it used to be show, with full paths. If not verbose, show just module name. Note that haskell-mode filters out everything after module name and this is expected behavior by newbees or when smaller projects are compiled. For more complicated projects hvr and other can increase verbosity level. I would also postulate to *not* add new flag with such low marginal utility and just use the existing verbosity level for this purpose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 13:25:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 13:25:59 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.3c0faf242d793b6cb6192f766e901f42@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The fix for this is in branch `wip/T12819`. But I haven't had time to tie the patch up with a bow on top (put tests in, re-validate, etc). Soon. Soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 13:39:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 13:39:29 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.4d21989acc4ce5b129cad0b8e67d48e2@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Author of the aformentioned patch here. Sorry for the lack of advertising of this change. 1. I didn't want the patch to be too radical, that is why I left the extensions "(.hs -> .o)": the paths could be inferred from the module name (at least in simple cases) but the extensions may not (.lhs for instance). I kept the previous object path display: "nothing"/"interpreted" when the target is HscNothing/HscInterpreted. Nevertheless I agree that we could totally avoid it. It is already what haskell-mode is doing (thanks @gracjan for the comment on Phab:D2679#79222). So this doesn't seem to be controversial and I will make a patch for this. 2. Do we need a new flag? Initially SPJ asked for one in #12807 to restore the old behaviour and it avoids enabling a too verbose mode. Also we would like verbosity levels to be aliases for sets of verbosity flags (see #12822). 3. Flag name: there has been a little bikeshedding about the flag name already (see Phab:D2679#77954). Initially I chose "-fshow-module-paths" but @nomeata thought "-fshow-source-paths" would be better and I don't have a strong opinion on it. I agree that having two flags (for source/object paths) would be more correct. 4. Hiding the object path by default: it doesn't seem controversial. Let's do that. 5. Hiding the the source path by default: I think we should as it is more newcomer friendly and in most cases I think we don't care about it (but I agree that it depends on your workflow). haskell-mode already hides it. Maybe we should have a poll on haskell-cafe or something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 13:41:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 13:41:59 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.43ec4e3281b69c353ea8b2053ae91410@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I infer that: * `makeStatic` should never be unfolded, * FloatOut needs to treat it specially when **deciding what to float** (unlike it does now with `StaticPtr`) * Besides keeping the floated bindings, the optimizations should never inline them, or the SPT construction pass wouldn't replace the inlined calls to `makeStatic`. * the SPT construction needs to do more work (which is replacing this call with a StaticPtr). It is probably doable, but how is it simpler than using the twin data constructor? Something that could be simpler is to stop relaying on the FloatOut pass. Instead: 1. As you suggest: Make `static e` expand into the ordinary function call `makeStatic e` 2. Make the SPT construction phase float all such calls and insert them in the SPT. Thus there is no need to worry about unfloated calls during linting and there will be no interference from optimizations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 14:40:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 14:40:35 -0000 Subject: [GHC] #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) In-Reply-To: <048.d4deec05c6f31ed2d01747b4defade16@haskell.org> References: <048.d4deec05c6f31ed2d01747b4defade16@haskell.org> Message-ID: <063.de5c47b9085772ab0f5fde7dd35d729a@haskell.org> #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2726 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"3bd1dd4d75fde3b922d4de08c16f29bdeb8e05d7/ghc" 3bd1dd4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3bd1dd4d75fde3b922d4de08c16f29bdeb8e05d7" Add Data instance for Const Summary: Fixes #12438. As discussed on the Haskell libraries mailing list here: https://mail.haskell.org/pipermail/libraries/2016-November/027396.html Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2726 GHC Trac Issues: #12438 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 14:41:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 14:41:37 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.9073ddea67bdf0f7fb6789075e670ea1@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by simonpj): I'm a bit lost reading comment:11. What is step (2)? Lots of stuff is crossed out. Yes `makeStatic` should not be unfolded. I'm not sure why `FloatOut` would need to treat `makeStatic` any more specially than it did `StaticPtr`. Yes, the top level binding `x = makeStatic y` should not be inlined; but I think that'll be the case anyway. Yes, some stuff (making a fingerprint, and `StaticPtr` value) is moved from the desugarer to the SPT construction -- that's a feature! It looks good to me. If you think another approach is better, by all means describe it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 14:42:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 14:42:04 -0000 Subject: [GHC] #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) In-Reply-To: <048.d4deec05c6f31ed2d01747b4defade16@haskell.org> References: <048.d4deec05c6f31ed2d01747b4defade16@haskell.org> Message-ID: <063.869ea1b28ec3d0225e7ff697cc0b9082@haskell.org> #12438: DeriveDataTypeable - deriving instance Data (Mu (Const ())) -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2726 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 15:01:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 15:01:02 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.9186df02049702d0a91ca088225bbfb3@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I've edited the comment to make it clear, I hope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 15:32:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 15:32:05 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.048491fd1224f41f9c783a11b6f55c1c@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Why I don't have a terribly strong opinion here one way or another, here are my thoughts, * I agree that, to a GHC developer, hiding paths by default is on the whole a small inconvenience. There is a certain convenience to pulling paths out of `ghc --make`. * I also agree that these paths are just noise to most users * However, I suspect that relatively few users are actually exposed to this noise at this point. Afterall, most users are using `stack` or `cabal-install` and both of those now hide GHC's output by default. * Even if the user uses a build tool which shows GHC's output (as `cabal- install` currently does with `-j1`), there's no reason why the tool couldn't pass `fno-show-source-paths` to GHC by default. * I really don't think the benefit-per-character-of-discussion ratio of this issue is high enough to warrant too many cycles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 15:32:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 15:32:58 -0000 Subject: [GHC] #12807: GHC is too verbose by default (source/object paths) In-Reply-To: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> References: <045.d012e117a49b5802c006389c03d8ce23@haskell.org> Message-ID: <060.c4ccb7a95ded3bc3de246def23c460db@haskell.org> #12807: GHC is too verbose by default (source/object paths) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12851 | Differential Rev(s): Phab:D2679 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #12851 Comment: The decision to move ahead with this has been drawn into question. See #12851 for part two of the saga. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 15:33:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 15:33:29 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.fb56cb01003d49413c192e77edcc1d37@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:2 hsyl20]: Why exactly is this considered "more newcomer friendly" if the source-path is shown by default when directly interacting with `ghc`'s CLI? Moreover, why should we optimise `ghc` for beginners (which are beginners for a relatively short time) to the detriment of the much larger group of experienced users? Isn't it better to maximise overall benefit (c.f. [Utilitarianism](https://en.wikipedia.org/wiki/Utilitarianism)). I also don't understand how `haskell-mode` hiding the paths by default provides any justification for GHC doing the same. `haskell- mode`/`cabal`/`stack` are IDEs/frontends around GHC, and are free to control the verbosity of GHC (and they all have configuration files which can be used to change the default verbosity). But this besides the point here, as this is about `ghc`'s default UI and there's no equivalent mechanism for `ghc` (there is for `ghci` to some degree via `~/.ghci` btw) to restore the default I consider best for my workflow. In any case, I'm feeling very strong about this, and you'll have to convince me before I can accept this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 16:01:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 16:01:01 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.b93d33c85e6a81cf671c70b9f622e504@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): > I really don't think the benefit-per-character-of-discussion ratio of this issue is high enough to warrant too many cycles I take a little offense with this statement as there were many cycles burt by haskell-mode logic tryng to filter out ghc noise, filtering too much or too little and requiring update with each new ghc version, new cabal, new stack and nix updates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 16:03:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 16:03:46 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.a0aa902d32464715c956d5cd7015d164@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): And since we are discussion this part of GHC output, can we get a flag to disable all of progress wholesale? I have a project with 250 modules, ghci's :reload produces a couple of screenfuls of useless information. Note that errors/warnings have their location attributed anyway, which is good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 16:08:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 16:08:14 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.b076e436601c8680335c6c11812fe37f@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2657 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The call to `nubAvails` wasn't added, I pushed it into the branch which deals with an explicit export list, where we actually need to do the nubbing. It doesn't seem like too much work to make the function deal with duplicates correctly. I'm not sure the other places are too critical but I will keep it in mind if I am ever working in that area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 16:13:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 16:13:29 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.87c430efe2141d17147e2baf2a7122b8@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): You can already use `-v0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 16:18:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 16:18:38 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.b049603377c73e7345d6411ac285b242@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2728 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D2728 Comment: @bgamari: I use stack and it still shows GHC's output. @hvr: I think it is more newcomer friendly because I think it is noise for them. But it is also noise for me even if I am not a beginner. As in the end I can't speak for newcomers, I will be fine with any -fno-show- whatever-paths flag. Proposed patch: Phab:D2728 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 16:29:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 16:29:45 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.4b208bf0cafb3812a7a691b5f6ab5923@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2657 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"4b72f859cd03ad3104c3935ea83ede68d0af6220/ghc" 4b72f85/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4b72f859cd03ad3104c3935ea83ede68d0af6220" Optimise whole module exports We directly build up the correct AvailInfos rather than generating lots of singleton instances and combining them with expensive calls to unionLists. There are two other small changes. * Pushed the nubAvails call into the explicit export list branch as we construct them correctly and uniquely ourselves. * fix_faminst only needs to check the first element of the export list as we maintain the (yucky) invariant that the parent is the first thing in it. Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: simonpj, thomie, niteria Differential Revision: https://phabricator.haskell.org/D2657 GHC Trac Issues: #12754 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 16:38:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 16:38:05 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.c09c1cba55976b0321f7a623806abe4c@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Are you stuck on this? To an extent, yes I was. The problem is that I cannot really use the `TRFun` that we introduced if I define it as, {{{#!hs data TypeRep (a :: k) where TRFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). TypeRep arg -> TypeRep res -> TypeRep (arg -> res) ... }}} due to the overly strict representational polymorphism checks described in this ticket. I thought would workaround would be to even further narrow the types represented by `TypeRep`. Namely, we only represent arrow types where both `arg` and `res` are of kind `Type`, {{{#!hs data TypeRep (a :: k) where TRFun :: forall arg res. TypeRep arg -> TypeRep res -> TypeRep (arg -> res) ... }}} However, this leads to trouble when implementing serialization, {{{#!hs putTypeRep :: TypeRep a -> Put putTypeRep (TRCon a b c) = putWord8 0 >> ... putTypeRep (TRApp a b c) = putWord8 1 >> ... putTypeRep (TRFun arg res) = putWord8 2 >> putTypeRep arg >> putTypeRep res ... getSomeTypeRep :: Get SomeTypeRep getSomeTypeRep = do tag <- getWord8 case tag of 0 -> ... 1 -> ... 2 -> do arg <- getSomeTypeRep res <- getSomeTypeRep {- uh oh! We don't know the kinds of arg and res -} return (TRFun arg res) }}} The trouble here is that, since we have dropped `typeRepKind`, we have no way of verifying during deserialization that `arg` and `res` indeed have kind `Type`. However, it sounds like `wip/T12819` should unstick me; if I'm not mistaken none of this should be problematic assuming we are able to represent arrows with arbitrary argument and result kinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 16:43:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 16:43:43 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.12491dbc4848d5e55eb6908e96f0f555@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Simon and Richard's recent PLDI paper on [[https://www.microsoft.com/en- us/research/publication/levity-polymorphism/|levity polymorphism]] is quite relevant to this ticket (and in fact cites it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 16:45:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 16:45:33 -0000 Subject: [GHC] #12777: reify yields the wrong type in the presence of functional dependencies In-Reply-To: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> References: <056.0bf64efa238ee4fc6a20edd88857408a@haskell.org> Message-ID: <071.8ffee6b15bf50987709baa2483951e09@haskell.org> #12777: reify yields the wrong type in the presence of functional dependencies -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: template- | haskell reify Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2659 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This was merged to `ghc-8.0` as e7c12cdaa7df8a7c71395da026c003ed36d3cbe6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 17:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 17:13:54 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.6b880aced09c8d0abc6a65b046067036@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2728 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I take a little offense with this statement as there were many cycles burt by haskell-mode logic tryng to filter out ghc noise, filtering too much or too little and requiring update with each new ghc version, new cabal, new stack and nix updates. Oh dear, I really didn't intend for this to be an insult to those who care about this issue. My apologies! I do understand that beginners may be overwhelmed by the volume of output that GHC can produce, I can easily believe that filtering out this noise is a non-trivial exercise, and I'm very happy that people are interested in improving the situation. What I had meant to say is that I don't really have a strong opinion in either direction; there are good arguments to be made for both defaults and there is no solution which will please all parties equally. If people want flags to disable various bits of output and they can be provided easily then let's add the flags. Sorry again for the rather careless remark and thanks for your efforts, gracjan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 17:41:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 17:41:02 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.ccef2ca0423689e501e2119808cadf40@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep Blocked By: | Blocking: Related Tickets: #9858, #11011 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: goldfire => * status: closed => new * resolution: duplicate => Comment: Unfortunately it looks like the initial implementation of type-indexed `Typeable` won't actually address this issue. We'll see what the future holds in store. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 18:31:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 18:31:03 -0000 Subject: [GHC] #12840: GHC-internal triplets passed to sub-project configure scripts In-Reply-To: <045.2e2c224d7fdf415c0b1a95252433ab8a@haskell.org> References: <045.2e2c224d7fdf415c0b1a95252433ab8a@haskell.org> Message-ID: <060.2beb8d78d57d08b1e0d3a9a17c5d3694@haskell.org> #12840: GHC-internal triplets passed to sub-project configure scripts -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: [[Image()]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 18:41:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 18:41:42 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.097935dd3dd1ac63532452e062ebb1b0@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2657 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: mpickering, is it safe to call this resolved despite the discussion in comment:13 and comment:12? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 18:43:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 18:43:17 -0000 Subject: [GHC] #12754: Adding an explicit export list halves compilation time. In-Reply-To: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> References: <049.4fba33939f9e1b3e97c4df81f802bc97@haskell.org> Message-ID: <064.b28f6dde33f08e36d94600b396452494@haskell.org> #12754: Adding an explicit export list halves compilation time. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2657 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 19:46:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 19:46:07 -0000 Subject: [GHC] #12852: threadWaitReadSTM does not provide a way to unregister action. Message-ID: <045.2f266f155c2facba66adab2831aa3543@haskell.org> #12852: threadWaitReadSTM does not provide a way to unregister action. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In non-threaded RTS or on windows RTS does not return meaningful unregister action: {{{#!hs threadWaitWriteSTM :: Fd -> IO (Sync.STM (), IO ()) threadWaitWriteSTM fd #ifndef mingw32_HOST_OS | threaded = Event.threadWaitWriteSTM fd #endif | otherwise = do m <- Sync.newTVarIO False _ <- Sync.forkIO $ do threadWaitWrite fd Sync.atomically $ Sync.writeTVar m True let waitAction = do b <- Sync.readTVar m if b then return () else retry let killAction = return () return (waitAction, killAction) }}} As a result in case if data will never arrive, helper thread will never be deallocated. This may lead to a memory leaks in some cases, see https://github.com/lpeterse/haskell-socket/issues/27 for details. Minimal testcase is: {{{#!hs import GHC.Conc import GHC.IO import GHC.IO.FD as FD import System.Posix.IO import System.Posix.Types main = do (rfd,wfd) <- createPipe (waitread, unregister) <- threadWaitReadSTM rfd unregister result0 <- atomically $ (fmap (const False) waitread) `orElse` return True print result0 fdWrite wfd "test" threadDelay 20000 result1 <- atomically $ (fmap (const False) waitread) `orElse` return True print result1 (waitread1, _) <- threadWaitReadSTM rfd threadDelay 20000 result2 <- atomically $ (fmap (const True) waitread1) `orElse` return False print result2 }}} Expected output will be True, True, True, but non-threaded runtime gives True, False, True -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 19:57:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 19:57:56 -0000 Subject: [GHC] #12852: threadWaitReadSTM does not provide a way to unregister action. In-Reply-To: <045.2f266f155c2facba66adab2831aa3543@haskell.org> References: <045.2f266f155c2facba66adab2831aa3543@haskell.org> Message-ID: <060.cf41feb4457c5fbe67248174e4661642@haskell.org> #12852: threadWaitReadSTM does not provide a way to unregister action. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2729 Wiki Page: | -------------------------------------+------------------------------------- Changes (by qnikst): * differential: => D2729 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 19:59:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 19:59:45 -0000 Subject: [GHC] #12852: threadWaitReadSTM does not provide a way to unregister action. In-Reply-To: <045.2f266f155c2facba66adab2831aa3543@haskell.org> References: <045.2f266f155c2facba66adab2831aa3543@haskell.org> Message-ID: <060.80d151e4274bbb8be3b26d0ec04bcb92@haskell.org> #12852: threadWaitReadSTM does not provide a way to unregister action. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2729 Wiki Page: | -------------------------------------+------------------------------------- Changes (by qnikst): * differential: D2729 => Phab:D2729 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 20:59:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 20:59:40 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.278689ddc8ad9c6db2a164df9f122566@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It turns out that the lack of `typeRepKind` has one more unfortunate effect: `Data.Dynamic.dynApply` can no longer be safely implemented. The reason is that we have no means of verifying that the result type of the function being applied is of kind `Type`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 22:11:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 22:11:02 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.f2c708264d1cbcc0a338515d560c4059@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2728 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): Well, my skin is thick enough for internet discussions. I'd rather note as fact that cycles are burnt by this in multiple places like emacs/vim/atom/vscode and hie/ghc-mod/intero, those could be burnt in one place. Second I think this is a very important issue to talk about and I see pretty big benefit-per-char-of-discussion. Note that there were compilers that boasting by readability of their output (clang), quickly followed by their direct competition (gcc) and now high level of attention to compiler output is an industry standard (see Elm or Rust). I'd like to thank hsyl20 for actually doing something about usability of compiler output. Third, I think ghc is just breaking expectations here. Just try to load Ruby, Python or C with the following code and see how much you expect: {{{ require A require B require C }}} {{{ from A import * from B import * from C import * }}} {{{ #include #include #include }}} There will be no output from these, unless you request extra verbosity to trace this functionality. GHC is an outlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 18 22:47:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 18 Nov 2016 22:47:48 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.2e8d28f2c8a312d534f3d59740dde752@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2728 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I'd rather note as fact that cycles are burnt by this in multiple places like emacs/vim/atom/vscode and hie/ghc-mod/intero, those could be burnt in one place. This is a fair point. > Third, I think ghc is just breaking expectations here. Just try to load Ruby, Python or C with the following code and see how much you expect: > > ... I'm not entirely sure this is an apples-to-apples comparison though. Python and Ruby are both interpreted languages with no real compile-/run- time phase distinction and certainly no "batch" compilation. In the case of C++ you rarely invoke the compiler itself; instead you typically invoke it via some build system, most of which do provide per- module feedback on progress. The same holds for most Scala and Java build systems, as far as I know. Of course, none of this is to say we shouldn't reconsider our output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 04:19:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 04:19:09 -0000 Subject: [GHC] #12853: Unpromoted tuples in TH in correctly accepted by tthe type checker Message-ID: <044.8ba142e5347a228d2cb8911bb3f50a47@haskell.org> #12853: Unpromoted tuples in TH in correctly accepted by tthe type checker -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This issue was discovered when writing tests for #11629. Test case: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE FlexibleInstances #-} module T11629 where import Control.Monad import Language.Haskell.TH class C (a :: Bool) class D (a :: (Bool, Bool)) class E (a :: [Bool]) instance C True instance C 'False instance D '(True, False) instance D '(False, True) instance E '[True, False] instance E '[False, True] do let getType (InstanceD _ _ ty _) = ty getType _ = error "getType: only defined for InstanceD" failMsg a ty1 ty2 = fail $ "example " ++ a ++ ": ty1 /= ty2, where\n ty1 = " ++ show ty1 ++ "\n ty2 = " ++ show ty2 withoutSig (ForallT tvs cxt ty) = ForallT tvs cxt (withoutSig ty) withoutSig (AppT ty1 ty2) = AppT (withoutSig ty1) (withoutSig ty2) withoutSig (SigT ty ki) = withoutSig ty withoutSig ty = ty -- test #2: type quotations and reified types should agree wrt -- promoted tuples. ty1 <- [t| D '(True, False) |] ty2 <- [t| D (False, True) |] ClassI _ insts <- reify ''D let [ty1', ty2'] = map (withoutSig . getType) insts when (ty1 /= ty1') $ failMsg "C" ty1 ty1' when (ty2 /= ty2') $ failMsg "D" ty2 ty2' return [] }}} According to @RyanlGlScott in https://phabricator.haskell.org/D2188#79228 the code `D (True, False)` in regular Haskell code would be rejected as a Kind error, whereas when its in Oxford brackets like `[t| D (True, False) |]`, it manages to sneak through the type checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 04:22:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 04:22:12 -0000 Subject: [GHC] #12853: Unpromoted tuples in TH in correctly accepted by tthe type checker In-Reply-To: <044.8ba142e5347a228d2cb8911bb3f50a47@haskell.org> References: <044.8ba142e5347a228d2cb8911bb3f50a47@haskell.org> Message-ID: <059.7c7b85c1d395daa1fce65ed482de4426@haskell.org> #12853: Unpromoted tuples in TH in correctly accepted by tthe type checker -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by erikd: @@ -14,1 +14,0 @@ - class C (a :: Bool) @@ -16,4 +15,0 @@ - class E (a :: [Bool]) - - instance C True - instance C 'False @@ -23,3 +18,0 @@ - - instance E '[True, False] - instance E '[False, True] New description: This issue was discovered when writing tests for #11629. Test case: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE FlexibleInstances #-} module T11629 where import Control.Monad import Language.Haskell.TH class D (a :: (Bool, Bool)) instance D '(True, False) instance D '(False, True) do let getType (InstanceD _ _ ty _) = ty getType _ = error "getType: only defined for InstanceD" failMsg a ty1 ty2 = fail $ "example " ++ a ++ ": ty1 /= ty2, where\n ty1 = " ++ show ty1 ++ "\n ty2 = " ++ show ty2 withoutSig (ForallT tvs cxt ty) = ForallT tvs cxt (withoutSig ty) withoutSig (AppT ty1 ty2) = AppT (withoutSig ty1) (withoutSig ty2) withoutSig (SigT ty ki) = withoutSig ty withoutSig ty = ty -- test #2: type quotations and reified types should agree wrt -- promoted tuples. ty1 <- [t| D '(True, False) |] ty2 <- [t| D (False, True) |] ClassI _ insts <- reify ''D let [ty1', ty2'] = map (withoutSig . getType) insts when (ty1 /= ty1') $ failMsg "C" ty1 ty1' when (ty2 /= ty2') $ failMsg "D" ty2 ty2' return [] }}} According to @RyanlGlScott in https://phabricator.haskell.org/D2188#79228 the code `D (True, False)` in regular Haskell code would be rejected as a Kind error, whereas when its in Oxford brackets like `[t| D (True, False) |]`, it manages to sneak through the type checker. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 09:33:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 09:33:09 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.0c41fdb7f65894ee36c2be141b4bda95@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 09:36:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 09:36:26 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.a7a8223fc37cf9340142442c4b5c80d4@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * type: task => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 09:40:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 09:40:20 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.343ef9966707414d5078bcc7cd2ea909@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by MikolajKonarski: @@ -46,0 +46,4 @@ + + My guess is the inlining forced with INLINE is just broken in GHC 8.0.1 + --- it omits some optimizations that ghc would normally do on manually + inlined code, such as floating out common subexpressions. New description: Mikolaj reported that he was seeing significantly different code generated in the case of an `INLINE` pragma versus manually inlining. I haven't looked into what the cause it and this isn't necessarily problematic; this is just a reminder to look into what is happening. See https://github.com/LambdaHack/LambdaHack/blob/97724fe8c73e80b329ddf326a8eb001020870b2d/Game/LambdaHack/Common/Color.hs#L99. Edit, by Mikolaj: here is a minimal example: {{{ -- ghc --make Main.hs -O1; ./Main +RTS -s -RTS seqFrame2 :: [Int] -> IO () {-# NOINLINE seqFrame2 #-} seqFrame2 l = do let crux = attrFromInt -- Total time 2.052s ( 2.072s elapsed) -- but the following version is many times slower: -- let crux = attrFromIntINLINE -- Total time 7.896s ( 7.929s elapsed) mapM_ (\a -> crux a `seq` return ()) l main :: IO () main = seqFrame2 $ replicate 100000000 0 data Attr = Attr !Int --- the bang is essential attrFromInt :: Int -> Attr {-# NOINLINE attrFromInt #-} attrFromInt w = Attr (w + (2 ^ (8 :: Int))) fgFromInt :: Int -> Int {-# INLINE fgFromInt #-} -- removing this INLINE makes it many times faster -- just like the manually inlined version -- and NOINLINE lands in between fgFromInt w = w + (2 ^ (8 :: Int)) attrFromIntINLINE :: Int -> Attr {-# NOINLINE attrFromIntINLINE #-} attrFromIntINLINE w = Attr (fgFromInt w) }}} My guess is the inlining forced with INLINE is just broken in GHC 8.0.1 --- it omits some optimizations that ghc would normally do on manually inlined code, such as floating out common subexpressions. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 09:53:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 09:53:39 -0000 Subject: [GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE In-Reply-To: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> References: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> Message-ID: <069.d23d4200493479cdf704d4092eb1b12a@haskell.org> #12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12603 | Differential Rev(s): #5775 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: #12747 #12603 => #12747 #12603 #5775 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 10:25:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 10:25:40 -0000 Subject: [GHC] #11532: ghc: panic! occured In-Reply-To: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> References: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> Message-ID: <060.b974602937089bc41c06ad5922168e25@haskell.org> #11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * status: infoneeded => closed * resolution: => invalid Comment: cutsea: thank you for the follow up! Given that nobody else managed to reproduce this, I'm closing the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 10:42:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 10:42:07 -0000 Subject: [GHC] #12079: segmentation fault in both ghci and compiled program involves gtk library In-Reply-To: <045.95402382996132bdb463dfe148e7d190@haskell.org> References: <045.95402382996132bdb463dfe148e7d190@haskell.org> Message-ID: <060.1a201d3ac17a5dea2bd9e8ed6fccc12c@haskell.org> #12079: segmentation fault in both ghci and compiled program involves gtk library ----------------------------------+-------------------------------------- Reporter: doofin | Owner: doofin Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by MikolajKonarski): I've just had a quick look, but shouldn't notify be called with postGUIAsync? Anyway, you may have better luck asking on gkt2hs mailing lists or other gtk2hs fora. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 11:01:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 11:01:01 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.3b39796adc85b4e69644b9c92648fabf@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: => #12776 #12789 #12675 Comment: Travis suggests that this happens with normal `cabal install` as well: https://travis-ci.org/LambdaHack/LambdaHack/jobs/176287181 Also, the travis results show this happens with `-O0`, `-O` and `-O2` and with any recent GHC version, inlcuding as old as 7.8.3. Due to the extra info, I'm not closing as a duplicate of #12776, #12789 and #12675. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 11:04:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 11:04:46 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.fad518a2ca1f434de42a65cf2c1454ec@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12843 #12675 | Differential Rev(s): #12789 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: => #12843 #12675 #12789 Comment: FYI: #12843 shows an example (a huge one, unfortunately), which crashes similarly with any optimization level and with older GHCs as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 11:05:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 11:05:28 -0000 Subject: [GHC] #12675: Simplifier ticks exhausted In-Reply-To: <045.9809884861ed5ba46ea5c77c85a40d6c@haskell.org> References: <045.9809884861ed5ba46ea5c77c85a40d6c@haskell.org> Message-ID: <060.7c000d65de42c827719986920ac1a3f5@haskell.org> #12675: Simplifier ticks exhausted ---------------------------------+-------------------------------------- Reporter: davean | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by MikolajKonarski): See also https://ghc.haskell.org/trac/ghc/ticket/12776. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 11:05:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 11:05:35 -0000 Subject: [GHC] #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. In-Reply-To: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> References: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> Message-ID: <063.662419b6e0fca945eb9b5c2e54acfbb2@haskell.org> #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. ---------------------------------+---------------------------------------- Reporter: rdwebster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by MikolajKonarski): See also https://ghc.haskell.org/trac/ghc/ticket/12776. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 14:05:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 14:05:08 -0000 Subject: [GHC] #12853: Unpromoted tuples in TH in correctly accepted by the type checker (was: Unpromoted tuples in TH in correctly accepted by tthe type checker) In-Reply-To: <044.8ba142e5347a228d2cb8911bb3f50a47@haskell.org> References: <044.8ba142e5347a228d2cb8911bb3f50a47@haskell.org> Message-ID: <059.9f266d8f7aa1594b533ab4024ad27bca@haskell.org> #12853: Unpromoted tuples in TH in correctly accepted by the type checker -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TemplateHaskell * cc: RyanGlScott, goldfire (added) Comment: I think there are two unrelated issues at play here. One is the issue that there's an inconsistency between tuples and other type constructors w.r.t. automatic promotion. Namely, most types get automatically promoted to a kind in certain contexts, whereas tuples do not. This is why `ty2`'s TH AST doesn't match that of `ty2'`. The other issue is that this program even typechecks at all. In light of the fact that tuples don't automatically get promoted to kinds, something like `[t| D (Bool, Bool) |]` feels bogus. But you can make it even more bogus if you wanted to: {{{#!hs ty2 <- [t| D (Char, Maybe) |] }}} For better or worse, TH doesn't appear to kind-check its quoted types until they're spliced. Is this desirable? On hand, this allows you to pass around values in `Q` computations that don't necessarily type-check, which can be convenient. On the other hand, not sanity checking TH quotations leads to bizarre results like in the program above. I'm a bit reticent to say we should change the behavior with regards to the second issue, since I feel like it could be a very disruptive breaking change. I've cc'd goldfire to get his opinion on the matter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 14:10:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 14:10:47 -0000 Subject: [GHC] #12853: Unpromoted tuples in TH in correctly accepted by the type checker In-Reply-To: <044.8ba142e5347a228d2cb8911bb3f50a47@haskell.org> References: <044.8ba142e5347a228d2cb8911bb3f50a47@haskell.org> Message-ID: <059.5191186d80493176c5391d30cd374e45@haskell.org> #12853: Unpromoted tuples in TH in correctly accepted by the type checker -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): > For better or worse, TH doesn't appear to kind-check its quoted types until they're spliced. It's consistent with TH not type checking quoted expressions. And in general the quotation could contain a splice, in which it can't be checked. So, there seems to be no issue here, actually? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 14:14:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 14:14:40 -0000 Subject: [GHC] #12853: Unpromoted tuples in TH in correctly accepted by the type checker In-Reply-To: <044.8ba142e5347a228d2cb8911bb3f50a47@haskell.org> References: <044.8ba142e5347a228d2cb8911bb3f50a47@haskell.org> Message-ID: <059.e302b71bdd008e1438980122e3e3bd37@haskell.org> #12853: Unpromoted tuples in TH in correctly accepted by the type checker -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: invalid | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Replying to [comment:3 rwbarton]: > It's consistent with TH not type checking quoted expressions. And in general the quotation could contain a splice, in which it can't be checked. > > So, there seems to be no issue here, actually? Upon further thought, I think you're right. I'll close this as invalid, then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 15:51:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 15:51:40 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2312854=3A_ghc-8_prints_mangled_names_in_er?= =?utf-8?b?cm9yIG1lc3NhZ2U6IOKAmEdIQy5CYXNlLiRkbTwk4oCZ?= Message-ID: <045.b2961fab558879fceba382b527980ad8@haskell.org> #12854: ghc-8 prints mangled names in error message: ‘GHC.Base.$dm<$’ -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Noticed on old omega codebase when built with ghc-8.0.2-rc1. Here is the minimal example: {{{#!hs {-# LANGUAGE FlexibleInstances, KindSignatures #-} {-# OPTIONS_GHC -Wall #-} data F a b instance Functor (F a) where fmap = undefined instance Functor (F String) where fmap = undefined }}} {{{ $ ghci a.hs GHCi, version 8.0.1.20161117: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/slyfox/.ghci [1 of 1] Compiling Main ( a.hs, interpreted ) a.hs:6:10: error: • Overlapping instances for Functor (F String) arising from a use of ‘GHC.Base.$dm<$’ Matching instances: instance Functor (F a) -- Defined at a.hs:5:10 instance Functor (F String) -- Defined at a.hs:6:10 • In the expression: GHC.Base.$dm<$ @F String In an equation for ‘<$’: (<$) = GHC.Base.$dm<$ @F String In the instance declaration for ‘Functor (F String)’ Failed, modules loaded: none. }}} ‘GHC.Base.$dm<$’ is an internal name. Looks like it should be a 'GHC.Base.<$'. Confusingly this does not cause overlapping error at all: {{{#!hs {-# LANGUAGE FlexibleInstances, KindSignatures #-} {-# OPTIONS_GHC -Wall #-} data F a b class C (f :: * -> *) where instance C (F a) where instance C (F String) where }}} {{{ $ ghci a.hs GHCi, version 8.0.1.20161117: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/slyfox/.ghci [1 of 1] Compiling Main ( a.hs, interpreted ) Ok, modules loaded: Main. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 20:54:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 20:54:41 -0000 Subject: [GHC] #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 Message-ID: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC version 8.0.1.20161117 {{{#!hs -- $ cat BodySpec.hs -- $ ghc --make -O1 -package={base,bytestring} BodySpec.hs -o a && ./a {- # OPTIONS_GHC -Wall -Werror #-} module Main (main) where import qualified Data.ByteString as S import qualified Data.ByteString.Char8 as S8 main :: IO () main = (S8.concat (map S.singleton (S.unpack (S8.pack ""))) == S8.empty) `seq` return () }}} {{{ $ ghc --make -O1 -package={base,bytestring} BodySpec.hs -o a && ./a Segmentation fault (core dumped) }}} The cause is similar to #12757: low-level optimisations inline string literal (or it's wrapping value? i don't know) in multiple places. That breaks pinter-chasing in bytestring package. {{{ $ strings a | fgrep '' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 20:55:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 20:55:55 -0000 Subject: [GHC] #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 In-Reply-To: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> References: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> Message-ID: <060.673e18db76ba8b7a466944e1e9d44048@haskell.org> #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by slyfox: @@ -24,1 +24,1 @@ - breaks pinter-chasing in bytestring package. + breaks pointer-chasing in bytestring package. New description: GHC version 8.0.1.20161117 {{{#!hs -- $ cat BodySpec.hs -- $ ghc --make -O1 -package={base,bytestring} BodySpec.hs -o a && ./a {- # OPTIONS_GHC -Wall -Werror #-} module Main (main) where import qualified Data.ByteString as S import qualified Data.ByteString.Char8 as S8 main :: IO () main = (S8.concat (map S.singleton (S.unpack (S8.pack ""))) == S8.empty) `seq` return () }}} {{{ $ ghc --make -O1 -package={base,bytestring} BodySpec.hs -o a && ./a Segmentation fault (core dumped) }}} The cause is similar to #12757: low-level optimisations inline string literal (or it's wrapping value? i don't know) in multiple places. That breaks pointer-chasing in bytestring package. {{{ $ strings a | fgrep '' }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 23:21:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 23:21:51 -0000 Subject: [GHC] #12856: Code comments mention wrong Module for definition of EquationInfo Message-ID: <047.22280234d690197be4458727072baab2@haskell.org> #12856: Code comments mention wrong Module for definition of EquationInfo -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: Documentation | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In compiler/deSugar/Match.hs the description mentions {{{ There is a type synonym, @EquationInfo@, defined in module @DsUtils at . }}} However EquationInfo is defined as data type in compiler/deSugar/DsMonad.hs:96 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 23:22:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 23:22:51 -0000 Subject: [GHC] #12856: Code comments mention wrong Module for definition of EquationInfo In-Reply-To: <047.22280234d690197be4458727072baab2@haskell.org> References: <047.22280234d690197be4458727072baab2@haskell.org> Message-ID: <062.67989a5b84bf78ff1678511e12a38e3b@haskell.org> #12856: Code comments mention wrong Module for definition of EquationInfo --------------------------------------+----------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: Documentation bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+----------------------------- Changes (by AndreasK): * Attachment "0001-Updated-code-comment-regarding-EquationInfo.patch" added. Patch changing the information in the comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 19 23:35:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 19 Nov 2016 23:35:46 -0000 Subject: [GHC] #12856: Code comments mention wrong Module for definition of EquationInfo In-Reply-To: <047.22280234d690197be4458727072baab2@haskell.org> References: <047.22280234d690197be4458727072baab2@haskell.org> Message-ID: <062.22c89e5d5c2a7b564f6ad2203626d574@haskell.org> #12856: Code comments mention wrong Module for definition of EquationInfo --------------------------------------+-------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: Documentation bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+-------------------------------- Changes (by AndreasK): * owner: => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 00:04:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 00:04:30 -0000 Subject: [GHC] #12856: Code comments mention wrong Module for definition of EquationInfo In-Reply-To: <047.22280234d690197be4458727072baab2@haskell.org> References: <047.22280234d690197be4458727072baab2@haskell.org> Message-ID: <062.e7ef66d8303f7855ae7bcc253f36fa46@haskell.org> #12856: Code comments mention wrong Module for definition of EquationInfo --------------------------------------+-------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: Documentation bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+-------------------------------- Comment (by Matthew Pickering ): In [changeset:"6ad94d8fbc45fcb725506e9b8bc53a55c089d727/ghc" 6ad94d8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6ad94d8fbc45fcb725506e9b8bc53a55c089d727" Updated code comment regarding EquationInfo. Trac #12856 Summary: Updated code comment regarding EquationInfo. Fixes T12856 Reviewers: austin, bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2730 GHC Trac Issues: #12856 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 00:05:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 00:05:21 -0000 Subject: [GHC] #12856: Code comments mention wrong Module for definition of EquationInfo In-Reply-To: <047.22280234d690197be4458727072baab2@haskell.org> References: <047.22280234d690197be4458727072baab2@haskell.org> Message-ID: <062.2d30dbbae6fccdfd49f4cdfc37726c3a@haskell.org> #12856: Code comments mention wrong Module for definition of EquationInfo --------------------------------------+-------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: closed Priority: lowest | Milestone: Component: Documentation | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: Documentation bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------+-------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 02:08:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 02:08:14 -0000 Subject: [GHC] #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 In-Reply-To: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> References: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> Message-ID: <060.9c689f2a3a009bb4306efb9dde434b95@haskell.org> #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12757 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #12757 Comment: This is another case of #12757. Unfortunately, it seems that the fix for #11158 wasn't present in the 8.0.2-rc1 release due to a silly mistake on my part. I've confirmed that merging the patch for #11158 to `ghc-8.0` resolves this crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 02:10:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 02:10:16 -0000 Subject: [GHC] #12757: Compiled program segfaults at -O1 In-Reply-To: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> References: <042.207045105eccab6bd150ba6e3c9e1d32@haskell.org> Message-ID: <057.96b6b711b543fed7bf8bbce8210f7190@haskell.org> #12757: Compiled program segfaults at -O1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11312, #12585, | Differential Rev(s): #12855 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #11312, #12585 => #11312, #12585, #12855 Comment: Sadly I made a silly mistake in the 8.0.2-rc1 source release; it turns out that the commit fixing #11158 didn't quite make it into the release. Consequently slyfox reported another similar issue, #12855, which is also fixed by merging the #11158 fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 02:14:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 02:14:12 -0000 Subject: [GHC] #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 In-Reply-To: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> References: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> Message-ID: <060.34bd10133cac6cd45a8ccd1bbf6aaa39@haskell.org> #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12757 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for the reduced testcase, slyfox! This will be a great addition to the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 09:51:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 09:51:29 -0000 Subject: [GHC] #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 In-Reply-To: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> References: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> Message-ID: <060.be06e6954abeb4881b0466e6407fa27a@haskell.org> #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12757 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): I'm a bit lost here. Can you clarify which commit in ghc-8.0 branch should fix it? I will apply it locally to -rc1 and try to rebuild ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 11:11:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 11:11:09 -0000 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> References: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> Message-ID: <064.de2a4506e51fdb00c1b3474867542106@haskell.org> #2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): I am intersted in implementing this. Does anyone have any thoughts about how? Perhaps someone has already started on this a bit? My tentative plan of attack is 1. Modify ghc to include the docs in interface files (Modify IfaceSyn.IfaceDecl to optionally include docs) 2. Add a :doc command to ghci Once that is done the next step would be to modify Haddock to take advantage of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 11:24:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 11:24:33 -0000 Subject: [GHC] #12857: associate pattern synonyms with a type synonym Message-ID: <044.977a800271703c596610344012947691@haskell.org> #12857: associate pattern synonyms with a type synonym -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I believe it would be useful to bundle pattern synonyms with type synonyms, which is currently not supported. For example, the `State` type synonym from monad transformers could profit from such bundling, as it would allow users to use `State (..)` in an import list: {{{#!hs {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} module State ( State (State, runState) ) where import Control.Monad newtype Identity a = Identity { runIdentity :: a } newtype StateT s m a = StateT { runStateT :: s -> m (s, a) } type State s a = StateT s Identity a pattern State { runState } <- ((runIdentity .) . runStateT -> runState) where State runState = StateT (Identity . runState) }}} (I would have a use for this in `haskell-src-exts-simple` package, which, similar to the above example, uses type synonyms to instantiate a type parameter a few datatypes to a fixed type.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 11:31:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 11:31:09 -0000 Subject: [GHC] #12857: associate pattern synonyms with a type synonym In-Reply-To: <044.977a800271703c596610344012947691@haskell.org> References: <044.977a800271703c596610344012947691@haskell.org> Message-ID: <059.e35f2bd68fea0f0c9228d5811ad2cbf2@haskell.org> #12857: associate pattern synonyms with a type synonym -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think this is a good idea. Also see #11461 for the class variant of this idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 16:15:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 16:15:39 -0000 Subject: [GHC] #12858: clock_gettime support on OS X is a nightmare Message-ID: <046.19e86429122bc1a6fb62b88319c07c56@haskell.org> #12858: clock_gettime support on OS X is a nightmare ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Darwin did not support `clock_gettime` until Sierra, which added it. Unfortunately, the existing `MACOSX_DEPLOYMENT_TARGET` environment variable has no effect on its availability, so binary distributions compiled on Sierra will be incompatible with older releases. We have three options for dealing with this, 1. Disable `clock_gettime` support in our OS X binary distributions (e.g. `./configure ac_cv_func_clock_gettime=no`) 2. Produce one binary distribution for Sierra and another for previous releases 3. Making it possible to change timer backends at runtime. At the moment I'm leaning towards (1). (2) is another possibility. (3) seems like a road to madness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 17:22:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 17:22:25 -0000 Subject: [GHC] #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 In-Reply-To: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> References: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> Message-ID: <060.ce8f7a7f77db0e1df14148797a26c585@haskell.org> #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12757 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): slyfox, see 58d9f9b7a7f1b4d2c94183b9b9428983e7c83fe9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 17:22:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 17:22:40 -0000 Subject: [GHC] #12858: clock_gettime support on OS X is a nightmare In-Reply-To: <046.19e86429122bc1a6fb62b88319c07c56@haskell.org> References: <046.19e86429122bc1a6fb62b88319c07c56@haskell.org> Message-ID: <061.fde039dc1c89c2ec14dbf4964fc68749@haskell.org> #12858: clock_gettime support on OS X is a nightmare ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I'll be going with option (1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 17:37:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 17:37:10 -0000 Subject: [GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ... In-Reply-To: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> References: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> Message-ID: <066.96680e5c417f6ec22f3584013f43f76e@haskell.org> #12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12001 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -5,0 +5,9 @@ + import qualified Control.Monad.Cont as C + import Control.Monad.Cont hiding (runCont) + import qualified Control.Monad.Writer as W + import Control.Monad.Writer hiding (runWriter) + import qualified Control.Monad.Reader as R + import Control.Monad.Reader hiding (runReader) + import qualified Control.Monad.State as S + import Control.Monad.State hiding (runState) + @@ -6,2 +15,2 @@ - pattern Cont a <- (runCont -> a) - where Cont a = cont a + pattern Cont {runCont} <- (C.runCont -> runCont) + where Cont a = cont a @@ -10,2 +19,2 @@ - pattern Writer a <- (runWriter -> a) - where Writer a = WriterT (Identity a) + pattern Writer {runWriter} <- (W.runWriter -> runWriter) + where Writer a = WriterT (Identity a) @@ -14,2 +23,2 @@ - pattern Reader a <- (runReader -> a) - where Reader a = reader a + pattern Reader {runReader} <- (R.runReader -> runReader) + where Reader a = reader a @@ -18,2 +27,2 @@ - pattern State a <- (runState -> a) - where State a = state a + pattern State {runState} <- (S.runState -> runState) + where State a = state a New description: Made this its own ticket, rather than using #12001. Are these worth adding? {{{#!hs import qualified Control.Monad.Cont as C import Control.Monad.Cont hiding (runCont) import qualified Control.Monad.Writer as W import Control.Monad.Writer hiding (runWriter) import qualified Control.Monad.Reader as R import Control.Monad.Reader hiding (runReader) import qualified Control.Monad.State as S import Control.Monad.State hiding (runState) pattern Cont :: ((a -> r) -> r) -> Cont r a pattern Cont {runCont} <- (C.runCont -> runCont) where Cont a = cont a pattern Writer :: (a, w) -> Writer w a pattern Writer {runWriter} <- (W.runWriter -> runWriter) where Writer a = WriterT (Identity a) pattern Reader :: (r -> a) -> Reader r a pattern Reader {runReader} <- (R.runReader -> runReader) where Reader a = reader a pattern State :: (s -> (a, s)) -> State s a pattern State {runState} <- (S.runState -> runState) where State a = state a }}} The mtl API was changed way back when (before advent of pattern synonyms) which caused some [http://stackoverflow.com/questions/14157090/has-the- control-monad-state-api-changed-recently confusion], [http://learnyouahaskell.com/for-a-few-monads-more LYAH] still uses `Writer`, `State` in their examples. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 17:38:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 17:38:47 -0000 Subject: [GHC] #12857: associate pattern synonyms with a type synonym In-Reply-To: <044.977a800271703c596610344012947691@haskell.org> References: <044.977a800271703c596610344012947691@haskell.org> Message-ID: <059.0040d116a25cda5c5c5b92b61f1d0efb@haskell.org> #12857: associate pattern synonyms with a type synonym -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): See #12767 about adding {{{#!hs pattern State :: (s -> (a, s)) -> State s a pattern State {runState} <- (S.runState -> runState) where State a = state a }}} et al to transformers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 18:34:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 18:34:01 -0000 Subject: [GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ... In-Reply-To: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> References: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> Message-ID: <066.72a887cc615301367369e018db81bac7@haskell.org> #12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12001 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Started a [https://mail.haskell.org/pipermail/libraries/2016-November/027442.html discussion] on the library mailing list. See #12857 for associating pattern synonyms with a type synonym: {{{#!hs module State ( State (State, runState) ) where ... type State s = StateT s Identity pattern State { runState } <- ((runIdentity .) . runStateT -> runState) where State runState = StateT (Identity . runState) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 20:12:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 20:12:32 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.b7a18fd13ef1abde78069cfebef1380f@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -9,1 +9,1 @@ - class Num (a :: Type k) where + class Num (a :: TYPE k) where @@ -35,1 +35,1 @@ - fromInteger (fromInteger -> I# int) = int + fromInteger (fromInteger @PtrRepLifted @Int -> I# int) = int @@ -54,1 +54,1 @@ - fromInteger (fromInteger -> D# dbl) = dbl + fromInteger (fromInteger @PtrRepLifted @Double -> D# dbl) = dbl @@ -63,7 +63,7 @@ - (+) = (P.+) - (-) = (P.-) - (*) = (P.*) - negate = P.negate - abs = P.abs - signum = P.signum - fromInteger = P.fromInteger + (+) = (P.+) @a + (-) = (P.-) @a + (*) = (P.*) @a + negate = P.negate @a + abs = P.abs @a + signum = P.signum @a + fromInteger = P.fromInteger @a @@ -82,1 +82,1 @@ - show = P.show + show = P.show @a @@ -84,1 +84,1 @@ - instance Show Int# where + instance Show (Int# :: TYPE IntRep) where @@ -86,1 +86,1 @@ - show int = show (I# int) + show int = show @PtrRepLifted @Int (I# int) @@ -88,1 +88,1 @@ - instance Show Double# where + instance Show (Double# :: TYPE DoubleRep) where @@ -90,1 +90,1 @@ - show dbl = show (D# dbl) + show dbl = show @PtrRepLifted @Double (D# dbl) New description: I can create a GHC proposal for this but I need a sanity check first {{{#!hs import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: TYPE k) where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a instance Num Int# where (+) :: Int# -> Int# -> Int# (+) = (+#) (-) :: Int# -> Int# -> Int# (-) = (-#) (*) :: Int# -> Int# -> Int# (*) = (*#) negate :: Int# -> Int# negate = negateInt# ... fromInteger :: Integer -> Int# fromInteger (fromInteger @PtrRepLifted @Int -> I# int) = int instance Num Double# where (+) :: Double# -> Double# -> Double# (+) = (+##) (-) :: Double# -> Double# -> Double# (-) = (-##) (*) :: Double# -> Double# -> Double# (*) = (*##) negate :: Double# -> Double# negate = negateDouble# ... fromInteger :: Integer -> Double# fromInteger (fromInteger @PtrRepLifted @Double -> D# dbl) = dbl }}} Note how the `fromInteger` views aren't qualified? That's because we can branch on the kind and all of a sudden, all instances of old `Num` are instances of our `Num` {{{#!hs instance P.Num a => Num (a :: Type) where (+) = (P.+) @a (-) = (P.-) @a (*) = (P.*) @a negate = P.negate @a abs = P.abs @a signum = P.signum @a fromInteger = P.fromInteger @a }}} ---- Same with `Show` etc. etc. {{{#!hs class Show (a :: TYPE k) where show :: (a :: TYPE k) -> String instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show @a instance Show (Int# :: TYPE IntRep) where show :: Int# -> String show int = show @PtrRepLifted @Int (I# int) instance Show (Double# :: TYPE DoubleRep) where show :: Double# -> String show dbl = show @PtrRepLifted @Double (D# dbl) }}} {{{#!hs class Functor (f :: Type -> TYPE rep) where fmap :: (a -> b) -> (f a -> f b) instance Functor ((# , #) a) where fmap :: (b -> b') -> ((# a, b #) -> (# a, b'#)) fmap f (# a, b #) = (# a, f b #) class Applicative (f :: Type -> TYPE rep) where pure :: a -> f a (<*>) :: f (a -> b) -> (f a -> f b) instance Monoid m => Applicative ((# , #) m) where pure :: a -> (# m, a #) pure a = (# mempty, a #) (<*>) :: (# m, a -> b #) -> ((# m, a #) -> (# m, b #)) (# m1, f #) <*> (# m2, x #) = (# m1 <> m2, f x #) class Foldable (f :: Type -> TYPE rep) where fold :: Monoid m => f m -> m instance Foldable ((# , #) xx) where fold :: Monoid m => (# xx, m #) -> m fold (# _, m #) = m }}} halp where does this end ---- What effects would this have? They are even printed the same by default {{{#!hs Prelude.Num :: * -> Constraint Main.Num :: * -> Constraint -- >>> :set -fprint-explicit-runtime-reps Prelude.Num :: * -> Constraint Main.Num :: TYPE k -> Constraint -- >>> :set -fprint-explicit-foralls Prelude.Num :: * -> Constraint Main.Num :: forall (k :: RuntimeRep). TYPE k -> Constraint }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 20:26:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 20:26:23 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.c3a82d0dd38dd0e76913517eeff89517@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Using the generalized function composition from the paper {{{#!hs (·) :: forall (r :: RuntimeRep) (a :: Type) (b :: Type) (c :: TYPE r). (b -> c) -> (a -> b) -> (a -> c) (f · g) x = f (g x) }}} we can write {{{#!hs fromInteger :: Integer -> Int# fromInteger (fromInteger -> I# i) = i fromInteger :: Integer -> Int# fromInteger (fromInteger -> D# d) = d) }}} pointfree {{{#!hs fromInteger :: Integer -> Int# fromInteger = getInt# · fromInteger where getInt# :: Int -> Int# getInt# (I# i) = i fromInteger :: Integer -> Double# fromInteger = getDouble# · fromInteger where getDouble# :: Double -> Double# getDouble# (D# d) = d -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 20:38:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 20:38:56 -0000 Subject: [GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary In-Reply-To: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> References: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> Message-ID: <060.be7dbda91bc9c5d7019ad43d943e6549@haskell.org> #12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: philderbeast Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by philderbeast): * owner: => philderbeast -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 22:00:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 22:00:57 -0000 Subject: [GHC] #12857: associate pattern synonyms with a type synonym In-Reply-To: <044.977a800271703c596610344012947691@haskell.org> References: <044.977a800271703c596610344012947691@haskell.org> Message-ID: <059.7ec3b3698a55fb8446fbddfb3cf95260@haskell.org> #12857: associate pattern synonyms with a type synonym -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm generally in favor of this idea. But I think this is a perfect candidate for the [https://github.com/ghc-proposals/ghc-proposals ghc- proposals] process. Please write up a proposal there (mentioning this already-created ticket), and then we can see if this has the community support necessary behind it. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 22:49:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 22:49:47 -0000 Subject: [GHC] #12859: ghc/packages/Cabal is not a valid repository name Message-ID: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> #12859: ghc/packages/Cabal is not a valid repository name --------------------------------------+--------------------------------- Reporter: philderbeast | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- On 2016-11-05 I was able to follow the newcomer build instructions [https://ghc.haskell.org/trac/ghc/wiki/Newcomers] for and built ghc on Windows with MSYS2 x64. I am now repeating those steps and see that doing a clean recursive clone of ghc fails for the Cabal submodule and many others ... {{{ $ git clone --recursive git://github.com/ghc/ghc Cloning into '/d/Dev/Src/ghc/libraries/Cabal'... fatal: remote error: ghc/packages/Cabal is not a valid repository name }}} I tried the exact same recursive clone on OSX and it completed without error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 20 22:50:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 20 Nov 2016 22:50:48 -0000 Subject: [GHC] #12859: ghc/packages/Cabal is not a valid repository name In-Reply-To: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> References: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> Message-ID: <066.2051dd068f9fa2c5e8231fd1e2dd86c3@haskell.org> #12859: ghc/packages/Cabal is not a valid repository name ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Description changed by philderbeast: @@ -2,4 +2,3 @@ - [https://ghc.haskell.org/trac/ghc/wiki/Newcomers] for and built ghc on - Windows with MSYS2 x64. I am now repeating those steps and see that doing - a clean recursive clone of ghc fails for the Cabal submodule and many - others ... + [https://ghc.haskell.org/trac/ghc/wiki/Newcomers] and built ghc on Windows + with MSYS2 x64. I am now repeating those steps and see that doing a clean + recursive clone of ghc fails for the Cabal submodule and many others ... New description: On 2016-11-05 I was able to follow the newcomer build instructions [https://ghc.haskell.org/trac/ghc/wiki/Newcomers] and built ghc on Windows with MSYS2 x64. I am now repeating those steps and see that doing a clean recursive clone of ghc fails for the Cabal submodule and many others ... {{{ $ git clone --recursive git://github.com/ghc/ghc Cloning into '/d/Dev/Src/ghc/libraries/Cabal'... fatal: remote error: ghc/packages/Cabal is not a valid repository name }}} I tried the exact same recursive clone on OSX and it completed without error. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 04:17:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 04:17:52 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop Message-ID: <050.0467eff6823365d8109e507aa34c563f@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This worked in GHC 7.6.3, but ever since GHC 7.8, this code will cause the typechecker to loop infinitely: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where class C a b | a -> b where c :: a -> Int newtype Foo a = Foo a deriving (C b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 04:50:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 04:50:26 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.314d6c2820fe18321d991cfda8897186@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well before 8.0, it results in a context reduction stack overflow reasonably quickly. The code is extremely dubious anyways, since the derived instance would have form {{{#!hs instance C b a => C b (Foo a) where ... }}} But if you could actually satisfy the context `C b a`, then you would be disallowed from writing the instance `C b (Foo a)` by the functional dependency. So the derived instance should be useless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 05:38:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 05:38:42 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.70f2e46eb40d07b98daeb9622374e6e9@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Thank you, that is indeed very helpful. I agree that comment in `newMetaTyVars` is very likely incorrect and the source of bugs. However I believe the panic that occurs in this case is actually a different problem. First note that the actual substitutions of the kinds that results in `∀ (ba ∷ kj) (cb ∷ kk). al ba cb` happens earlier, on the line {{{ ; (wrap2, rho2) <- deeplyInstantiate orig (substTyUnchecked subst rho) }}} of `deeplyInstantiate`. Note that the substitution was already unchecked there, likely due to the problem you mention (as well as perhaps other problems). The panic in the line {{{ kind = substTy subst (tyVarKind tv) }}} that happens later seems unrelated to the substitution invariant. At this point the kinds have already been substituted, so it is trying to do the substitution `kk -> kk`, which in fact satisfies the invariant. The code line above is very suspicious to me--I'm not sure why any substitution for the kind is being attempted. Why not just `kind = tyVarKind tv`? If all kinds must be specified before the types that use them (and I assume that is checked somewhere earlier) then the kind substitution must have already been happened. The problem seems to be that `subst` here is the substitution for the type variable, but we pass in the kind variable as the second argument to `substTy` which confuses `checkValidSubst`. This can be seen from the values printed out by the assert (here with the full names). {{{ in_scope InScope {k_a12j b_a12p} tenv [a11a :-> b_a12p[tau:2]] cenv [] tys [k_a12k[tau:2]] cos [] needInScope [a12k :-> k_a12k[tau:2]] }}} The substitution being attempted is `kk -> kk` but `tenv` contains the `ba -> bp` substitution. So in the lines {{{ needInScope = (tyCoVarsOfTypes tys `unionVarSet` tyCoVarsOfCos cos) `delListFromUFM_Directly` substDomain }}} of `checkValidSubst` the `substDomain` (of `tenv`) is getting removed from `needInScope` but it is the wrong domain--it should be `kk`, not `ba`. Anyway it seems there seem to be a lot of problems with this code, and it's certainly worth going through and cleaning up, but again I'd appreciate some perspective to make sure I'm not breaking more than I fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 06:33:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 06:33:52 -0000 Subject: [GHC] #12861: "ghc-pkgh-6.9" Message-ID: <050.1e0a9f38d50e1c46cd6fa07cd3ef54bf@haskell.org> #12861: "ghc-pkgh-6.9" -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-pkg.cabal has version 6.9, which may be okay, but `ghc-pkg --version` outputs the same version as ghc which seems slightly confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 06:35:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 06:35:00 -0000 Subject: [GHC] #12861: "ghc-pkg-6.9" (was: "ghc-pkgh-6.9") In-Reply-To: <050.1e0a9f38d50e1c46cd6fa07cd3ef54bf@haskell.org> References: <050.1e0a9f38d50e1c46cd6fa07cd3ef54bf@haskell.org> Message-ID: <065.2781a7205a965cbe77d24733c53a1043@haskell.org> #12861: "ghc-pkg-6.9" -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 07:10:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 07:10:31 -0000 Subject: [GHC] #7353: Make system IO interruptible on Windows In-Reply-To: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> References: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> Message-ID: <063.ec540cf7c0042f10aee2f2a3d1e60cd8@haskell.org> #7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: refold Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by winter): * cc: drkoster@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 08:30:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 08:30:33 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.1885e572502d3a1b0fc06fd53243b3ea@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): And for this commit `--ghc-option=-fsimpl-tick-factor=1000` is not enough, but 10000 is: https://travis-ci.org/LambdaHack/LambdaHack/builds/177586400 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 11:29:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 11:29:35 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.915ec917d976906915a3b7b6a76495f9@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by simonpj): Yes, all the calls to `substTyUnchecked` indicate places where the in- scope set is not properly maintained. I think most, but not all, of the calls to `newMetaTyVarX` do have a correct in-scope set. As my comment says, the one that doesn't is the call from `tc_infer_args`, which is a bit of code that (as Richard knows) I do not fully understand. Richard: we may need your help to get the in-scope set right here. John: which call to `newMetaTyVars` do you think is at fault? They all look ok to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 11:45:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 11:45:15 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.fc901416a94846980b1c2aeff2c6d2fb@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2669 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D2669 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 11:51:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 11:51:19 -0000 Subject: [GHC] #12862: Operator (!) causes weird pretty printing and parsing Message-ID: <051.b9bd3dd84e7892e2b9d38679aae4d11c@haskell.org> #12862: Operator (!) causes weird pretty printing and parsing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs class Key key where data TotalMap key :: Type -> Type (!) :: TotalMap key val -> (key -> val) instance Key Bool where data TotalMap Bool val = BoolMap val val (!) :: TotalMap Bool val -> (Bool -> val) (BoolMap f _) ! False = f }}} puts unnecessary parentheses around the wildcard pattern: {{{ tf6t.hs:14:3-23: error: … Parse error in pattern: (BoolMap f (_)) Compilation failed. }}} and with no parentheses {{{#!hs BoolMap f _ ! False = f }}} it talks about missing method, pattern bindings and doesn't list a space between `!` and `False`: {{{ tf6t.hs:13:3-5: error: … The class method signature for ‘!’ lacks an accompanying binding (The class method signature must be given where ‘!’ is declared) tf6t.hs:14:3-25: error: … Pattern bindings (except simple variables) not allowed in instance declaration: BoolMap f _ !False = f Compilation failed. }}} All of these issues go away if the operator is called something other than `!`, it works if written prefix {{{#!hs (!) (BoolMap f _) False = f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 11:55:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 11:55:16 -0000 Subject: [GHC] #12862: Operator (!) causes weird pretty printing and parsing In-Reply-To: <051.b9bd3dd84e7892e2b9d38679aae4d11c@haskell.org> References: <051.b9bd3dd84e7892e2b9d38679aae4d11c@haskell.org> Message-ID: <066.c3dab6a4d0d773f322e97781e33ddc04@haskell.org> #12862: Operator (!) causes weird pretty printing and parsing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Ah this is because {{{#!hs NaturalMap str ! nat = str !! fromIntegral nat }}} gets parsed as {{{#!hs NaturalMap str !nat = str !! fromIntegral nat }}} If this is intended behavior maybe the error messages should reflect that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 12:14:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 12:14:45 -0000 Subject: [GHC] #12863: Associated data families don't use superclasses when deriving instances Message-ID: <051.6aa25cf014d4c5be0a8a6bf0646cf7f9@haskell.org> #12863: Associated data families don't use superclasses when deriving instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs class Functor (TotalMap key) => Key key where data TotalMap key :: Type -> Type (¡) :: TotalMap key val -> key -> val }}} a constraint `Key key` entails a `Functor (TotalMap key)` constraint, using the notation of [https://hackage.haskell.org/package/constraints constraints] {{{#!hs prf1 :: Key key :- Functor (TotalMap key) prf1 = Sub Dict prf2 :: (Key key1, Key key2) :- (Functor (TotalMap key1), Functor (TotalMap key2)) prf2 = prf1 *** prf1 }}} Yet these proofs are not used in {{{#!hs -- tzLp.hs:28:89-95: error: … -- • No instance for (Functor (TotalMap key1)) -- arising from the first field of ‘PairMap’ -- (type ‘TotalMap key1 (TotalMap key2 val)’) -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Functor (TotalMap (key1, key2))) -- Compilation failed. instance (Key key1, Key key2) => Key (key1, key2) where data TotalMap (key1, key2) val = PairMap (TotalMap key1 (TotalMap key2 val)) deriving Functor (¡) :: TotalMap (key1, key2) val -> ((key1, key2) -> val) PairMap keys ¡ (k1, k2) = keys ¡ k1 ¡ k2 }}} I would expect it to work like {{{#!hs deriving instance (Key key1, Key key2) => Functor (TotalMap (key1, key2)) }}} Same problem occurs with only a single constraint {{{#!hs -- tzLp.hs:33:14-20: error: … -- • No instance for (Functor (TotalMap key)) -- arising from the first field of ‘Id’ (type ‘TotalMap key val’) -- Possible fix: -- use a standalone 'deriving instance' declaration, -- so you can specify the instance context yourself -- • When deriving the instance for (Functor -- (TotalMap (Identity key))) -- Compilation failed. instance Key key => Key (Identity key) where data TotalMap (Identity key) val = Id (TotalMap key val) deriving Functor }}} which should work like {{{#!hs deriving instance Key key => Functor (TotalMap (Identity key)) -- or deriving instance Functor (TotalMap key) => Functor (TotalMap (Identity key)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 12:18:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 12:18:00 -0000 Subject: [GHC] #12863: Associated data families don't use superclasses when deriving instances In-Reply-To: <051.6aa25cf014d4c5be0a8a6bf0646cf7f9@haskell.org> References: <051.6aa25cf014d4c5be0a8a6bf0646cf7f9@haskell.org> Message-ID: <066.9f5853c4200980c3df3a9e1fa5c0859f@haskell.org> #12863: Associated data families don't use superclasses when deriving instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Even adding them to the context doesn't make a difference {{{#!hs instance (Key key, Functor (TotalMap key)) => Key (Identity key) instance (Key key1, Key key2, Functor (TotalMap key1), Functor (TotalMap key2)) => Key (key1, key2) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 13:35:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 13:35:57 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.dc70b7cc47c9e5813294ed5db7a131e2@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yikes that is really bad. At ''least'' we should get a context-stack overflow. But there is more, as I found when investigating: * At the moment if we have {{{ inert: [D] a ~ ty work item [D] a ~ ty }}} we rewrite the work item with the inert to get `[D] ty ~ ty` and then take a series steps to decompose it. It'd be fast to use `unifyDerived` for this case. * The reason we generate two duplicate Derived constraints is also a bit stupid. Suppose we have `[W] C T a`, where class C has some fundeps, and `a` is a skolem of some kind. From this we might generate a derived `[D] a ~ ty`. This kicks out a derived shadow `[D] C T a` from the inerts. We rewrite it to `[D] C T ty`. ''But then we interact it with the `[W] C T a` in the inert set, to make another derived `[D] a ~ ty`. What a waste of effort. But underlying all this is the question of what ''should'' happen here. The problem is: {{{ [W] C a b --> [D] b ~ Foo beta1 (by fundeps, beta1 fresh unification variable) --> [D] C a (Foo beta1) (rewrite) --> [D] C a beta1 (use instance C a b => C a (Foo b)) }}} and now the cycle repeats. With a hand-written instance decl {{{ instance C a b => C a (Foo b) }}} you rightly need `UndecidableInstances`, but it's less clear what to do when trying to guess the instance context; fail in some way I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 14:01:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 14:01:55 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.81a4244b4038eb6fb0c25aba96d71773@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): It's buried a bit in all the text I wrote above (written when I was still trying to understand the code), but it's the line {{{ = do { (subst, tvs') <- newMetaTyVars tvs }}} of `deeplyInstantiate`, particularly inside the recursive call that happens a few lines down. {{{ ; (wrap2, rho2) <- deeplyInstantiate orig (substTyUnchecked subst rho) }}} In the example I give above there are two forall groups. The first works fine and substitutions are made into the second via the `substTyUnchecked`, in particular into the kind variables of the second group. However these kind variables are not part of the the in-scope set when {{{ kind = substTyUnchecked subst (tyVarKind tv) }}} is called in `new_meta_tv_x` of the second, recursive, call of `deeplyInstantiate`, since `newMetaTyVars ` starts with a fresh empty in- scope set, thus the panic I was looking at. As I noted above, the kind variables being substituted into are "fresh" from the outer call and thus there will be no real problem, but it's probably better to pass them in to `newMetaTyVars` as Richard suggests rather than trying to special-case the checking logic, and there may well still be places where not passing in a pre-existing in-scope set does cause a real problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 14:13:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 14:13:42 -0000 Subject: [GHC] #12859: ghc/packages/Cabal is not a valid repository name In-Reply-To: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> References: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> Message-ID: <066.4a064f672cc3fe621c1d1cd769131cc1@haskell.org> #12859: ghc/packages/Cabal is not a valid repository name ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by philderbeast): The automated mirror at {{{https://github.com/ghc}}} has different paths to submodules ... {{{ https://github.com/ghc/packages-Cabal http://git.haskell.org/packages/Cabal.git }}} If I don't use the mirror as the newcomer docs say then the submodules are found ... {{{ $ git clone --recursive git://git.haskell.org/ghc Cloning into 'D:/Dev/Src/ghc/libraries/Cabal'... Submodule path 'libraries/Cabal': checked out 'a7fb9b9ae733ceb3c52fee68e6e1a6ded5fb91da' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 14:25:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 14:25:56 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.ca53214383bf5d78ea3b86ed8164818a@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): If I understand correctly, GHC sometimes rejects `deriving` clauses if the inferred context is considered too "exotic", right? Is there a nice way to teach GHC that this case should be marked as exotic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 14:58:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 14:58:54 -0000 Subject: [GHC] #11954: Associated pattern synonyms not included in haddock In-Reply-To: <046.dee795066f70760dedef2b550cf6d5e0@haskell.org> References: <046.dee795066f70760dedef2b550cf6d5e0@haskell.org> Message-ID: <061.8c5be30e89bf11004e3df835b0778fa2@haskell.org> #11954: Associated pattern synonyms not included in haddock -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.0.3 Comment: Bumping to 8.0.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 15:45:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 15:45:31 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.adc4fef8d57940110a38a09dba2fb04a@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * milestone: ⊥ => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 16:02:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 16:02:44 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags In-Reply-To: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> References: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> Message-ID: <067.a469a2cf4a9151313403bb4f79d31c4b@haskell.org> #8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: siddhanathan => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 16:25:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 16:25:40 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.0c8829d2d72eef3f3886468913c1cdb6@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): To put a finer point on the concern I raised in comment:11: Consider this example, {{{#!hs data TypeRep (a :: k) pattern Fun :: forall k k' (a :: k) (b :: k'). a -> b -> TypeRep (a -> b) -- As seen in "A reflection on types" data Dynamic where Dyn :: TypeRep a -> a -> Dynamic dynApply :: Dynamic -> Dynamic -> Maybe Dynamic dynApply (Dyn rf f) (Dyn rx x) = do Fun arg res <- pure rx Just HRefl <- eqTypeRep arg rx -- We now know that the argument types match up but what about the -- result type? -- -- In order to package up the result (f x) into a `Dyn` we must -- know that the its type is of kind *. However, we don't know -- this since TypeRep's index is poly-kinded. -- -- Consequently we really need to do this, which requires typeRepKind, Just HRefl <- eqTypeRep (typeRepKind res) (typeRep @Type) pure $ Dyn res (f x) -- Consider this example... f :: Int -> Int# f (I# n#) = n# df :: Dynamic df = Dyn f -- Here is an example of a use of Dynamic that would expose the issue in dynApply uhOh :: Maybe Dynamic uhOh = dynApply df (Dynamic (42::Int)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 16:39:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 16:39:52 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.60046e7a45f55dfc0e21ab0806be25c6@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Very good point. We can't make `Dyn res (f x)` unless `f x :: Type`, I agree. Let's see what Richard has to say. What is `Fun`? You're referring to some code I can't see. In any case, I'd remark that we don't necessarily need the full generality of `typeRepKind`; we only need to know the arguments to `(->)` when we take `rx` apart. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 16:48:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 16:48:58 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.37f0658a40fdbbbf4e426ba553baf041@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by simonpj): Right you are. Here's what to do: * Make `deeply_instantiate` take a substitution that it extends: {{{ deeply_instantiate :: CtOrigin -> TCvSubst -- new! -> TcSigmaType -> TcM (HsWrapper, TcRhoType) }}} Its semantics are: {{{ deeply_instantiate subst ty = deeplyInstantiate (substTy subst ty) }}} * Define `deeplyInstantiate` (externally called) initialise the substitution with a suitable in-scope set, like this: {{{ deeplyInstantiate ty = deeply_instantiate (mkEmptyTcSubst (tyCoVarsOfType ty)) ty }}} * The impl of `deeply_instantiate` is just as `deeplyInstantiate` today, except: * Use `newMetaTyVarsX` to extend the substitution * The unchecked-ness can go away * The recursive call is to `deeply_instantiate`, and does not substitute in `rho`. Make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 17:29:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 17:29:37 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.0ae71a3eb289502719b60cb0a99117c9@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I think that a special-purpose float pass would also be OK, and I do agree that it'd be nicer to localise the magic. I bet that almost always the ordinary float-out stuff would move `(makeStatic e)` to top level anyway (if not, it would be good to explain why not) but not having that as a guaranteed invariant would be nicer. But before going there, let's just check that what we have is not almost OK anyway: * You say that `FloatOut` would have go treat `makeStatic` specially, when not currently treat `StaticPtr` specially. Why? * I'm betting that if we had a top-level binding `x = makeStatic e` then it would never get inlined anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 18:23:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 18:23:41 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.94774704c909f145add90b1276b094ea@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by facundo.dominguez): > I'm betting that if we had a top-level binding x = makeStatic e then it would never get inlined anyway. Indeed, I would hope GHC has no incentive to inline it. > You say that FloatOut would have go treat makeStatic specially, when not currently treat StaticPtr specially. Why? The SetLevels pass checks if a soon-to-be new top-level binding is a static pointer to determine what kind of Id to produce for the new binding (bindings of StaticPtrs need to be of //exported// kind). But so far the SetLevels pass decides on its own that the static pointer needs to be floated, because, I presume, most or all data constructor applications are treated like that. If we want SetLevels to float `makeStatic e`, we probably will have to modify the decision procedure to treat `makeStatic e` unlike other function applications and always float it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 19:22:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 19:22:11 -0000 Subject: [GHC] #12024: GHC leaks GHC.Prim.~# into type In-Reply-To: <051.7eb6150e403ea080535783c5107e00b5@haskell.org> References: <051.7eb6150e403ea080535783c5107e00b5@haskell.org> Message-ID: <066.9722241cd6d060034b3fbf5a590c7525@haskell.org> #12024: GHC leaks GHC.Prim.~# into type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T12024 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"926469fcd9ba25b1c8f4b8113d6b6683259b9d6d/ghc" 926469f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="926469fcd9ba25b1c8f4b8113d6b6683259b9d6d" testsuite: Add test for #12024 Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2702 GHC Trac Issues: #12024 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 19:22:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 19:22:11 -0000 Subject: [GHC] #12447: Pretty-printing of equality `~` without parentheses In-Reply-To: <051.dba18f323b8c18d3270065a172f0294e@haskell.org> References: <051.dba18f323b8c18d3270065a172f0294e@haskell.org> Message-ID: <066.9eaaea0b4874ce94e79e9fa8370351f6@haskell.org> #12447: Pretty-printing of equality `~` without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b98dbdf667744c288f03525d5e012563d31143ce/ghc" b98dbdf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b98dbdf667744c288f03525d5e012563d31143ce" testsuite: Add (still broken) testcase for #12447 Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2703 GHC Trac Issues: #12447 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 19:22:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 19:22:11 -0000 Subject: [GHC] #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 In-Reply-To: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> References: <045.4e1a45886f6ddb19f483c755fd36fdcc@haskell.org> Message-ID: <060.c8f933e504f53fbfc738f87b0385a842@haskell.org> #12855: ghc-8.0.2_rc1 inlines string literals too aggressively, breaks tests of http-client-0.4.30 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12757 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5bce207b61f105b3797d2be00dd1df2a28cbfab6/ghc" 5bce207/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5bce207b61f105b3797d2be00dd1df2a28cbfab6" testsuite: Add test for #12855 Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2731 GHC Trac Issues: #12855 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 19:22:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 19:22:11 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.9974ae9d05d8d6168a9c755b22b75a67@haskell.org> #12550: Inconsistent unicode display for kinds ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"e7ec521ecf7dfcb42d39763e84d3447127747aed/ghc" e7ec521/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7ec521ecf7dfcb42d39763e84d3447127747aed" testsuite: Add (still failing) testcase for #12550 I thought that this would naturally resolve itself with the elimination of the Type pretty-printer but somehow all of the stars in result position of an arrow are still rendered in non-Unicode syntax. Quite odd. Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2704 GHC Trac Issues: #12550 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 19:26:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 19:26:14 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.99c678037ba7e0060ce99713ba711be3@haskell.org> #12550: Inconsistent unicode display for kinds ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Thanks a lot for adding the tests. I'm happy to do the Unicode fix unless you'd like to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 19:29:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 19:29:26 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.eff93e657b2bb648c26d2d9241131254@haskell.org> #12550: Inconsistent unicode display for kinds ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Please do! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 19:29:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 19:29:34 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.681316d6398c99c547078b42805d583d@haskell.org> #12550: Inconsistent unicode display for kinds ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 19:31:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 19:31:34 -0000 Subject: [GHC] #12024: GHC leaks GHC.Prim.~# into type In-Reply-To: <051.7eb6150e403ea080535783c5107e00b5@haskell.org> References: <051.7eb6150e403ea080535783c5107e00b5@haskell.org> Message-ID: <066.fddb6c2a34f628ef5a5c6c2361d6d452@haskell.org> #12024: GHC leaks GHC.Prim.~# into type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T12024 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 19:31:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 19:31:50 -0000 Subject: [GHC] #12697: Improve output of pattern synonym info In-Reply-To: <051.6f8b72552ef498bf9ffa8be1d2c78562@haskell.org> References: <051.6f8b72552ef498bf9ffa8be1d2c78562@haskell.org> Message-ID: <066.b0230f71c5b70d61add9d6b7408927da@haskell.org> #12697: Improve output of pattern synonym info -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12024 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #12024 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 20:51:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 20:51:48 -0000 Subject: [GHC] #12864: Produce type errors after looking at whole applications Message-ID: <046.9b7f53593c0d6ec63beeb1ea65f1893a@haskell.org> #12864: Produce type errors after looking at whole applications -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the type error messages we produce in case of function applications are rather dumb, in particular if arguments were ommited, added, swapped or not parenthized correctly. (Examples in the first comment below.) In many cases the error messages would be better if it would at one application if a function at once, and, in general, present the user with the (inferred) type of the function as well as the (expected) type due to the argument. This way, only one type error will be reported per function application, and comparing these two reported types will allow the user to spot the problem more easily. (With „one application“ I mean `e1 e2 e3 … en` where `e1` is not of that form.) Furthermore, once we have these two types in our hands, we can look for common patterns, and give even more helpful error messages, such as suggesting to swap two arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 20:53:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 20:53:33 -0000 Subject: [GHC] #12864: Produce type errors after looking at whole applications In-Reply-To: <046.9b7f53593c0d6ec63beeb1ea65f1893a@haskell.org> References: <046.9b7f53593c0d6ec63beeb1ea65f1893a@haskell.org> Message-ID: <061.b31c7e4ac2b015da306ac9ecd4854289@haskell.org> #12864: Produce type errors after looking at whole applications -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Here are a few examples with proposed alternative error messages: {{{#!hs module ErrorMessages where i1, i2, i3 :: Int i1 = 0 i2 = 0 i3 = 0 d1 :: Double d1 = 1 fid :: Int -> Double -> Int fid = undefined fii :: Int -> Int -> Int fii = undefined fidi :: Int -> Double -> Int -> Int fidi = undefined ex1 :: Int ex1 = fid i1 i2 {- ErrorMessages.hs:17:14: error: • Couldn't match expected type ‘Double’ with actual type ‘Int’ • In the second argument of ‘fid’, namely ‘i2’ In the expression: fid i1 i2 In an equation for ‘ex1’: ex1 = fid i1 i2 So far ok -} ex2 :: Int ex2 = fid d1 i1 {- ErrorMessages.hs:36:11: error: • Couldn't match expected type ‘Int’ with actual type ‘Double’ • In the first argument of ‘fid’, namely ‘d1’ In the expression: fid d1 i1 In an equation for ‘ex2’: ex2 = fid d1 i1 ErrorMessages.hs:36:14: error: • Couldn't match expected type ‘Double’ with actual type ‘Int’ • In the second argument of ‘fid’, namely ‘i1’ In the expression: fid d1 i1 In an equation for ‘ex2’: ex2 = fid d1 i1 Two error messages for one simple error! Why not ErrorMessages.hs:36:7: error: • Cannot use expression ‘fid’ of type ‘Double -> Int -> Int’ as a function of type ‘Int -> Double -> Int’ • Probable cause: The first and second argument are swapped In the expression: fid d1 i1 In an equation for ‘ex2’: ex2 = fid d1 i1 -} ex3 :: Int ex3 = fidi i1 i2 {- ErrorMessages.hs:20:7: error: • Couldn't match expected type ‘Int’ with actual type ‘Int -> Int’ • Probable cause: ‘fidi’ is applied to too few arguments In the expression: fidi i1 i2 In an equation for ‘ex3’: ex3 = fidi i1 i2 ErrorMessages.hs:20:15: error: • Couldn't match expected type ‘Double’ with actual type ‘Int’ • In the second argument of ‘fidi’, namely ‘i2’ In the expression: fidi i1 i2 In an equation for ‘ex3’: ex3 = fidi i1 i2 Bad; two errors for one. Why not: ErrorMessages.hs:20:15: error: • Missing second argument to ‘fidi’ of type ‘Double’ • In the function application: fidi i1 i2 In an equation for ‘ex3’: ex3 = fidi i1 i2 -} ex4 :: Int ex4 = fii i1 succ i2 {- ErrorMessages.hs:57:7: error: • Couldn't match expected type ‘Int -> Int’ with actual type ‘Int’ • The function ‘fii’ is applied to three arguments, but its type ‘Int -> Int -> Int’ has only two In the expression: fii i1 succ i2 In an equation for ‘ex4’: ex4 = fii i1 succ i2 ErrorMessages.hs:57:14: error: • Couldn't match expected type ‘Int’ with actual type ‘a0 -> a0’ • Probable cause: ‘succ’ is applied to too few arguments In the second argument of ‘fii’, namely ‘succ’ In the expression: fii i1 succ i2 In an equation for ‘ex4’: ex4 = fii i1 succ i2 Bad; again two errors for one. Why not: ErrorMessages.hs:20:15: error: • Cannot use expression ‘fii’ of type ‘Int -> Int -> Int’ as a function of type ‘Int -> (Int -> Int) -> Int -> Int’ • Probable cause: Missing parenthesis around ‘succ i2’ • In the function application: fii i1 succ i2 In an equation for ‘ex4’: ex4 = fii i1 succ i2 -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 21:01:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 21:01:39 -0000 Subject: [GHC] #12864: Produce type errors after looking at whole applications In-Reply-To: <046.9b7f53593c0d6ec63beeb1ea65f1893a@haskell.org> References: <046.9b7f53593c0d6ec63beeb1ea65f1893a@haskell.org> Message-ID: <061.951a628df40468b644e5162d43dbfeed@haskell.org> #12864: Produce type errors after looking at whole applications -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by nomeata: @@ -19,0 +19,4 @@ + + Clearly, there are many tricky corner cases (e.g. polymorphic functions, + types with constraints or type classes, type applications etc.). But that + should not stop us from trying better in obvious, monomorphic cases. New description: Currently, the type error messages we produce in case of function applications are rather dumb, in particular if arguments were ommited, added, swapped or not parenthized correctly. (Examples in the first comment below.) In many cases the error messages would be better if it would at one application if a function at once, and, in general, present the user with the (inferred) type of the function as well as the (expected) type due to the argument. This way, only one type error will be reported per function application, and comparing these two reported types will allow the user to spot the problem more easily. (With „one application“ I mean `e1 e2 e3 … en` where `e1` is not of that form.) Furthermore, once we have these two types in our hands, we can look for common patterns, and give even more helpful error messages, such as suggesting to swap two arguments. Clearly, there are many tricky corner cases (e.g. polymorphic functions, types with constraints or type classes, type applications etc.). But that should not stop us from trying better in obvious, monomorphic cases. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 22:22:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 22:22:35 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.cc870e7921854932604c494ececf6052@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:13 simonpj]: > Let's see what Richard has to say. I say "yes". I also say that your `Fun` is quite wrong. I prefer this one: {{{#!hs pattern Fun :: forall k (a_to_b :: k). () => forall r r' (a :: TYPE r) (b :: TYPE r'). (k ~ Type, a_to_b ~ (a -> b)) => TypeRep a -> TypeRep b -> TypeRep a_to_b }}} But otherwise I agree with your conclusions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 22:29:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 22:29:31 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.da4e76ecbe46a083a5f48cd0ea58a61c@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > I also say that your Fun is quite wrong. I prefer this one: That is true and I implement your variant in the branch; I probably should have written `Fun` as a GADT-style constructor of `TypeRep` to avoid confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 22:53:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 22:53:09 -0000 Subject: [GHC] #12825: ghc panic on ppc64el, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI In-Reply-To: <044.632ebd0cd498a6c31622b890d3f61cd2@haskell.org> References: <044.632ebd0cd498a6c31622b890d3f61cd2@haskell.org> Message-ID: <059.2d6b9cd3eb5ddf24fa9d6b765487f6ef@haskell.org> #12825: ghc panic on ppc64el, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI ---------------------------------+---------------------------------- Reporter: clint | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------- Changes (by bgamari): * status: new => infoneeded * milestone: => 8.2.1 Comment: We won't be able to do much with this without instructions to reproduce the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 22:58:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 22:58:11 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.2d5726b7e6b6f14523409dc34cd92da4@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.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 Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Agda also apparently exhibits an example of this, http://dpaste.com/2BQ0X7F.txt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 23:05:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 23:05:04 -0000 Subject: [GHC] #12825: ghc panic on ppc64le, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI (was: ghc panic on ppc64el, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI) In-Reply-To: <044.632ebd0cd498a6c31622b890d3f61cd2@haskell.org> References: <044.632ebd0cd498a6c31622b890d3f61cd2@haskell.org> Message-ID: <059.05b59b26757546c4e7bfb082fe0c068b@haskell.org> #12825: ghc panic on ppc64le, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI ---------------------------------+---------------------------------- Reporter: clint | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 23:21:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 23:21:04 -0000 Subject: [GHC] #12865: POSIX osDecommitMemory has nasty compatibility problems Message-ID: <046.4ae668e01490d7d770171a5fd8c666d2@haskell.org> #12865: POSIX osDecommitMemory has nasty compatibility problems ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- `osDecommitMemory` in `rts/posix/OSMem.c` currently does the following, {{{#!c #ifdef MADV_FREE // Try MADV_FREE first, FreeBSD has both and MADV_DONTNEED // just swaps memory out r = madvise(at, size, MADV_FREE); #else r = madvise(at, size, MADV_DONTNEED); #endif if(r < 0) sysErrorBelch("unable to decommit memory"); }}} As it turns out, the Linux kernel as of 4.5 supports `MADV_FREE`. This means that binary distributions built in such environments will use `MADV_FREE`, even if running on an older kernel that does not support this advice. Ultimately this means that any attempt to decommit will fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 23:21:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 23:21:35 -0000 Subject: [GHC] #12865: POSIX osDecommitMemory has nasty compatibility problems In-Reply-To: <046.4ae668e01490d7d770171a5fd8c666d2@haskell.org> References: <046.4ae668e01490d7d770171a5fd8c666d2@haskell.org> Message-ID: <061.2f6213feb1f3dfb9abcd4c42bbe82299@haskell.org> #12865: POSIX osDecommitMemory has nasty compatibility problems -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One approach to fixing this would be to instead do something like this, {{{#!c int r = 1; #ifdef MADV_FREE // Try MADV_FREE first, FreeBSD has both and MADV_DONTNEED // just swaps memory out r = madvise(at, size, MADV_FREE); #endif #ifdef MADV_DONTNEED if (r != 0) r = madvise(at, size, MADV_DONTNEED); #endif if(r < 0) sysErrorBelch("unable to decommit memory"); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 23:25:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 23:25:40 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.f3890adea3c409e90c76607a650c14cc@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by danharaj): Replying to [comment:20 simonpj]: > That is an admirably clear explanation, thank you. Could you please add it (suitably edited) as a `Note` in the code? > > I think I buy the idea in principle. But do we have "in the wild" example(s) of where it makes a perceptible difference? Will anyone notice/care? > > I don't think the implementation is right, I'm afraid, but I'll comment on Phab. > > Simon I've got a working draft of a patch that follows your guidance and includes my explanation as a note. I will polish it and put it on Phab once I have a convincing case that real code benefits from this change. Unfortunately, the code I'm trying to improve for the `reflex` package has an instance of this form that I would like to use in lieu of given superclasses: {{{#!hs instance t ~ SpiderTimeline Global => Reflex t where ... }}} This is a strange instance. Normally the `reflex` package is completely polymorphic in `t`. However there are performance issues with this approach if intermediate definitions are not inlined aggressively enough to end up at a call site where all the types are concrete (usually in `main = ...`). An experimental flag provides this instance in an attempt to get better code when user's write code whose constraints imply `Reflex t`. The classes that cause suboptimal code all have a similar form to this class declaration: {{{#!hs class (Monad m, Reflex t, DomSpace (DomBuilderSpace m), MonadAdjust t m) => DomBuilder t m | m -> t where ... }}} The code users of `reflex` tend to write looks like: {{{#!hs buildSomeDom :: DomBuilder t m => ... -> m () }}} I don't know if there's anything reasonable we can do for this case, even with the strange instance. Nevertheless it's useful to me to have some real world code to work with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 23:36:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 23:36:12 -0000 Subject: [GHC] #12866: GHC internal error while building darcsden Message-ID: <047.b99e56fbdb3bd24d0c5cb2ff430c4a60@haskell.org> #12866: GHC internal error while building darcsden -------------------------------------+------------------------------------- Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I get an internal error while building darcsden with GHC 8.0.1: $ darcs get hub.darcs.net:simon/darcsden-ghc8 $ cd darcsden-ghc8 $ stack --stack-yaml=stack-ghc8.yaml build ... [12 of 56] Compiling DarcsDen.Backend.Transient ( src/DarcsDen/Backend/Transient.hs, .stack- work/dist/i386-linux/Cabal-1.24.0.0/build/DarcsDen/Backend/Transient.o ) /home/simon/src/darcsden/src/DarcsDen/Backend/Transient.hs:10:33: error: • GHC internal error: ‘BackendTransientM’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [ajE2 :-> Type variable ‘bt’ = bt] • In the first argument of ‘MonadIO’, namely ‘BackendTransientM bt’ In the type ‘(BT bt, MonadIO (BackendTransientM bt))’ In the type declaration for ‘BTIO’ /home/simon/src/darcsden/src/DarcsDen/Backend/Transient.hs:44:1: error: • Non type-variable argument in the constraint: Functor (BackendTransientM bt) (Use FlexibleContexts to permit this) • In the context: (Functor (BackendTransientM bt), Monad (BackendTransientM bt)) While checking the super-classes of class ‘BackendTransient’ In the class declaration for ‘BackendTransient’ -- While building package darcsden-1.1.99 using: /home/simon/.stack/setup-exe-cache/i386-linux/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack- work/dist/i386-linux/Cabal-1.24.0.0 build lib:darcsden exe:darcsden exe :darcsden-post-hook exe:da... Process exited with code: ExitFailure 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 23:38:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 23:38:49 -0000 Subject: [GHC] #12866: GHC internal error while building darcsden In-Reply-To: <047.b99e56fbdb3bd24d0c5cb2ff430c4a60@haskell.org> References: <047.b99e56fbdb3bd24d0c5cb2ff430c4a60@haskell.org> Message-ID: <062.f7a58ea8a64f7efe8cc0a9dfdc3eda9e@haskell.org> #12866: GHC internal error while building darcsden -------------------------------------+------------------------------------- Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmic): View code at http://hub.darcs.net/simon/darcsden- ghc8/browse/src/DarcsDen/Backend/Transient.hs#10 : {{{ 9 type BT bt = (BackendTransient bt, ?backendTransient :: bt) 10 type BTIO bt = (BT bt, MonadIO (BackendTransientM bt)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 23:39:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 23:39:43 -0000 Subject: [GHC] #12866: GHC internal error while building darcsden In-Reply-To: <047.b99e56fbdb3bd24d0c5cb2ff430c4a60@haskell.org> References: <047.b99e56fbdb3bd24d0c5cb2ff430c4a60@haskell.org> Message-ID: <062.05a34b4086e84b9ba3f47f1736c6632b@haskell.org> #12866: GHC internal error while building darcsden -------------------------------------+------------------------------------- Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Compiler (Type checker) * milestone: => 8.2.1 @@ -2,1 +2,1 @@ - + {{{ @@ -34,0 +34,1 @@ + }}} New description: I get an internal error while building darcsden with GHC 8.0.1: {{{ $ darcs get hub.darcs.net:simon/darcsden-ghc8 $ cd darcsden-ghc8 $ stack --stack-yaml=stack-ghc8.yaml build ... [12 of 56] Compiling DarcsDen.Backend.Transient ( src/DarcsDen/Backend/Transient.hs, .stack- work/dist/i386-linux/Cabal-1.24.0.0/build/DarcsDen/Backend/Transient.o ) /home/simon/src/darcsden/src/DarcsDen/Backend/Transient.hs:10:33: error: • GHC internal error: ‘BackendTransientM’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [ajE2 :-> Type variable ‘bt’ = bt] • In the first argument of ‘MonadIO’, namely ‘BackendTransientM bt’ In the type ‘(BT bt, MonadIO (BackendTransientM bt))’ In the type declaration for ‘BTIO’ /home/simon/src/darcsden/src/DarcsDen/Backend/Transient.hs:44:1: error: • Non type-variable argument in the constraint: Functor (BackendTransientM bt) (Use FlexibleContexts to permit this) • In the context: (Functor (BackendTransientM bt), Monad (BackendTransientM bt)) While checking the super-classes of class ‘BackendTransient’ In the class declaration for ‘BackendTransient’ -- While building package darcsden-1.1.99 using: /home/simon/.stack/setup-exe-cache/i386-linux/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack- work/dist/i386-linux/Cabal-1.24.0.0 build lib:darcsden exe:darcsden exe :darcsden-post-hook exe:da... Process exited with code: ExitFailure 1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 21 23:50:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 21 Nov 2016 23:50:12 -0000 Subject: [GHC] #12867: Internal error while typechecking invalid program Message-ID: <046.2ab7f73f469c3c9979cc29eb99ddf47e@haskell.org> #12867: Internal error while typechecking invalid program -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to reduce #12866 I encountered this program, {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleContexts #-} module T12866 where type Test2 a = (Eq (TestM a)) class Test a where type TestM :: * }}} which gives rise to this internal GHC error during typechecking, {{{ $ ghc Hi2.hs Hi2.hs:7:21: error: • GHC internal error: ‘TestM’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [ap0 :-> Type variable ‘a’ = a] • In the first argument of ‘Eq’, namely ‘TestM a’ In the type ‘Eq (TestM a)’ In the type declaration for ‘Test2’ Hi2.hs:9:1: error: • The associated type ‘TestM’ mentions none of the type or kind variables of the class ‘Test a’ • In the class declaration for ‘Test’ }}} Clearly the program is bogus, but the first error message is quite suspicious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 00:17:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 00:17:39 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.24ab00d53a5683598ede505e1f592e94@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Dan, you should open a new ticket to talk about this change as it is unrelated. I think it is still unclear what is going on in the case of reflex but let's not side track this ticket. It isn't clear that instances such as the strange one in your ticket help at all. If at the call site, a specific `t` is known then the class methods of `Reflex` should be suitably specialised, if not then we should understand why it is not happening without resorting to hacks! I think there are plenty of real world examples of this, that isn't a worry. A simple one is {{{ foo :: MonadWriter String m => m () foo = ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 02:29:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 02:29:58 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.cfadb9d5d2fad576aec7badb42d282f3@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:20 RyanGlScott]: > 2. What does it mean to automatically generate instances for `(:=>)`? That is the question isn't it, I imagined it as `Typeable` or `Coercible` where the compiler creates instances on the fly but which instances I do not know. > While those classes are neat tricks that can get you some of the functionality of `QuantifiedConstraints`/`ImplicationConstraints`, they don't go all the way. `QuantifiedConstraints` and `ImplicationConstraints` would certainly be preferable! Are there any plans to research / implement such features? They would enable a lot of awesome code that is currently beyond reach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 02:41:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 02:41:19 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.fc273d197b0562219cac380227519592@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I have no specific, concrete plans to work on implication constraints, but I have a few enterprising students who may be looking for a project next semester. Implementation implication constraints is on the shortlist of projects to consider. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 02:41:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 02:41:42 -0000 Subject: [GHC] #2893: Implement "Quantified contexts" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.092bbfc5c6b78a931acbc2021a72e167@haskell.org> #2893: Implement "Quantified contexts" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: proposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I want to mention an example from 1997: [https://www.microsoft.com/en- us/research/wp-content/uploads/1997/01/multi.pdf Type classes: an exploration of the design space] > What we really want is universal quantification: > > {{{#!hs > class (forall s. Monad (m s)) > => StateMonad m where > get :: m s s > set :: s -> m s () > }}} which can be defined as {{{#!hs class ForallF Monad m => StateMonad m where get :: m s s set :: s -> m s () }}} How does it compare to `MonadState`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 03:05:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 03:05:38 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.85c078a9ebf158c92490564f31af358c@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ryantrinkle): I'm afraid it's my fault that these things have gotten mixed up. I asked Dan to look into this stuff in the hope that it would give some benefit in the Reflex case, but he found today that it doesn't quite fit. You're absolutely right that the Writer case is still useful. You're absolutely right about putting specialization under separate tickets, and we'll be doing that if we find anything in that vein. In the mean time, if Dan's work so far helps in the MonadWriter case, we'll try to get that wrapped up for this ticket soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 03:09:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 03:09:33 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.1058499ab36d5e72da0ad00fb478d29f@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.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 Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ack, this bug keeps creeping up in unexpected places. Well, since I'm in a bug-fixing mood, let's just patch Agda: https://github.com/agda/agda/pull/2310 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 06:07:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 06:07:16 -0000 Subject: [GHC] #11338: Unwind information is incorrect in region surrounding a safe foreign call In-Reply-To: <046.63160c8569d055bb9627f95207d1d3a0@haskell.org> References: <046.63160c8569d055bb9627f95207d1d3a0@haskell.org> Message-ID: <061.1b3e7fbae801ffafb80bb869d171c690@haskell.org> #11338: Unwind information is incorrect in region surrounding a safe foreign call -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11337, #11353 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Compiler (CodeGen) * milestone: => 8.2.1 @@ -1,4 +1,3 @@ - Safe foreign calls can occur at the end of a block. Like #11337, these - produce incorrect debug information. However, the situation is worse in - the case of foreign calls since these return to the calling block. This - means that we are currently unable to unwind out of a safe foreign call. + The code generator produces a prologue and epilogue around a safe foreign + call to suspend and resume the thread state. This needs to be decorated + with proper unwind information. New description: The code generator produces a prologue and epilogue around a safe foreign call to suspend and resume the thread state. This needs to be decorated with proper unwind information. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 06:07:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 06:07:38 -0000 Subject: [GHC] #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls In-Reply-To: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> References: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> Message-ID: <061.0deeea2ccbe936b6a5701dcd5bce8191@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11338, #11337 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler (CodeGen) => Compiler (NCG) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 08:33:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 08:33:50 -0000 Subject: [GHC] #12798: LLVM seeming to over optimize, producing inefficient assembly code... In-Reply-To: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> References: <050.c7bc7da5f0632b6e39cdd048e6c5755f@haskell.org> Message-ID: <065.5af5e625a760db73d2c5c213bea64f47@haskell.org> #12798: LLVM seeming to over optimize, producing inefficient assembly code... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by GordonBGood): @AlexET, Replying to [comment:1 AlexET]: > On current HEAD with llvm 3.9.0, the following code: > > ... code skipped for brevity... > > The CMM and initial llvm code is the same as your code for 8.0.1, so it seems the difference is due to the fact that rust ships with its own more recent llvm than ghc 8.0.1 supports. > > The difference in the code between my version and your original version is that we force `twos` early which is needed to prevent the evaluation of that within the loop, an optimisation which seems to have been missed by HEAD. It's even worse with GHC version 8.0.1 than I thought:, with the very minor change of the inner loop to as follows: {{{ let cull j = -- very tight inner loop where all the time is spent if j > bfLmt then return () else do let sh = unsafeAt twos (j .&. 31) let w = j `shiftR` 5 ov <- unsafeRead cmpstsw w unsafeWrite cmpstsw w (ov .|. sh) -- (1 `shiftL` (j .&. 31))) cull (j + p) in do { cull s; cullp (i + 1) } in cullp 0 }}} only changed so the loop back for the next prime value is outside the `cull` loop, the assembly code is as follows: {{{ .align 16, 0x90 .LBB33_3: # %caLP.i.caLP.i_crit_edge # in Loop: Header=BB33_2 Depth=1 movq (%r12), %rdx .LBB33_2: # %caLP.i # =>This Inner Loop Header: Depth=1 movq %rsi, %rcx movl %ecx, %edi movq %rdx, %rsi addq %rcx, %rsi sarq $5, %rcx movq -24(%r12), %rdx movq -16(%r12), %rbx andl $31, %edi movl 16(%rbx,%rdi,4), %edi orl %edi, 16(%rdx,%rcx,4) cmpq -8(%r12), %rsi jle .LBB33_3 }}} with three register reloads in the loop and another version in the code also reloading the `p` increment value for a total of four reloads. I can't see that the code generated should be any different then for the original ticket code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 09:26:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 09:26:58 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.36425c989f964d211f5d96f58e94ec87@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But do we need the full glory of `typeRepKind`, or just the ability to look at `(->)` levity arguments? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 09:55:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 09:55:49 -0000 Subject: [GHC] #12622: Unboxed static pointers lead to missing SPT entries In-Reply-To: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> References: <044.ed00efa526d7a4e027dd2c240e32a0ec@haskell.org> Message-ID: <059.9a41b15e0547a3b185186ec92d4a6382@haskell.org> #12622: Unboxed static pointers lead to missing SPT entries -------------------------------------+------------------------------------- Reporter: mboes | Owner: | facundo.dominguez Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2709 Wiki Page: | Phab:D2720 -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. In fact this "make it an exported Id" stuff can now be done later. The Grand Plan comment in `SimplCore` says {{{ The FloatOut pass is careful to produce an /exported/ Id for a floated 'StaticPtr', so the binding is not removed by the simplifier (see #12207). E.g. the code for `f` above might look like static_ptr = StaticPtr k f x = ...(staticKey static_ptr)... which might correctly be simplified to f x = ...... BUT the top-level binding for static_ptr must remain, so that it can be collected to populate the Static Pointer Table. }}} But if we generate `sp = makeStatic e)` not `sp = StaticPtr blah blah`, then `(staticKey sp)` won't simplify, but will still use `sp`. So no need for special treatment. Hooray. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 10:00:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 10:00:34 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.76221b307fca349f0981951bd9729e9e@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Just to check: as I understand it, you are working on this, but it's not ready for review. Can I urge you to write a ''specification'' of what you are trying to achieve? A wiki page is a good place to do that. It's super-hard to review code without knowing (precisely) what it is trying to do. And it's annoying for you if people suggest changes to the spec after you have already invested a lot in the impl. Thanks for doing this! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 10:02:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 10:02:27 -0000 Subject: [GHC] #12859: ghc/packages/Cabal is not a valid repository name In-Reply-To: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> References: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> Message-ID: <066.ff10087d820c000655c356a079d08d81@haskell.org> #12859: ghc/packages/Cabal is not a valid repository name ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by hvr): The different url-path scheme is what the command {{{ git config --global url."git://github.com/ghc/packages-".insteadOf git://github.com/ghc/packages/ }}} is supposed to rewrite automatically. What's the Git version you're using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 10:07:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 10:07:39 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.1af4eb45bc2ae9abce76a3932ac82200@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The specification is on the wiki. https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs The implementation is also finished and split up into two patches. One which refactors the pattern match checker (D2725) and one which implements the feature. (D2669) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 10:19:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 10:19:11 -0000 Subject: [GHC] #12863: Associated data families don't use superclasses when deriving instances In-Reply-To: <051.6aa25cf014d4c5be0a8a6bf0646cf7f9@haskell.org> References: <051.6aa25cf014d4c5be0a8a6bf0646cf7f9@haskell.org> Message-ID: <066.0e54299420dad02530e1a16a53173a85@haskell.org> #12863: Associated data families don't use superclasses when deriving instances -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is just what I'd expect. The `deriving( Functor )` clause is trying to infer a suitable context `???` for {{{ instance ??? => Functor (TotalMap (Identity key)) }}} Let's call this "deriving context inference" (DCI). To do that it needs `Functor (TotalMap key)`. But DCI insists on a simple context with a class applied to type variables, otherwise it could infer stupid context like `Num (Tree a)`. So it insists on being able to simplify `Functor (TotalMap key)` and it can't. It's true that `Key key` is also OK for `???`, since `Functor (TotalMap key)` is a superclass, but DCI will never guess that. Apart from anything else it might be too restrictive. Now I think you are pointing out that DCI for an ''associated'' data type could include the context of the parent instance declaration. It would add a bit more code and complexity (to the compiler and the user manual). And it might be much more restrictive than necessary. E.g. {{{ instance (Key key) => Key (Identity key) where data TotalMap (Identity key) val = Id val deriving( Functor ) }}} I suppose we ''could'' specify that the derived instance is {{{ instance (Key key) => Functor (TotalMap (Identity key)) }}} but today we'll get the superior {{{ instance Functor (TotalMap (Identity key)) }}} But it would be a valid alternative design. My suggestion: use a standalone deriving clause to specify the context yourself. As you point out, it's not hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 10:27:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 10:27:08 -0000 Subject: [GHC] #12864: Produce type errors after looking at whole applications In-Reply-To: <046.9b7f53593c0d6ec63beeb1ea65f1893a@haskell.org> References: <046.9b7f53593c0d6ec63beeb1ea65f1893a@haskell.org> Message-ID: <061.ee0ab950fb1daf42368d6cc660259cc6@haskell.org> #12864: Produce type errors after looking at whole applications -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for it, if you can see how to achieve it! The second paragraph of the Description is extremely hard to parse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 10:31:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 10:31:40 -0000 Subject: [GHC] #12867: Internal error while typechecking invalid program In-Reply-To: <046.2ab7f73f469c3c9979cc29eb99ddf47e@haskell.org> References: <046.2ab7f73f469c3c9979cc29eb99ddf47e@haskell.org> Message-ID: <061.9c09a48e6265d7bab67b4e0cf5a3b059@haskell.org> #12867: Internal error while typechecking invalid program -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Works in HEAD, although I'm not sure what fixed it. I'll commit a test. Not sure if it's worth trying to move it to 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 10:32:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 10:32:43 -0000 Subject: [GHC] #12866: GHC internal error while building darcsden In-Reply-To: <047.b99e56fbdb3bd24d0c5cb2ff430c4a60@haskell.org> References: <047.b99e56fbdb3bd24d0c5cb2ff430c4a60@haskell.org> Message-ID: <062.8ab2d38ebd999bc457120c13f43b3e56@haskell.org> #12866: GHC internal error while building darcsden -------------------------------------+------------------------------------- Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you try with HEAD? See #12867 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 10:34:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 10:34:46 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.8f9a49983a8b33b6329332bc701556e6@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK thanks, I did not know that. So are you declaring the specification and both patches ready for review? Worth sending an email to ghc-devs about that. Also, I hate to suggest this, but it looks like an ideal candidate for a GHC proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 10:48:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 10:48:00 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.458b93163c355d2ef94efdd83aacb3ab@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Yes everything should be ready for review. I just posted to the mailing list about it. I'm not interested in submitting a GHC proposal until there is a process for proposals to be actually accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 11:49:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 11:49:53 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312854=3A_ghc-8_prints_mangled_names?= =?utf-8?b?IGluIGVycm9yIG1lc3NhZ2U6IOKAmEdIQy5CYXNlLiRkbTwk4oCZ?= In-Reply-To: <045.b2961fab558879fceba382b527980ad8@haskell.org> References: <045.b2961fab558879fceba382b527980ad8@haskell.org> Message-ID: <060.f83ca83b4dc430aa42d4c3b5798fb519@haskell.org> #12854: ghc-8 prints mangled names in error message: ‘GHC.Base.$dm<$’ -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I can explain what is going on. I'm not so sure how to fix it. You don't get an overlapping error for your `C` declarations because you aren't ''using'' them. Class overlap is reported lazily; see the user manual. For the `Functor` declarations, since you omit the default method, we fill it in fo you {{{ instance Functor (F String) where fmap = undefined ($<) = $dm< @(F String) }}} The default method comes from the original class decl, which looked like this {{{ class Functor f where fmap :: (a -> b) -> f a -> f b (<$) :: a -> f b -> f a (<$) = fmap . const }}} From this we get {{{ $dm< :: Functor f => a -> f b -> f a }}} So, in the instance decl we get the constraint `Functor (F String)`. But we don't know which of the two instance decls to use to solve it, alas, hence the error. It's not very clear what a good error message would be; and even less clear how to achieve it! Perhaps some more explanation in the user manual, along the lines above, would be a stop-gap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 13:25:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 13:25:51 -0000 Subject: [GHC] #12868: Add groupOn function to Data.List Message-ID: <045.311a4a05408ec3bc7a3410f628e3ce08@haskell.org> #12868: Add groupOn function to Data.List -------------------------------------+------------------------------------- Reporter: wizzup | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: | Version: libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- sortOn was already add in #9004 but what about groupOn ? According to https://wiki.haskell.org/List_function_suggestions#groupOn_and_sortOn both functions are "so common". Although rejected in #2659, this might be a good time to reconsider. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 13:27:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 13:27:15 -0000 Subject: [GHC] #12868: Add groupOn function to Data.List In-Reply-To: <045.311a4a05408ec3bc7a3410f628e3ce08@haskell.org> References: <045.311a4a05408ec3bc7a3410f628e3ce08@haskell.org> Message-ID: <060.913fbeaf47eb0b67e73d70cc09519e11@haskell.org> #12868: Add groupOn function to Data.List -------------------------------------+------------------------------------- Reporter: wizzup | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by wizzup: @@ -1,1 +1,1 @@ - sortOn was already add in #9004 but what about groupOn ? + sortOn was already added in #9004 but what about groupOn ? New description: sortOn was already added in #9004 but what about groupOn ? According to https://wiki.haskell.org/List_function_suggestions#groupOn_and_sortOn both functions are "so common". Although rejected in #2659, this might be a good time to reconsider. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 13:34:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 13:34:53 -0000 Subject: [GHC] #12869: getChar doesn't work on a new Windows build Message-ID: <048.a9ae396b2f18efad7938113691fb259c@haskell.org> #12869: getChar doesn't work on a new Windows build -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Last night I updated my PC to the 14965 Windows insider build. Today I notice that `getLine` no longer terminates (pressing enter just goes to a new line), but I'm suspecting that the root cause it that `getChar` returns `'\NUL'` no mather what is input. I've tried this both GHCi and in a compiled program. This is only broken if I set my codepage to 65001 (UTF-8). If I set it to something like 850 it works as it should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 14:56:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 14:56:14 -0000 Subject: [GHC] #12859: ghc/packages/Cabal is not a valid repository name In-Reply-To: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> References: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> Message-ID: <066.3f9ec34675e77a1d1f14c437cac71af3@haskell.org> #12859: ghc/packages/Cabal is not a valid repository name ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by philderbeast): Versions of git from the command line here are ... {{{ git bash: git version 2.10.1.windows.1 git CMD: git version 2.10.1.windows.1 msys: git version 2.10.1 posh git: git version 2.10.2.windows.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 15:11:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 15:11:52 -0000 Subject: [GHC] #12859: ghc/packages/Cabal is not a valid repository name In-Reply-To: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> References: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> Message-ID: <066.b13b551966c67ad417ebe66ded116689@haskell.org> #12859: ghc/packages/Cabal is not a valid repository name ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by philderbeast): The rewrite rule wasn't in git's global config at {{{%USERPROFILE%/.gitconfig}}} so I added it and then checked again that it was there. {{{ $ git config --global url."git://github.com/ghc/packages-".insteadOf git://github.com/ghc/packages/ $ git config --global --list url.git://github.com/ghc/packages-.insteadof=git://github.com/ghc/packages/ }}} Having set the rewrite rule in the global config, the recursive clone works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 15:17:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 15:17:07 -0000 Subject: [GHC] #12859: ghc/packages/Cabal is not a valid repository name In-Reply-To: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> References: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> Message-ID: <066.115d0973b1a018f774198b4062fe360f@haskell.org> #12859: ghc/packages/Cabal is not a valid repository name ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by philderbeast): On windows, depending on which shell and application is used, the global git config file can be at ... {{{ %USERPROFILE%\.gitconfig $HOME/.gitconfig %APPDATA%\.gitconfig }}} SOURCE: [https://www.onwebsecurity.com/windows/git-on-windows-location-of- global-configuration-file] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 15:23:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 15:23:16 -0000 Subject: [GHC] #12864: Produce type errors after looking at whole applications In-Reply-To: <046.9b7f53593c0d6ec63beeb1ea65f1893a@haskell.org> References: <046.9b7f53593c0d6ec63beeb1ea65f1893a@haskell.org> Message-ID: <061.f451b222b45532ce7b64f1d1af0f7e39@haskell.org> #12864: Produce type errors after looking at whole applications -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -6,6 +6,6 @@ - In many cases the error messages would be better if it would at one - application if a function at once, and, in general, present the user with - the (inferred) type of the function as well as the (expected) type due to - the argument. This way, only one type error will be reported per function - application, and comparing these two reported types will allow the user to - spot the problem more easily. + In many cases a procedure like the following would be better: For a given + application `f a1 a2 a3`, present the user with the (inferred) type of + `f`, as well as the (expected) type `f` needs to have to be used with + arguments `a1 a2 a3`. This way, only one type error will be reported per + function application, instead of many, and comparing these two reported + types will allow the user to spot the problem more easily. New description: Currently, the type error messages we produce in case of function applications are rather dumb, in particular if arguments were ommited, added, swapped or not parenthized correctly. (Examples in the first comment below.) In many cases a procedure like the following would be better: For a given application `f a1 a2 a3`, present the user with the (inferred) type of `f`, as well as the (expected) type `f` needs to have to be used with arguments `a1 a2 a3`. This way, only one type error will be reported per function application, instead of many, and comparing these two reported types will allow the user to spot the problem more easily. (With „one application“ I mean `e1 e2 e3 … en` where `e1` is not of that form.) Furthermore, once we have these two types in our hands, we can look for common patterns, and give even more helpful error messages, such as suggesting to swap two arguments. Clearly, there are many tricky corner cases (e.g. polymorphic functions, types with constraints or type classes, type applications etc.). But that should not stop us from trying better in obvious, monomorphic cases. -- Comment (by nomeata): Reformulated it a bit. I stared a bit at the code, but it is not obvious how to do it: Type information moves from the function towards the arguments and then down, and eventually hits something that does not match. I don’t know enough about the type checker to see if this can sensibly be refactored, and what would be the cost (e.g. performance?) Maybe I’ll try to corner Richard someday and talk this over with him. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 15:37:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 15:37:59 -0000 Subject: [GHC] #12866: GHC internal error while building darcsden In-Reply-To: <047.b99e56fbdb3bd24d0c5cb2ff430c4a60@haskell.org> References: <047.b99e56fbdb3bd24d0c5cb2ff430c4a60@haskell.org> Message-ID: <062.11ccb8097764148a792203a1d6692407@haskell.org> #12866: GHC internal error while building darcsden -------------------------------------+------------------------------------- Reporter: simonmic | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonmic: @@ -3,1 +3,1 @@ - $ darcs get hub.darcs.net:simon/darcsden-ghc8 + $ darcs get http://hub.darcs.net/simon/darcsden-ghc8 [--lazy] New description: I get an internal error while building darcsden with GHC 8.0.1: {{{ $ darcs get http://hub.darcs.net/simon/darcsden-ghc8 [--lazy] $ cd darcsden-ghc8 $ stack --stack-yaml=stack-ghc8.yaml build ... [12 of 56] Compiling DarcsDen.Backend.Transient ( src/DarcsDen/Backend/Transient.hs, .stack- work/dist/i386-linux/Cabal-1.24.0.0/build/DarcsDen/Backend/Transient.o ) /home/simon/src/darcsden/src/DarcsDen/Backend/Transient.hs:10:33: error: • GHC internal error: ‘BackendTransientM’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [ajE2 :-> Type variable ‘bt’ = bt] • In the first argument of ‘MonadIO’, namely ‘BackendTransientM bt’ In the type ‘(BT bt, MonadIO (BackendTransientM bt))’ In the type declaration for ‘BTIO’ /home/simon/src/darcsden/src/DarcsDen/Backend/Transient.hs:44:1: error: • Non type-variable argument in the constraint: Functor (BackendTransientM bt) (Use FlexibleContexts to permit this) • In the context: (Functor (BackendTransientM bt), Monad (BackendTransientM bt)) While checking the super-classes of class ‘BackendTransient’ In the class declaration for ‘BackendTransient’ -- While building package darcsden-1.1.99 using: /home/simon/.stack/setup-exe-cache/i386-linux/setup-Simple- Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack- work/dist/i386-linux/Cabal-1.24.0.0 build lib:darcsden exe:darcsden exe :darcsden-post-hook exe:da... Process exited with code: ExitFailure 1 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 15:46:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 15:46:06 -0000 Subject: [GHC] #12868: Add groupOn function to Data.List In-Reply-To: <045.311a4a05408ec3bc7a3410f628e3ce08@haskell.org> References: <045.311a4a05408ec3bc7a3410f628e3ce08@haskell.org> Message-ID: <060.4e25990183cf892ddb207a9fca1d74d3@haskell.org> #12868: Add groupOn function to Data.List -------------------------------------+------------------------------------- Reporter: wizzup | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Worth considering. You should raise the issue on the `libraries` list, following the process outlined on https://wiki.haskell.org/Library_submissions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 15:46:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 15:46:35 -0000 Subject: [GHC] #12859: ghc/packages/Cabal is not a valid repository name In-Reply-To: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> References: <051.c1f764cd9ffaeebed40b4ed8669c32e1@haskell.org> Message-ID: <066.c6a9cdb72565d26a8e12e912641ab103@haskell.org> #12859: ghc/packages/Cabal is not a valid repository name ---------------------------------+-------------------------------------- Reporter: philderbeast | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by philderbeast): I use posh git and git from msys. I see that {{{%USERPROFILE%\.gitconfig}}} and {{{$HOME/.gitconfig}}} are the same file location. In any case, when I was unable to repeat the recursive clone, I tried every git client I have installed and all failed. Previously, one client, I can't remember which, had succeeded. I did have to run CHKDSK to repair the drive on which I was compiling and testing ghc. However, this is {{{E:}}}, not the {{{C:}}} system drive with git's global config. I don't see how this could explain losing the rewrite rule. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 20:45:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 20:45:48 -0000 Subject: [GHC] #12870: Allow completely disabling +RTS options parsing Message-ID: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> #12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'd like to have a way to completely disable the +RTS flag so that a ghc- compiled binary does not eat it, but keeps it in `argv`/`getArgs` instead. This is needed whenever you try to make a program that's supposed to pass on all arguments, for example something like `ccache` or [https://github.com/fpco/pid1 pid1]. As you can imagine, swallowing +RTS argument's isn't great when you want to pass them on to a Haskell program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 20:46:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 20:46:35 -0000 Subject: [GHC] #12870: Allow completely disabling +RTS options parsing In-Reply-To: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> References: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> Message-ID: <057.fa133d3d0fd05898c358806e3db650d4@haskell.org> #12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): From IRC: {{{ rwbarton: nh2_: looks like -rtsopts=none will do it, judging from the source rwbarton: or hm, maybe not rwbarton: I guess it will consume +RTS and then error out rwbarton: it looks like it would probably be pretty easy to implement }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 21:02:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 21:02:11 -0000 Subject: [GHC] #12857: associate pattern synonyms with a type synonym In-Reply-To: <044.977a800271703c596610344012947691@haskell.org> References: <044.977a800271703c596610344012947691@haskell.org> Message-ID: <059.98094176415b081c8f588a746d2419c1@haskell.org> #12857: associate pattern synonyms with a type synonym -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): See also https://github.com/ghc-proposals/ghc-proposals/pull/28 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 21:03:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 21:03:42 -0000 Subject: [GHC] #12870: Allow completely disabling +RTS options parsing In-Reply-To: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> References: <042.8ee30dc911ab648c85fb1ba15e356468@haskell.org> Message-ID: <057.b4a704f464d9b2413334cad48d87f05a@haskell.org> #12870: Allow completely disabling +RTS options parsing -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Agree that this would be useful, but as a workaround you can always use `--RTS` as the first argument to your program; it will be consumed by the RTS, and then disable all further command-line processing by the RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 21:24:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 21:24:35 -0000 Subject: [GHC] #7637: split-objs not supported for ARM In-Reply-To: <049.80911b8f0baddee1dd8f96bbf6de9b0e@haskell.org> References: <049.80911b8f0baddee1dd8f96bbf6de9b0e@haskell.org> Message-ID: <064.8b048bb1a65c8a6478c612c316aa4858@haskell.org> #7637: split-objs not supported for ARM -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Compile-time | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: #8300 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #8300 Comment: Given that ARM is essentially solely supported by LLVM at this point, I think it's fair to call this a duplicate of #8300. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 21:29:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 21:29:06 -0000 Subject: [GHC] #11219: Implement fine-grained `-Werror=...` facility In-Reply-To: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> References: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> Message-ID: <057.3ff2a3162751e1971dde4ffcdeb29d45@haskell.org> #11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11796 | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"514acfe4c4e61941c2fa2e06cff02f6e4424e5e6/ghc" 514acfe4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="514acfe4c4e61941c2fa2e06cff02f6e4424e5e6" Implement fine-grained `-Werror=...` facility This patch add new options `-Werror=...`, `-Wwarn=...` and `-Wno-error=...` (synonym for `-Wwarn=...`). Semantics: - `-Werror` marks all warnings as fatal, including those that don't have a warning flag, and CPP warnings. - `-Werror=...` enables a warning and marks it as fatal - `-Wwarn=...` marks a warning as non-fatal, but doesn't disable it Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: mpickering, svenpanne, RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D2706 GHC Trac Issues: #11219 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 21:29:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 21:29:06 -0000 Subject: [GHC] #12796: hschooks.c #include path is incorrect In-Reply-To: <046.be652681697ce65090aa6a04158d2f64@haskell.org> References: <046.be652681697ce65090aa6a04158d2f64@haskell.org> Message-ID: <061.8ede2274371c0d4cceb2859520f67faf@haskell.org> #12796: hschooks.c #include path is incorrect -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1399c8b481bd04848377b2f8a449e0bb09f0bb65/ghc" 1399c8b4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1399c8b481bd04848377b2f8a449e0bb09f0bb65" ghc/hschooks.c: Fix include path of Rts.h We need to ensure that we don't include Rts.h from bootstrap compiler. See #12796. Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2698 GHC Trac Issues: #12796 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 21:29:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 21:29:06 -0000 Subject: [GHC] #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 In-Reply-To: <044.9c8bab5a25e1b9b83e76116a3cc77c77@haskell.org> References: <044.9c8bab5a25e1b9b83e76116a3cc77c77@haskell.org> Message-ID: <059.474397777a70b15c047864c82b403e60@haskell.org> #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ea76a213d14709ded827abeb2246e4daa154e92e/ghc" ea76a213/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ea76a213d14709ded827abeb2246e4daa154e92e" add ieee754 next* functions to math_funs Reviewers: austin, simonmar, trofi, bgamari Reviewed By: bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2671 GHC Trac Issues: #12802 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 21:32:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 21:32:25 -0000 Subject: [GHC] #8300: split-objs doesn't split on LLVM In-Reply-To: <047.984373a836be528107e61ac010d1d280@haskell.org> References: <047.984373a836be528107e61ac010d1d280@haskell.org> Message-ID: <062.ed7cb8c8b6b38fd99adfe63ebc2d2793@haskell.org> #8300: split-objs doesn't split on LLVM -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.7 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8629 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: Given that functions sections are now implemented (see #8405) and support by LLVM, I'll mark this as won't-fix. If you, the reader, find yourself still wanting this feature for some reason feel free to reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 22 22:44:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 22 Nov 2016 22:44:41 -0000 Subject: [GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary In-Reply-To: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> References: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> Message-ID: <060.d5ce36ec225a546b2a85f38f66ca86cd@haskell.org> #12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: philderbeast Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2734 Wiki Page: | -------------------------------------+------------------------------------- Changes (by philderbeast): * status: new => patch * differential: => Phab:D2734 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 00:26:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 00:26:47 -0000 Subject: [GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary In-Reply-To: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> References: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> Message-ID: <060.342ce7ad453a408dbdabfe8d2e080c6c@haskell.org> #12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: philderbeast Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2734 Wiki Page: | -------------------------------------+------------------------------------- Comment (by philderbeast): Found these failures ... {{{ Unexpected results from: TEST="T3468 tcfail072 T8119 KindInvariant" }}} Of those, only T3468 is showing forall in the diff ... {{{ Actual stderr output differs from expected: and its hs-boot file Main module: type role Tool phantom data Tool d where - F :: a -> Tool d + F :: forall d a r. a -> Tool d Boot file: abstract Tool The types have different kinds *** unexpected failure for T3468(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 02:02:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 02:02:49 -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.1623c83b31715af6a2101849b51fde9a@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by dobenour): If rewritten in Haskell, it would be ''very'' easy to run `ghc-split` in- process – just run it in a separate Haskell thread, and send data to it over a pipe or channel. That should solve the binary size worries. In fact, the LLVM mangler could easily be made to work this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 03:05:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 03:05:16 -0000 Subject: [GHC] #12852: threadWaitReadSTM does not provide a way to unregister action. In-Reply-To: <045.2f266f155c2facba66adab2831aa3543@haskell.org> References: <045.2f266f155c2facba66adab2831aa3543@haskell.org> Message-ID: <060.1a80de613ee0e8dfaebdf168217b4a57@haskell.org> #12852: threadWaitReadSTM does not provide a way to unregister action. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2729 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f43025340d05d3c6085c41e441d278745f34a317/ghc" f4302534/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f43025340d05d3c6085c41e441d278745f34a317" Allow to unregister threadWaitReadSTM action. Allow to unregister threadWaitReadSTM/threadWaitWriteSTM on a non-threaded runtime. Previosly noop action was returned, as a result it was not possible to unregister action, unless data arrives to Fd or it's closed. Fixes #12852. Reviewers: simonmar, hvr, austin, bgamari, trofi Reviewed By: bgamari, trofi Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2729 GHC Trac Issues: #12852 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 09:04:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 09:04:04 -0000 Subject: [GHC] #12868: Add groupOn function to Data.List In-Reply-To: <045.311a4a05408ec3bc7a3410f628e3ce08@haskell.org> References: <045.311a4a05408ec3bc7a3410f628e3ce08@haskell.org> Message-ID: <060.5ba643795f1f7ac01147a000b6673206@haskell.org> #12868: Add groupOn function to Data.List -------------------------------------+------------------------------------- Reporter: wizzup | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by wizzup): On a side note; the `Data.List.Split` use `On` with different meaning. There should not be inconsistency in `Data.List` and `Data.List.Split`. {{{ > splitOn "x" "axbxc" ["a","b","c"] > splitOn "x" "axbxcx" ["a","b","c",""] > splitWhen (<0) [1,3,-4,5,7,-9,0,2] [[1,3],[5,7],[0,2]] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 10:00:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 10:00:22 -0000 Subject: [GHC] #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 Message-ID: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D2749 | Wiki Page: -------------------------------------+------------------------------------- Bump up the bindists to have a more up to date gcc and binutils. The updated binutils should fix LLVM backend on 64bit Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 10:01:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 10:01:11 -0000 Subject: [GHC] #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 In-Reply-To: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> References: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> Message-ID: <059.bb99d3c9c5c7ae9172b784a9485b6834@haskell.org> #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 10:02:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 10:02:10 -0000 Subject: [GHC] #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 In-Reply-To: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> References: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> Message-ID: <059.0764ff2e784b0da2ea44c0422b515f88@haskell.org> #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 10:03:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 10:03:14 -0000 Subject: [GHC] #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 In-Reply-To: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> References: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> Message-ID: <059.a2455c04f4928a7624c10a6e7c8e9266@haskell.org> #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 11:14:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 11:14:13 -0000 Subject: [GHC] #12711: GHC Internal error, unboxed sums In-Reply-To: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> References: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> Message-ID: <066.ff17ea687a4785f870d8b08b8f1e4fa1@haskell.org> #12711: GHC Internal error, unboxed sums -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: osa1 Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Sorry I saw this just now. I'll fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 13:02:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 13:02:44 -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.7fcc6325801bb10cfd66cf20ed996343@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): I think we might just deprecate `ghc-split` as a whole for Windows no @bgamari? With the updated toolchain we should be able to get `function- sections` working on Windows as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 13:23:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 13:23:44 -0000 Subject: [GHC] #12872: Pattern synonyms allow multiple type signatures but only use the first Message-ID: <046.b85d07d8719090fd68889da7dd80ef73@haskell.org> #12872: Pattern synonyms allow multiple type signatures but only use the first -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC seems to only be using the first signature for pattern synonyms GHC 8.0.2 allows this to compile: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Pattern where pattern Foo :: () pattern Foo :: Bool pattern Foo = () }}} but not this: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Pattern where pattern Foo :: Bool pattern Foo :: () pattern Foo = () }}} This compiles and ghci tells me the type of `Foo` is `()`: {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Pattern where pattern Foo :: () pattern Foo :: Bool pattern Foo <- _ where Foo = undefined }}} This doesn't compile (as expected): {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Pattern where pattern Foo :: () pattern Foo :: Bool Bool pattern Foo = () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 13:27:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 13:27:45 -0000 Subject: [GHC] #12872: Pattern synonyms allow multiple type signatures but only use the first In-Reply-To: <046.b85d07d8719090fd68889da7dd80ef73@haskell.org> References: <046.b85d07d8719090fd68889da7dd80ef73@haskell.org> Message-ID: <061.6fc2ca9a3e6f782495a87827725a3010@haskell.org> #12872: Pattern synonyms allow multiple type signatures but only use the first -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This is fixed in HEAD. {{{ [1 of 1] Compiling Pattern (.hs -> .o) test.hs:5:10: error: Duplicate pattern synonym signatures for ‘Foo’ at test.hs:4:10-12 test.hs:5:10-12 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 13:29:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 13:29:34 -0000 Subject: [GHC] #12872: Pattern synonyms allow multiple type signatures but only use the first In-Reply-To: <046.b85d07d8719090fd68889da7dd80ef73@haskell.org> References: <046.b85d07d8719090fd68889da7dd80ef73@haskell.org> Message-ID: <061.9e6712dda6236ae656eb3f785d49b121@haskell.org> #12872: Pattern synonyms allow multiple type signatures but only use the first -------------------------------------+------------------------------------- Reporter: jophish | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => PatternSynonyms * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 14:48:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 14:48:01 -0000 Subject: [GHC] #12455: Compact Regions In-Reply-To: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> References: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> Message-ID: <062.ba59ead1a91c569fa4af824d51d446e6@haskell.org> #12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2751 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D2751 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 16:14:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 16:14:20 -0000 Subject: [GHC] #12873: hWaitForInput with socket as handle excepts on windows Message-ID: <044.1ddaa628578738df0ad8573626efc264@haskell.org> #12873: hWaitForInput with socket as handle excepts on windows --------------------------------------+---------------------------------- Reporter: bwurk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- If I create a socket wrapped in a Handle (either by directly creating a handle with connectTo, or by creating a socket and wrapping it), hWaitForInput and hReady always give an exception with that handle. It excepts directly when calling, it does not wait until the given timeout of hWaitForInput has expired. The following code exposes the bug (requiring that a server-socket is listening on port 7892): {{{#!hs module SockDebug where import System.IO import Network main = do sock <- connectTo "localhost" (Service $ show 7892) hWaitForInput sock 5000 }}} Excepts with "hWaitForInput: invalid argument (Invalid argument)" Happens both on windows 10 and windows 7. This is the same error as in ticket 1198 so I'd guess that the bug is in cbits/inputReady.c as well, but I'm not an expert. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 18:55:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 18:55:10 -0000 Subject: [GHC] #12874: Read/Show Incompatibility in base Message-ID: <049.71359ccd92bc2a67db9803ae9158d252@haskell.org> #12874: Read/Show Incompatibility in base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just stumbled across a situation where the deriving machinery, in combination with types provided by base, produces Show/Read instances that are incompatible. Here is a minimal example: {{{#!hs import Data.Proxy main :: IO () main = do x <- readLn print (x :: Thing (Proxy Int)) data Thing a = Thing a deriving (Read,Show) }}} If you run this program and type "Thing Proxy" into standard in, you get a parse error. If you type in "Thing (Proxy)", it works fine. Calling `show` on `Thing Proxy` gives the string "Thing Proxy" though. So, `read . show =/= id` in this case. This might just be an issue with `Proxy`'s Read instance, but I'm not really sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 18:59:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 18:59:19 -0000 Subject: [GHC] #12711: GHC Internal error, unboxed sums In-Reply-To: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> References: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> Message-ID: <066.c5c924eb095e9cdd5370534cdfb58339@haskell.org> #12711: GHC Internal error, unboxed sums -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: osa1 Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2753 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D2753 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 19:48:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 19:48:41 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.50a4ddc3aa53b641a62b813761b5a5e0@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | ------------------------------------+-------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2749 * milestone: 8.0.1 => 8.2.1 Comment: Updating the bindist for 8.2, Didn't have enough testing to include it for 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 19:51:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 19:51:23 -0000 Subject: [GHC] #11575: Program crashes only when compiled via LLVM In-Reply-To: <049.d1272a840a63edf1ed87ef1d7e8f2f1e@haskell.org> References: <049.d1272a840a63edf1ed87ef1d7e8f2f1e@haskell.org> Message-ID: <064.495c5e307b9e66f40a7a0e0795c9383e@haskell.org> #11575: Program crashes only when compiled via LLVM ----------------------------------+-------------------------------------- Reporter: Guest00000 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: duplicate | Keywords: llvm Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #8974 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate * related: => #8974 Comment: Hi, sorry seem to have missed this ticket.. It seems to be a duplicate of #8974. A patch for this will be in GHC 8.2. If it is not, please re-open the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 19:59:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 19:59:08 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.44aadd11bae28383589a391700fc23b4@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D2752 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 21:34:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 21:34:31 -0000 Subject: [GHC] #12864: Produce type errors after looking at whole applications In-Reply-To: <046.9b7f53593c0d6ec63beeb1ea65f1893a@haskell.org> References: <046.9b7f53593c0d6ec63beeb1ea65f1893a@haskell.org> Message-ID: <061.76c7dce604c0730c3746aadfb9dbb740@haskell.org> #12864: Produce type errors after looking at whole applications -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): We briefly talked about this, and it is not obviously easily possible. Currently, the type checker will, for example with `ex2 = fid d1 i1`, create two insoluble wanted constraints, one at `d1` and one at `i1`, which are then reported separately. So here is a wild and not-thought through idea: We already have the machinery to turn (some) type errors into coercions. So how about this scheme: * The type checker runs. Type errors that can be “fixed” by coercions are fixed this way, and ''not'' reported right now. The others are reported as ususal. * (New step) We try to detect common, interesting patterns of code and error coercions, and possibly move them around. For example: {{{ (i ▷ (DelayedError Int Double), d ▷ (DelayedError Double Int)) :: (Double, Int) }}} would be re-written to {{{ (i, d) ▷ (DelayedError (Int, Double) (Double, Int)) :: (Double, Int) }}} This pass would only move these coercion wrappers around, otherwise, we preserve the AST as entered by the user. * Finally, the syntax tree is traversed as well, and all `DelayedError` axioms are reported. One side-effect of this would be that we could report error messages citing the actual source of the context where they appear, in the actual syntax of the user (using annotations), which might work better than our current context-explanation-generating machinery. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 23:28:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 23:28:36 -0000 Subject: [GHC] #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable Message-ID: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple StaticPointers | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider that you have a package called `lib` which exposes these modules, {{{#!hs module ALib.Types where data AThing = AThing String deriving (Show) {-# LANGUAGE StaticPointers #-} module ALib.Things where import GHC.StaticPtr import ALib.Types thing1 :: StaticPtr AThing thing1 = static (AThing "hello") }}} Now consider that you have a server which reads a `StaticKey` of `StaticPtr AThing` and shows it, {{{#!hs import ALib.Types main :: IO () main = do key <- readFingerprint <$> getContents :: IO StaticKey Just thing <- unsafeLookupStaticPtr key :: IO (Maybe (StaticPtr AThing)) print $ deRefStaticPtr thing }}} Naturally this executable will link against `lib`. However, this executable as-written will fail if given the key of `ALib.Things.thing1`. Fixing this requires that the executable explicitly import and use a definition from `ALib.Things`. The problem appears to be that the linker elides the `ALib.Things` object from the final executable unless it refers to a symbol. Note that things also work fine if the server executable is dynamically linked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 23:30:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 23:30:06 -0000 Subject: [GHC] #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable In-Reply-To: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> References: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> Message-ID: <061.6388e187bcea92930aa06b66cb71e573@haskell.org> #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -7,0 +7,1 @@ + New description: Consider that you have a package called `lib` which exposes these modules, {{{#!hs module ALib.Types where data AThing = AThing String deriving (Show) {-# LANGUAGE StaticPointers #-} module ALib.Things where import GHC.StaticPtr import ALib.Types thing1 :: StaticPtr AThing thing1 = static (AThing "hello") }}} Now consider that you have a server which reads a `StaticKey` of `StaticPtr AThing` and shows it, {{{#!hs import ALib.Types main :: IO () main = do key <- readFingerprint <$> getContents :: IO StaticKey Just thing <- unsafeLookupStaticPtr key :: IO (Maybe (StaticPtr AThing)) print $ deRefStaticPtr thing }}} Naturally this executable will link against `lib`. However, this executable as-written will fail if given the key of `ALib.Things.thing1`. Fixing this requires that the executable explicitly import and use a definition from `ALib.Things`. The problem appears to be that the linker elides the `ALib.Things` object from the final executable unless it refers to a symbol. Note that things also work fine if the server executable is dynamically linked. -- Comment (by bgamari): See https://github.com/bgamari/T12875-repro for a functional example of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 23 23:30:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 23 Nov 2016 23:30:25 -0000 Subject: [GHC] #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable In-Reply-To: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> References: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> Message-ID: <061.12ac8ff3cb350eb48ea0985ae95413de@haskell.org> #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: dcoutts (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 00:01:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 00:01:45 -0000 Subject: [GHC] #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable In-Reply-To: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> References: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> Message-ID: <061.9466fb3aa15d97f65901dc490d678cc4@haskell.org> #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Perhaps it is possible to stop the linker from removing modules from the final executable when they use the `StaticPointers` language extension. That failing, the simplest solution could be to document that the module defining static pointers needs to be imported transitively into the main module of an executable supposed to find them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 01:13:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 01:13:33 -0000 Subject: [GHC] #12711: GHC Internal error, unboxed sums In-Reply-To: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> References: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> Message-ID: <066.99893279cf5b9f3e7c912a20bac999e2@haskell.org> #12711: GHC Internal error, unboxed sums -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: osa1 Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2753 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"14ac3725eb1e93289f205cbf432b537f6c84c4dc/ghc" 14ac3725/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14ac3725eb1e93289f205cbf432b537f6c84c4dc" Collect wildcards in sum types during renaming (#12711) This patch also removes the "catch all" pattern in the function and explicitly lists constructors to get a warning in the future if a new `HsType` was added. Reviewers: bgamari, austin, simonpj Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2753 GHC Trac Issues: #12711 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 01:15:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 01:15:04 -0000 Subject: [GHC] #12711: GHC Internal error, unboxed sums In-Reply-To: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> References: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> Message-ID: <066.2c081619838ed74f1dd8ef057f78801d@haskell.org> #12711: GHC Internal error, unboxed sums -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: osa1 Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2753 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 01:28:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 01:28:01 -0000 Subject: [GHC] #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable In-Reply-To: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> References: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> Message-ID: <061.894fcf6b70b126f494f3ea4ee02f5bf0@haskell.org> #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): > That failing, the simplest solution could be to document that the module defining static pointers needs to be imported transitively into the main module of an executable supposed to find them. That solution would be as anti-modular as non StaticPtr remote tables. Losing modularity would defeat much of the purpose of this language extension. Surely we can let the linker know that downstream modules *might* depend on `ALib.Things`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 08:30:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 08:30:17 -0000 Subject: [GHC] #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable In-Reply-To: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> References: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> Message-ID: <061.cb1523c60864d2b9fad8bb77d38321c9@haskell.org> #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you explain a bit more what the problem is? In the description what is `things1`? In general if a Haskell process deserialises, say from a network message, the key of a static pointer, there is no guarantee that it'll be in its SPT. Also I don't understand the API. What's unsafe about looking up a static pointer? Surely we shouldn't be exposing low-level details like fingerprints? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 09:00:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 09:00:15 -0000 Subject: [GHC] #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable In-Reply-To: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> References: <046.fb0d5a3c144e65e427af06126af5a4cb@haskell.org> Message-ID: <061.6292713163e85e68178fadba58d79062@haskell.org> #12875: GHC fails to link all StaticPointers-defining modules of a library in an executable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | StaticPointers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): > Also I don't understand the API. What's unsafe about looking up a static pointer? Surely we shouldn't be exposing low-level details like fingerprints? I think both of these points were already discussed in previous tickets (but I don't have pointers handy right now). The only lookup operation we have right now is one that doesn't check that you're looking up at the right type. That's because we don't yet store in the SPT what the type of the pointer really should be. As for fingerprints: an alternative is to expose {{{ serializeStaticPtr :: ... => StaticPtr a -> ByteString unserializeStaticPtr :: ... => ByteString -> StaticPtr a }}} As discussed, not a viable API, because then `base` depends on `bytestring`. That API would have the compiler make more assumptions than it needs to. With the current API the user has the freedom to serialize/deserialize in whatever way she wants (including e.g. integers created by a perfect hash function). IOW we try to bake into the compiler as little as possible, leaving the rest to implementation choices in "userland" libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 09:08:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 09:08:53 -0000 Subject: [GHC] #12479: build fail of commercialhaskell.com with stack build on mac os x sierra In-Reply-To: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> References: <047.7670c81fff3911fb27fec4bdb084ac72@haskell.org> Message-ID: <062.fc5eacc01a93c86e79066b7c7746ed9a@haskell.org> #12479: build fail of commercialhaskell.com with stack build on mac os x sierra -------------------------------------+------------------------------------- Reporter: stephenb | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12198 | Differential Rev(s): Phab:D2532 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ilovezfs): Sources for Sierra's dyld have now been posted: https://opensource.apple.com/source/dyld/dyld-421.1/ https://opensource.apple.com/tarballs/dyld/dyld-421.1.tar.gz https://opensource.apple.com/source/dyld/dyld-421.1/src/ImageLoader.h.auto.html {{{ #define MAX_MACH_O_HEADER_AND_LOAD_COMMANDS_SIZE (32*1024) }}} https://opensource.apple.com/source/dyld/dyld-421.1/src/ImageLoaderMachO.cpp.auto.html {{{ if ( sizeofcmds > (MAX_MACH_O_HEADER_AND_LOAD_COMMANDS_SIZE- sizeof(macho_header)) ) dyld::throwf("malformed mach-o: load commands size (%u) > %u", sizeofcmds, MAX_MACH_O_HEADER_AND_LOAD_COMMANDS_SIZE); }}} Note the changes from El Capitan https://opensource.apple.com/source/dyld/dyld-360.22/src/ImageLoaderMachO.cpp.auto.html Other Sierra sources: https://opensource.apple.com/release/os-x-1012.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 11:17:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 11:17:30 -0000 Subject: [GHC] #12441: Conflicting definitions error does not print explicit quantifiers when necessary In-Reply-To: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> References: <045.c17febc228a9db8632bc6adb53d95df5@haskell.org> Message-ID: <060.d9de7aa647f8fe2e9a013ec3c7b0f73b@haskell.org> #12441: Conflicting definitions error does not print explicit quantifiers when necessary -------------------------------------+------------------------------------- Reporter: ezyang | Owner: philderbeast Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2734 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for doing this patch. To me the extra-code to extra-benefit ratio feels a bit low. My suggestion: always print foralls when displaying the results from hi-boot- file mis-matches. * It's a relatively corner case that few people encounter, and those that do are probably not going to be puzzled by a forall. * If we start getting complaints that the foralls are cluttering things up for someone we can consider elaborating. In short, let's not solve a problem we don't yet have. Even with the "always print foralls" idea, the whole ppr-iface stuff is getting a bit baroque. We have * The print-foralls flag * The `ShowSub` info * Sometimes `hdr_only` flag goo Could we combine all three into a single record with three fields? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 11:40:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 11:40:57 -0000 Subject: [GHC] #10614: Show constraints in ``Found hole...'' In-Reply-To: <047.e629c8600a92660c55de2127511a14cd@haskell.org> References: <047.e629c8600a92660c55de2127511a14cd@haskell.org> Message-ID: <062.d5d7ba204565f8c529330d5a48250d6c@haskell.org> #10614: Show constraints in ``Found hole...'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This would not be hard. * Error messages generation is highly localised, in `TcErrors` * All the info about in-scope constraints is right there in the constraint tree, and is accessible in just the same way that we extract the "relevant bindings". More easily, actually! The only hard bit is deciding exactly what to print, and with what flags to control it. I'm happy to offer guidance. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 14:38:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 14:38:56 -0000 Subject: [GHC] #12876: Appreciate your work! Message-ID: <044.785bafe117eef99e54266b96b3ef8e4e@haskell.org> #12876: Appreciate your work! -------------------------------------+------------------------------------- Reporter: deech | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not a bug. Happy Thanksgiving and thanks for all your efforts! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 17:39:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 17:39:00 -0000 Subject: [GHC] #12877: Constant propagation with basic unboxed arithmetic instructions Message-ID: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> #12877: Constant propagation with basic unboxed arithmetic instructions -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a program that generates the following core: {{{#!hs main = case t of t0 0## -> ... DEFAULT -> case t0 -# 1## of t1 0## -> ... DEFAUT -> case t1 -# 1## of t2 0## -> ... DEFAULT -> case t2 -# 1## of _ 0## -> ... DEFAULT -> ... }}} I think it would be possible to implement constant propagation to get: {{{#!hs main = case t of _ 0## -> ... 1## -> ... 2## -> ... 3## -> ... DEFAULT -> ... }}} If I'm not mistaken, to do that we could replace occurences of: {{{#!hs case t -# k# of _ n0# -> ... n1# -> ... ... DEFAULT -> f }}} with: {{{#!hs case t of _ (n0#+k#) -> ... -- (ni#+k#) statically computed (n1#+k#) -> ... ... DEFAULT -> f }}} Any guidance on how to implement that would be appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 24 19:14:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 24 Nov 2016 19:14:48 -0000 Subject: [GHC] #11629: reify returns Dec that use ConT instead of PromotedT In-Reply-To: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> References: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> Message-ID: <060.962889bd8ec627f892aefd4a894ff893@haskell.org> #11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2188 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"d081fcfc08cfeb3fb729ed2b1df7119ea5b4cf97/ghc" d081fcf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d081fcfc08cfeb3fb729ed2b1df7119ea5b4cf97" Make quoting and reification return the same types Previously TH was incorrectly returning a `Dec` using a `ConT` instead of `PromotedT`. Test Plan: validate Reviewers: mainland, jstolarek, osa1, goldfire, thomie, bollmann, bgamari, RyanGlScott, austin Reviewed By: RyanGlScott Subscribers: erikd Differential Revision: https://phabricator.haskell.org/D2188 GHC Trac Issues: #11629 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 05:43:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 05:43:23 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.945090a1df6a636a3fd07dd177688a7d@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Thank you, everything makes sense except "does not substitute in `rho`". Perhaps I misunderstood something, but it seems it is essential to substitute into `rho` at some point and nowhere else is it done, so if I leave that out the original skolem variables are never replaced with taus and unification fails later on. Indeed I tried this out and it failed: I get the error `No instance for (C k0 k1 a0) arising from a use of ‘f’` when I try to do `:t f` for `class C a where f :: a b c`. If I leave in the substitution for `rho` everything seems to work fine. Note that I keep the unchecked substitutions in `deeply_instantiate` and only revert the one in `new_meta_tv_x` (which was the one causing the bug in the first place), since I'm worried making the other ones checked will cause other problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 09:29:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 09:29:49 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.318b30f1a80154ae9191d1f748c6f06f@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by simonpj): > everything makes sense except "does not substitute in rho". Remember: {{{ deeply_instantiate subst ty = deeplyInstantiate (substTy subst ty) }}} So `deeply_instantiate` '''itself''' is responsible for applying `subst` to `ty`, '''not'' the caller of `deeply_instantiate`. So I did miss something: in the `otherwise` case, which currently looks like {{{ | otherwise = return (idHsWrapper, ty) }}} you'll need to use `substTy subst ty`. Also make sure you use `newMetaTyVarsX` so that you pass in the current substitution and get an extended substitution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 11:30:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 11:30:26 -0000 Subject: [GHC] #12444: Regression: panic! on inaccessible code with constraint In-Reply-To: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> References: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> Message-ID: <060.d8fa18de06039dc2da7737a253f52f79@haskell.org> #12444: Regression: panic! on inaccessible code with constraint -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #12526 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1eec1f21268af907f59b5d5c071a9a25de7369c7/ghc" 1eec1f21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1eec1f21268af907f59b5d5c071a9a25de7369c7" Another major constraint-solver refactoring This patch takes further my refactoring of the constraint solver, which I've been doing over the last couple of months in consultation with Richard. It fixes a number of tricky bugs that made the constraint solver actually go into a loop, including Trac #12526 Trac #12444 Trac #12538 The main changes are these * Flatten unification variables (fmvs/fuvs) appear on the LHS of a tvar/tyvar equality; thus fmv ~ alpha and not alpha ~ fmv See Note [Put flatten unification variables on the left] in TcUnify. This is implemented by TcUnify.swapOverTyVars. * Don't reduce a "loopy" CFunEqCan where the fsk appears on the LHS: F t1 .. tn ~ fsk where 'fsk' is free in t1..tn. See Note [FunEq occurs-check principle] in TcInteract This neatly stops some infinite loops that people reported; and it allows us to delete some crufty code in reduce_top_fun_eq. And it appears to be no loss whatsoever. As well as fixing loops, ContextStack2 and T5837 both terminate when they didn't before. * Previously we generated "derived shadow" constraints from Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly generate a derived shadow from the same Wanted. A big change in this patch is to have two kinds of Wanteds: [WD] behaves like a pair of a Wanted and a Derived [W] behaves like a Wanted only See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh field of a Wanted. This turned out to be a lot simpler. A [WD] gets split into a [W] and a [D] in TcSMonad.maybeEmitShaodow. See TcSMonad Note [The improvement story and derived shadows] * Rather than have a separate inert_model in the InertCans, I've put the derived equalities back into inert_eqs. We weren't gaining anything from a separate field. * Previously we had a mode for the constraint solver in which it would more aggressively solve Derived constraints; it was used for simplifying the context of a 'deriving' clause, or a 'default' delcaration, for example. But the complexity wasn't worth it; now I just make proper Wanted constraints. See TcMType.cloneWC * Don't generate injectivity improvement for Givens; see Note [No FunEq improvement for Givens] in TcInteract * solveSimpleWanteds leaves the insolubles in-place rather than returning them. Simpler. I also did lots of work on comments, including fixing Trac #12821. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 11:30:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 11:30:26 -0000 Subject: [GHC] #12821: Find the incredible vanishing [The improvement story] In-Reply-To: <046.8f1c0172fb0349cdea42e58509937ad2@haskell.org> References: <046.8f1c0172fb0349cdea42e58509937ad2@haskell.org> Message-ID: <061.27ced97d78aa4dce2945564c91f7a94a@haskell.org> #12821: Find the incredible vanishing [The improvement story] -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1eec1f21268af907f59b5d5c071a9a25de7369c7/ghc" 1eec1f21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1eec1f21268af907f59b5d5c071a9a25de7369c7" Another major constraint-solver refactoring This patch takes further my refactoring of the constraint solver, which I've been doing over the last couple of months in consultation with Richard. It fixes a number of tricky bugs that made the constraint solver actually go into a loop, including Trac #12526 Trac #12444 Trac #12538 The main changes are these * Flatten unification variables (fmvs/fuvs) appear on the LHS of a tvar/tyvar equality; thus fmv ~ alpha and not alpha ~ fmv See Note [Put flatten unification variables on the left] in TcUnify. This is implemented by TcUnify.swapOverTyVars. * Don't reduce a "loopy" CFunEqCan where the fsk appears on the LHS: F t1 .. tn ~ fsk where 'fsk' is free in t1..tn. See Note [FunEq occurs-check principle] in TcInteract This neatly stops some infinite loops that people reported; and it allows us to delete some crufty code in reduce_top_fun_eq. And it appears to be no loss whatsoever. As well as fixing loops, ContextStack2 and T5837 both terminate when they didn't before. * Previously we generated "derived shadow" constraints from Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly generate a derived shadow from the same Wanted. A big change in this patch is to have two kinds of Wanteds: [WD] behaves like a pair of a Wanted and a Derived [W] behaves like a Wanted only See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh field of a Wanted. This turned out to be a lot simpler. A [WD] gets split into a [W] and a [D] in TcSMonad.maybeEmitShaodow. See TcSMonad Note [The improvement story and derived shadows] * Rather than have a separate inert_model in the InertCans, I've put the derived equalities back into inert_eqs. We weren't gaining anything from a separate field. * Previously we had a mode for the constraint solver in which it would more aggressively solve Derived constraints; it was used for simplifying the context of a 'deriving' clause, or a 'default' delcaration, for example. But the complexity wasn't worth it; now I just make proper Wanted constraints. See TcMType.cloneWC * Don't generate injectivity improvement for Givens; see Note [No FunEq improvement for Givens] in TcInteract * solveSimpleWanteds leaves the insolubles in-place rather than returning them. Simpler. I also did lots of work on comments, including fixing Trac #12821. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 11:30:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 11:30:26 -0000 Subject: [GHC] #12826: TyVar ASSERT failure in type family checking: T12041 In-Reply-To: <046.9d0fa2858f11e126141a89fb401b8d81@haskell.org> References: <046.9d0fa2858f11e126141a89fb401b8d81@haskell.org> Message-ID: <061.1e6607e97bb73648d4e6466a4c5bbdd5@haskell.org> #12826: TyVar ASSERT failure in type family checking: T12041 -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"18d0bdd3848201882bae167e3b15fd797d217e93/ghc" 18d0bdd3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="18d0bdd3848201882bae167e3b15fd797d217e93" Allow TyVars in TcTypes Up to now we've had a rule that a TyVar can't apppear in a type seen by the type checker; they should all be TcTyVars. But: a) With -XTypeInType it becomes much harder to exclude them; see Note [TcTyVars in the typechecker] in TcType. b) It's unnecessary to exculde them; instead we can just treat a TyVar just like vanillaSkolemTv. This is what was causing an ASSERT error in indexed-types/should_fail/T12041, reported in Trac #12826. That patch allows a TyVar in a TcType. The most significant change is to make Var.tcTyVarDetails return vanillaSkolemTv. In fact it already did, but (a) it was not documented, and (b) we never exploited it. Now we rely on it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 11:30:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 11:30:26 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.bb859c8d94fb91fe2e50874ae4641d11@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1eec1f21268af907f59b5d5c071a9a25de7369c7/ghc" 1eec1f21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1eec1f21268af907f59b5d5c071a9a25de7369c7" Another major constraint-solver refactoring This patch takes further my refactoring of the constraint solver, which I've been doing over the last couple of months in consultation with Richard. It fixes a number of tricky bugs that made the constraint solver actually go into a loop, including Trac #12526 Trac #12444 Trac #12538 The main changes are these * Flatten unification variables (fmvs/fuvs) appear on the LHS of a tvar/tyvar equality; thus fmv ~ alpha and not alpha ~ fmv See Note [Put flatten unification variables on the left] in TcUnify. This is implemented by TcUnify.swapOverTyVars. * Don't reduce a "loopy" CFunEqCan where the fsk appears on the LHS: F t1 .. tn ~ fsk where 'fsk' is free in t1..tn. See Note [FunEq occurs-check principle] in TcInteract This neatly stops some infinite loops that people reported; and it allows us to delete some crufty code in reduce_top_fun_eq. And it appears to be no loss whatsoever. As well as fixing loops, ContextStack2 and T5837 both terminate when they didn't before. * Previously we generated "derived shadow" constraints from Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly generate a derived shadow from the same Wanted. A big change in this patch is to have two kinds of Wanteds: [WD] behaves like a pair of a Wanted and a Derived [W] behaves like a Wanted only See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh field of a Wanted. This turned out to be a lot simpler. A [WD] gets split into a [W] and a [D] in TcSMonad.maybeEmitShaodow. See TcSMonad Note [The improvement story and derived shadows] * Rather than have a separate inert_model in the InertCans, I've put the derived equalities back into inert_eqs. We weren't gaining anything from a separate field. * Previously we had a mode for the constraint solver in which it would more aggressively solve Derived constraints; it was used for simplifying the context of a 'deriving' clause, or a 'default' delcaration, for example. But the complexity wasn't worth it; now I just make proper Wanted constraints. See TcMType.cloneWC * Don't generate injectivity improvement for Givens; see Note [No FunEq improvement for Givens] in TcInteract * solveSimpleWanteds leaves the insolubles in-place rather than returning them. Simpler. I also did lots of work on comments, including fixing Trac #12821. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 11:30:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 11:30:26 -0000 Subject: [GHC] #12538: Incorrect usage of overlapping instances and data families sends GHC into loop In-Reply-To: <043.73b9606c82869f13ef2cf5bbad585344@haskell.org> References: <043.73b9606c82869f13ef2cf5bbad585344@haskell.org> Message-ID: <058.2ba80dccb213713bb531013aa71e1536@haskell.org> #12538: Incorrect usage of overlapping instances and data families sends GHC into loop -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1eec1f21268af907f59b5d5c071a9a25de7369c7/ghc" 1eec1f21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1eec1f21268af907f59b5d5c071a9a25de7369c7" Another major constraint-solver refactoring This patch takes further my refactoring of the constraint solver, which I've been doing over the last couple of months in consultation with Richard. It fixes a number of tricky bugs that made the constraint solver actually go into a loop, including Trac #12526 Trac #12444 Trac #12538 The main changes are these * Flatten unification variables (fmvs/fuvs) appear on the LHS of a tvar/tyvar equality; thus fmv ~ alpha and not alpha ~ fmv See Note [Put flatten unification variables on the left] in TcUnify. This is implemented by TcUnify.swapOverTyVars. * Don't reduce a "loopy" CFunEqCan where the fsk appears on the LHS: F t1 .. tn ~ fsk where 'fsk' is free in t1..tn. See Note [FunEq occurs-check principle] in TcInteract This neatly stops some infinite loops that people reported; and it allows us to delete some crufty code in reduce_top_fun_eq. And it appears to be no loss whatsoever. As well as fixing loops, ContextStack2 and T5837 both terminate when they didn't before. * Previously we generated "derived shadow" constraints from Wanteds, but we could (and sometimes did; Trac #xxxx) repeatedly generate a derived shadow from the same Wanted. A big change in this patch is to have two kinds of Wanteds: [WD] behaves like a pair of a Wanted and a Derived [W] behaves like a Wanted only See CtFlavour and ShadowInfo in TcRnTypes, and the ctev_nosh field of a Wanted. This turned out to be a lot simpler. A [WD] gets split into a [W] and a [D] in TcSMonad.maybeEmitShaodow. See TcSMonad Note [The improvement story and derived shadows] * Rather than have a separate inert_model in the InertCans, I've put the derived equalities back into inert_eqs. We weren't gaining anything from a separate field. * Previously we had a mode for the constraint solver in which it would more aggressively solve Derived constraints; it was used for simplifying the context of a 'deriving' clause, or a 'default' delcaration, for example. But the complexity wasn't worth it; now I just make proper Wanted constraints. See TcMType.cloneWC * Don't generate injectivity improvement for Givens; see Note [No FunEq improvement for Givens] in TcInteract * solveSimpleWanteds leaves the insolubles in-place rather than returning them. Simpler. I also did lots of work on comments, including fixing Trac #12821. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 12:00:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 12:00:15 -0000 Subject: [GHC] #12877: Constant propagation with basic unboxed arithmetic instructions In-Reply-To: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> References: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> Message-ID: <060.5abd9e915a45a771c23d32808959cd45@haskell.org> #12877: Constant propagation with basic unboxed arithmetic instructions -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * Attachment "Variant.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 12:01:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 12:01:33 -0000 Subject: [GHC] #12877: Constant propagation with basic unboxed arithmetic instructions In-Reply-To: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> References: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> Message-ID: <060.870334a7e4aa1fe1bc060cf6c7a1153c@haskell.org> #12877: Constant propagation with basic unboxed arithmetic instructions -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 12:05:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 12:05:27 -0000 Subject: [GHC] #12877: Constant propagation with basic unboxed arithmetic instructions In-Reply-To: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> References: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> Message-ID: <060.5c798653d3bb7297f76fa9ace5185c42@haskell.org> #12877: Constant propagation with basic unboxed arithmetic instructions -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * owner: => hsyl20 Comment: I have attached a small reproducing example. I have a patch for GHC to handle this specific case but I will extend it to other cases before publishing it for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 12:16:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 12:16:20 -0000 Subject: [GHC] #12538: Incorrect usage of overlapping instances and data families sends GHC into loop In-Reply-To: <043.73b9606c82869f13ef2cf5bbad585344@haskell.org> References: <043.73b9606c82869f13ef2cf5bbad585344@haskell.org> Message-ID: <058.6830747a978f0d4280de6815be028b26@haskell.org> #12538: Incorrect usage of overlapping instances and data families sends GHC into loop -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T12538 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_compile/T12538 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 12:16:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 12:16:58 -0000 Subject: [GHC] #12526: regression in type inference with respect to type families In-Reply-To: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> References: <046.b9c59022f1ecf69581e2ddffe412ed95@haskell.org> Message-ID: <061.67938a055e940bd416cdf1f6d8679213@haskell.org> #12526: regression in type inference with respect to type families -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T12526 Blocked By: | Blocking: Related Tickets: #10634 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T12526 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 12:17:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 12:17:39 -0000 Subject: [GHC] #12444: Regression: panic! on inaccessible code with constraint In-Reply-To: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> References: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> Message-ID: <060.210db9a5efa3a9b08e55c4c4f8a34145@haskell.org> #12444: Regression: panic! on inaccessible code with constraint -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | polykinds/T12444 Blocked By: | Blocking: Related Tickets: #12526 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T12444 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 12:18:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 12:18:24 -0000 Subject: [GHC] #12821: Find the incredible vanishing [The improvement story] In-Reply-To: <046.8f1c0172fb0349cdea42e58509937ad2@haskell.org> References: <046.8f1c0172fb0349cdea42e58509937ad2@haskell.org> Message-ID: <061.a9254240eb91eb5c3dbb9a073c757287@haskell.org> #12821: Find the incredible vanishing [The improvement story] -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: See `Note [The improvement story and derived shadows]` in `TcSMonad`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 12:19:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 12:19:17 -0000 Subject: [GHC] #12826: TyVar ASSERT failure in type family checking: T12041 In-Reply-To: <046.9d0fa2858f11e126141a89fb401b8d81@haskell.org> References: <046.9d0fa2858f11e126141a89fb401b8d81@haskell.org> Message-ID: <061.4a935a98a2bd3837d2dfd38f4d16cece@haskell.org> #12826: TyVar ASSERT failure in type family checking: T12041 -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Fixed. T12041 now works even with `-DEEBUG`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 12:56:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 12:56:49 -0000 Subject: [GHC] #12877: Constant propagation with basic unboxed arithmetic instructions In-Reply-To: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> References: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> Message-ID: <060.d8b3de7132f59478abb7e11a1db26437@haskell.org> #12877: Constant propagation with basic unboxed arithmetic instructions -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. I'm all for it. A good place to look is `SimplUtils.mkCase`. One thing it does ("Merge Nested Cases") is very similar to what you have. GHC does this: {{{ case x of A -> ea DEFAULT -> case x of B -> eb C -> ec ===> case x of A -> ea B -> eb C -> ec }}} But as you point out, if you just do your second transformation (after "if I'm not mistaken...") then the ''existing'' case-merging stuff will do the rest. And I think you might be able do to your second transformation just by adding a case to `SimplUtils.mkCase`. Yell if you need help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 15:00:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 15:00:07 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.544f5f71e5ffd363036833906085c76b@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Thanks, that also works, and as you say is semantically cleaner. I did in fact use `newMetaTyVarsX`; in fact I had to write it since it didn't exist, but it is straightforward. {{{ newMetaTyVarsX :: TCvSubst -> [TyVar] -> TcM (TCvSubst, [TcTyVar]) -- Just like newMetaTyVars, but start with an existing substitution. newMetaTyVarsX subst = mapAccumLM newMetaTyVarX subst }}} I'll post the code for review in the near future. Note that I haven't handled `tc_infer_args`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 16:32:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 16:32:12 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.6e6fba910ad3d9eca4317e329d93b117@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1676, Wiki Page: | Phab:D1795 -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: I'm re-opening this because compilation still takes a ridiculously long time (minutes) and memory (6.7G allocated). Almost all of this is in the pattern-match checking. It can't be right! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 16:33:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 16:33:54 -0000 Subject: [GHC] #12686: Attempt to promote a value to a type results in an internal error In-Reply-To: <046.3d98ed3f59b125593ac3e939cbafbd11@haskell.org> References: <046.3d98ed3f59b125593ac3e939cbafbd11@haskell.org> Message-ID: <061.dc474d2d7c8aa1f4354ea9da2f94a886@haskell.org> #12686: Attempt to promote a value to a type results in an internal error -------------------------------------+------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c1b4b76931a58c59e5b269477e38db659cf7aea8/ghc" c1b4b76/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1b4b76931a58c59e5b269477e38db659cf7aea8" Fix a name-space problem with promotion Trac #12686 showed that we were allowing a term variable into a type, by promotion. I chose to squash this in the renamer. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 16:40:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 16:40:34 -0000 Subject: [GHC] #12686: Attempt to promote a value to a type results in an internal error In-Reply-To: <046.3d98ed3f59b125593ac3e939cbafbd11@haskell.org> References: <046.3d98ed3f59b125593ac3e939cbafbd11@haskell.org> Message-ID: <061.19380733c773a575d9785b3488988006@haskell.org> #12686: Attempt to promote a value to a type results in an internal error -------------------------------------+------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T12686 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => rename/should_fail/T12686 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 17:47:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 17:47:09 -0000 Subject: [GHC] #12844: No Skolem Info with PartialTypeSignatures In-Reply-To: <047.2c635f7d8f9e46b10ebe3b29b92a477c@haskell.org> References: <047.2c635f7d8f9e46b10ebe3b29b92a477c@haskell.org> Message-ID: <062.8e20037c4270ad4da95d5f63ca8ba218@haskell.org> #12844: No Skolem Info with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1bfff60fc57cd564382b86bdfb1f2764ca15d44f/ghc" 1bfff60f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1bfff60fc57cd564382b86bdfb1f2764ca15d44f" Fix inference of partial signatures When we had f :: ( _ ) => blah we were failing to call growThetaTyVars, as we do in the no-type-signature case, and that meant that we weren't generalising over the right type variables. I'm quite surprised this didn't cause problems earlier. Anyway Trac #12844 showed it up and this patch fixes it }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 17:47:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 17:47:09 -0000 Subject: [GHC] #12845: -XPartialTypeSignatures results in unbound variables In-Reply-To: <047.fe1a80c8e93b6a208be7bf5baa2818e3@haskell.org> References: <047.fe1a80c8e93b6a208be7bf5baa2818e3@haskell.org> Message-ID: <062.ff11fef3f30de454c7a63f7032c4883d@haskell.org> #12845: -XPartialTypeSignatures results in unbound variables -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"83a952d14012ff4706a366a3155712f8caa69ead/ghc" 83a952d1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83a952d14012ff4706a366a3155712f8caa69ead" Test Trac #12845 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 17:47:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 17:47:09 -0000 Subject: [GHC] #12867: Internal error while typechecking invalid program In-Reply-To: <046.2ab7f73f469c3c9979cc29eb99ddf47e@haskell.org> References: <046.2ab7f73f469c3c9979cc29eb99ddf47e@haskell.org> Message-ID: <061.9ce5ddaef3de58db942ae07f51fbc2d3@haskell.org> #12867: Internal error while typechecking invalid program -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f0f468262d8b3932de0ce79f4fd98fecf51a62a3/ghc" f0f4682/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f0f468262d8b3932de0ce79f4fd98fecf51a62a3" Test Trac #12867 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 17:47:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 17:47:09 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.d2f370682e131813a8d93e358c12c797@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"eb55ec2941239dee05afc6be818b129efe51660e/ghc" eb55ec2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb55ec2941239dee05afc6be818b129efe51660e" Refactor functional dependencies a bit * Rename CoAxiom.Eqn = Pair Type to TypeEqn, and use it for fundeps * Use the FunDepEqn for injectivity, which lets us share a bit more code, and (more important) brain cells * When generating fundeps, take the max depth of the two constraints. This aimed at tackling the strange loop in Trac #12860, but there is more to come for that. * Improve pretty-printing with -ddump-tc-trace }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 17:47:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 17:47:09 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.96a0d1f045fb7130a5bae5a80c4224c3@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f8c966c70bf4e6ca7482658d4eaca2dae367213f/ghc" f8c966c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8c966c70bf4e6ca7482658d4eaca2dae367213f" Be a bit more selective about improvement This patch makes [W] constraints not participate in improvement. See Note [Do not do improvement for WOnly] in TcSMonad. Removes some senseless work duplication in some cases (notably Trac #12860); should not change behaviour. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 17:49:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 17:49:49 -0000 Subject: [GHC] #12845: -XPartialTypeSignatures results in unbound variables In-Reply-To: <047.fe1a80c8e93b6a208be7bf5baa2818e3@haskell.org> References: <047.fe1a80c8e93b6a208be7bf5baa2818e3@haskell.org> Message-ID: <062.cc783454456a38b02813f337f72027ce@haskell.org> #12845: -XPartialTypeSignatures results in unbound variables -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: partial- valid program | sigs/should_compile/T12845 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => partial-sigs/should_compile/T12845 * resolution: => fixed Comment: I don't quite know what fixed this, and I suspect it'll be hard to get into 8.0, so I'll just close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 17:51:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 17:51:18 -0000 Subject: [GHC] #12844: No Skolem Info with PartialTypeSignatures In-Reply-To: <047.2c635f7d8f9e46b10ebe3b29b92a477c@haskell.org> References: <047.2c635f7d8f9e46b10ebe3b29b92a477c@haskell.org> Message-ID: <062.0cd03c54d417932cd406f5feeb0b1cf3@haskell.org> #12844: No Skolem Info with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: partial- crash or panic | sigs/should_compile/T12844 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => partial-sigs/should_compile/T12844 Comment: This fix is fairly simple and might be worth merging to 8.0. Try, anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 17:52:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 17:52:21 -0000 Subject: [GHC] #12867: Internal error while typechecking invalid program In-Reply-To: <046.2ab7f73f469c3c9979cc29eb99ddf47e@haskell.org> References: <046.2ab7f73f469c3c9979cc29eb99ddf47e@haskell.org> Message-ID: <061.4a41f1f714add2f3530ba06e0036cecf@haskell.org> #12867: Internal error while typechecking invalid program -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T12867 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_fail/T12867 * resolution: => fixed Comment: I'm just going to mark this as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 17:55:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 17:55:00 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.92aeabde112f398566c51da5bd1343e1@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well my efforts thus far have at least succeeded in getting an error message very promptly {{{ T12860.hs:12:13: error: • Reduction stack overflow; size = 201 When simplifying the following type: C y (Foo x) Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • When deriving the instance for (C y (Foo x)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 18:24:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 18:24:31 -0000 Subject: [GHC] #12876: Appreciate your work! In-Reply-To: <044.785bafe117eef99e54266b96b3ef8e4e@haskell.org> References: <044.785bafe117eef99e54266b96b3ef8e4e@haskell.org> Message-ID: <059.5ff48e1fc37305a291ca393c52dbd640@haskell.org> #12876: Appreciate your work! -------------------------------------+------------------------------------- Reporter: deech | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by deech): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 19:31:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 19:31:10 -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.013da681df43cba90411c6e5d12750d2@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by dobenour): I think we can deprecate it on other systems too, except (possibly) OS X (which I believe bundles Perl with the OS). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 19:34:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 19:34:44 -0000 Subject: [GHC] #12878: Use gold linker by default if available on ELF systems Message-ID: <047.c7ddb643b4ab18bdba2072ff5764699e@haskell.org> #12878: Use gold linker by default if available on ELF systems -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Driver | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `ld.gold` is both faster and less buggy than `ld.bfd`, but only works on ELF. On ELF systems, we should thus prefer `ld.gold` when it is installed, even when `ld.bfd` is supported (as it is on x86). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 19:53:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 19:53:27 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly In-Reply-To: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> References: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> Message-ID: <062.d3ecf47a647d5a3f01470c61054f492d@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * component: Compiler => Driver Comment: nomeata: yes, this happens even if `-a.hs` exists. This bug probably is not triggered often because there are few legitimate reasons to have a leading dash in an executable name, but it is still a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 21:13:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 21:13:02 -0000 Subject: [GHC] #10614: Show constraints in ``Found hole...'' In-Reply-To: <047.e629c8600a92660c55de2127511a14cd@haskell.org> References: <047.e629c8600a92660c55de2127511a14cd@haskell.org> Message-ID: <062.b669bcc48f60dae9600230a5318d048e@haskell.org> #10614: Show constraints in ``Found hole...'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zyla): I can work on this. If I understand correctly, the needed information is in `ic_given` of `Implication` in `cec_encl` of the `ReportErrCtxt`. Is this right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 22:13:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 22:13:25 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.b07a3f4efd2e486767418b574c587369@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): I've posted my change for review: https://phabricator.haskell.org/D2757 As noted there, this does not fix the `tc_infer_args` problem so we'll either have to defer this checkin until that's fixed or change the `substTy` in `new_meta_tv_x` back to `substTyUnchecked` and file a new bug for `tc_infer_args`. I wanted to make sure my other changes were okay, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 22:20:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 22:20:34 -0000 Subject: [GHC] #10614: Show constraints in ``Found hole...'' In-Reply-To: <047.e629c8600a92660c55de2127511a14cd@haskell.org> References: <047.e629c8600a92660c55de2127511a14cd@haskell.org> Message-ID: <062.5ad8ce2f2b51a355de0ad965873542d9@haskell.org> #10614: Show constraints in ``Found hole...'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > If I understand correctly, the needed information is in ic_given of Implication in cec_encl of the ReportErrCtxt Yes, exactly! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 25 22:30:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 25 Nov 2016 22:30:01 -0000 Subject: [GHC] #11158: Combine exprIsTrivial and cpe_ExprIsTrivial In-Reply-To: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> References: <046.4f8a76b38a90ffce5029325839aa4f94@haskell.org> Message-ID: <061.2f3aae7e1dc9f3ee1f282b83a1c31f1c@haskell.org> #11158: Combine exprIsTrivial and cpe_ExprIsTrivial -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12757 | Differential Rev(s): Phab:D2666 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #12757 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 05:32:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 05:32:39 -0000 Subject: [GHC] #12100: GHC 8.0.1 build segmentation fault in haddock In-Reply-To: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> References: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> Message-ID: <062.3c50e4b8de1223873963a53da4d360a5@haskell.org> #12100: GHC 8.0.1 build segmentation fault in haddock -------------------------------------+------------------------------------- Reporter: ilovezfs | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11744, #11951 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ilovezfs): https://gist.github.com/ilovezfs/a264b673a046f3d7b51d54f6479425c4 Does that help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 06:03:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 06:03:08 -0000 Subject: [GHC] #12879: (xs -> xs) wrongly suggests TypeApplications Message-ID: <051.16598209ccbf8290d8f46e992fbe8e53@haskell.org> #12879: (xs -> xs) wrongly suggests TypeApplications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `(xs -> xs)` and `map (xs -> xs)` wrongly suggest `TypeApplications` {{{ > map (xs -> xs) :38:6: error: Pattern syntax in expression context: xs -> xs Did you mean to enable TypeApplications? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 09:56:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 09:56:46 -0000 Subject: [GHC] #12880: Update to Cabal-1.24.1.1 Message-ID: <042.fed2f725f41f6702d6c9570271c8e9a1@haskell.org> #12880: Update to Cabal-1.24.1.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.2 Component: libraries | Version: 8.0.2-rc1 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a tracking ticket to make sure it we don't forget about this. See https://github.com/haskell/cabal/issues/4123 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 09:57:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 09:57:18 -0000 Subject: [GHC] #12100: GHC 8.0.1 build segmentation fault in haddock In-Reply-To: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> References: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> Message-ID: <062.ec63298235004e830b1ebe4b37545324@haskell.org> #12100: GHC 8.0.1 build segmentation fault in haddock -------------------------------------+------------------------------------- Reporter: ilovezfs | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11744, #11951 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pggiarrusso): It's a start, since it gives the crashing position (`initGcThreads + 674 (GC.c:818)`) and suggests the runtime system is possibly (though not necessarily) involved. However, it seems the failing binary is not literally 8.0.1, so the line number might be out of sync. What's the source of the `ghc8.0.1.20161117` you're using? A stacktrace could be a bit better. Below, what I can analyze out of this dump, which isn't that much really. I suspect we'd need an actual coredump. https://github.com/ghc/ghc/blob/ghc-8.0.1-release/rts/sm/GC.c#L818 is an unlikely source of a crash. (But my best guess, based on a snapshot of ghc-8.0 with that date, suggests the affected code is https://github.com/ghc/ghc/blob/58d9f9b7a7f1b4d2c94183b9b9428983e7c83fe9/rts/sm/GC.c#L818, which is similarly surprising). If either is accurate, we have a segfault when writing *in the middle* of `gen_workspace *ws`. If the source tree matches commit commit 58d9f9b7a7f1b4d2c94183b9b9428983e7c83fe9, given the type definition in https://github.com/ghc/ghc/blob/58d9f9b7a7f1b4d2c94183b9b9428983e7c83fe9/rts/sm/GCThread.h#L79-L90, the crash is when writing to field `ws->todo_large_objects`, which starts 64 bytes after the start of `ws`. `ws` is 64-bytes aligned, so this is plausible (if `ws->todo_large_objects` points to the beginning of a page). Strangely, no register in the dump has the right alignment to be such a `ws`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 11:38:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 11:38:47 -0000 Subject: [GHC] #12100: GHC 8.0.1 build segmentation fault in haddock In-Reply-To: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> References: <047.3b49389b21e0a29c007c4ece13b83eaf@haskell.org> Message-ID: <062.2bc50085417ee48f1c713fee532354ca@haskell.org> #12100: GHC 8.0.1 build segmentation fault in haddock -------------------------------------+------------------------------------- Reporter: ilovezfs | Owner: Type: bug | Status: infoneeded Priority: highest | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #11744, #11951 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ilovezfs): >What's the source of the ghc8.0.1.20161117 you're using http://downloads.haskell.org/~ghc/8.0.2-rc1/ghc-8.0.1.20161117-src.tar.xz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 15:20:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 15:20:55 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations Message-ID: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `quickcheck-combinators-0.0.1` fails to build with GHC 8.0.2-rc1 (but does build with GHC 8.0.1) due to this issue. Here is a simplified example: {{{#!hs {-# LANGUAGE FlexibleInstances #-} module Bug where class Arbitrary a where shrink :: a -> [a] shrink _ = [] instance Arbitrary a instance Arbitrary Int }}} Is this expected? If so, we should make a note of this in the 8.0.2 release notes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 15:22:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 15:22:11 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.3bf915f9e24b796ee77594a3961dedcc@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It should be noted that if you add explicit `OVERLAP*` annotations: {{{#!hs {-# LANGUAGE FlexibleInstances #-} module Bug where class Arbitrary a where shrink :: a -> [a] shrink _ = [] instance {-# OVERLAPPABLE #-} Arbitrary a instance {-# OVERLAPPING #-} Arbitrary Int }}} Then it will compile again, so there's at least a simple workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 16:43:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 16:43:01 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.20ad9917ef6d49afbfadca926a8d1c72@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I did a run of Stackage with GHC 8.0.2-rc1 recently, and here are all of the libraries which fail to install because of this issue: * `consul-haskell-0.3` * `ede-0.2.8.5` * `HaRe-0.8.3.0` * `hbayes-0.5.2` * `quickcheck-combinators-0.0.1` * `rethinkdb-2.2.0.7` * `vectortiles-1.2.0` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 17:19:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 17:19:18 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.75e342e3a84a56e9ab01b99f475e71ea@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) * milestone: => 8.0.2 Comment: Simon, this commit ( https://ghc.haskell.org/trac/ghc/changeset/d2958bd08a049b61941f078e51809c7e63bc3354/ghc ) once again appears to be responsible. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 18:55:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 18:55:42 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.09772e827823087b90bb950f0e2188ce@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 18:56:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 18:56:39 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.5a801ef5a8c3805af61e17b1fec9a4aa@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 26 19:16:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 26 Nov 2016 19:16:06 -0000 Subject: [GHC] #9504: LLVM backend TBAA is too aggressive In-Reply-To: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> References: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> Message-ID: <062.1de37673f799d7d9b9da4bb613677d56@haskell.org> #9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | 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: 9308 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 08:56:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 08:56:19 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.31bfaa7e3b423291dc58492557883d71@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): #12753 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by robinbb): * cc: robinbb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 08:59:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 08:59:42 -0000 Subject: [GHC] #12753: GHCi/Template Haskell: Don't panic on linker errors. In-Reply-To: <047.d3ab0d524e9cdf7f9d5712b3903db94c@haskell.org> References: <047.d3ab0d524e9cdf7f9d5712b3903db94c@haskell.org> Message-ID: <062.6bf3935e4d4b88db3f96fe4ad307001b@haskell.org> #12753: GHCi/Template Haskell: Don't panic on linker errors. -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #11042 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by robinbb): * cc: robinbb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 12:06:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 12:06:52 -0000 Subject: [GHC] #12004: Windows unexpected failures In-Reply-To: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> References: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> Message-ID: <060.d79e2594469d4093bebaad8ee58548d9@haskell.org> #12004: Windows unexpected failures -------------------------------------+------------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | Phab:D2759 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: Phab:D2684 => Phab:D2684 Phab:D2759 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 12:07:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 12:07:34 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.378628a63cc14350dc260aafcd756760@haskell.org> #12725: T7037 is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | Phab:D2759 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: Phab:D2684 => Phab:D2684 Phab:D2759 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 14:44:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 14:44:41 -0000 Subject: [GHC] #12882: Unexpected constraint when using ExistentialQuantification Message-ID: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> #12882: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello! Consider this simple code: {{{ data Elem t = Typeable t => Elem Int tst1 :: forall a. Elem a -> TypeRep tst1 (Elem _) = typeRep (Proxy :: Proxy a) }}} It works and it should work. `Elem` is created only to be sure that if we've got a value of type `Elem t` we don't have to check that `t` is `Typeable`. By the way, exystential newtypes would be so awesome in GHC! And now a strange thing. If we create another function: {{{ tst2 :: forall a. Elem a -> TypeRep tst2 _ = typeRep (Proxy :: Proxy a) }}} GHC throws error that there is no `Typeable a` constraint. The only difference between `tst1` and `tst2` is different pattern binding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 14:45:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 14:45:35 -0000 Subject: [GHC] #12883: Unexpected constraint when using ExistentialQuantification Message-ID: <046.27a1447251529f6cfc8fe416942d437f@haskell.org> #12883: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello! Consider this simple code: {{{ data Elem t = Typeable t => Elem Int tst1 :: forall a. Elem a -> TypeRep tst1 (Elem _) = typeRep (Proxy :: Proxy a) }}} It works and it should work. `Elem` is created only to be sure that if we've got a value of type `Elem t` we don't have to check that `t` is `Typeable`. By the way, exystential newtypes would be so awesome in GHC! And now a strange thing. If we create another function: {{{ tst2 :: forall a. Elem a -> TypeRep tst2 _ = typeRep (Proxy :: Proxy a) }}} GHC throws error that there is no `Typeable a` constraint. The only difference between `tst1` and `tst2` is different pattern binding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 14:47:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 14:47:31 -0000 Subject: [GHC] #12883: Unexpected constraint when using ExistentialQuantification In-Reply-To: <046.27a1447251529f6cfc8fe416942d437f@haskell.org> References: <046.27a1447251529f6cfc8fe416942d437f@haskell.org> Message-ID: <061.3565f18448e2d93c2a0ad7210bc04d60@haskell.org> #12883: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danilo2): * status: new => closed * resolution: => duplicate Comment: Hmm it seams that I posted it twice. The site was loading very long and I've refreshed it. After -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 14:51:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 14:51:17 -0000 Subject: [GHC] #12882: Unexpected constraint when using ExistentialQuantification In-Reply-To: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> References: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> Message-ID: <061.119eb6ce028bb47c796f6cdd6825ccaf@haskell.org> #12882: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Can you paste your whole file please? It isn't clear which extensions you have turned on to get the first example to compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 14:53:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 14:53:18 -0000 Subject: [GHC] #12882: Unexpected constraint when using ExistentialQuantification In-Reply-To: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> References: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> Message-ID: <061.35a2d16a326ff565960a843e2523c217@haskell.org> #12882: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: high => normal * status: new => closed * resolution: => invalid Comment: > The only difference between `tst1` and `tst2` is different pattern binding. Different forms of pattern binding have different semantics. Here the pattern match is required to ensure that the argument was actually built with the `Elem` constructor, so that it contains a `Typeable a` dictionary. Since `tst2` ignores its argument, it should be fine to write `tst2 undefined`, but then where does the `Typeable` instance come from? In contrast, `tst1 undefined` clearly diverges. For the same reason, it doesn't make sense here to make `data Elem t = Typeable t => Elem Int` into a newtype, since it holds two pieces of data: a `Typeable t` dictionary and an `Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 14:56:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 14:56:17 -0000 Subject: [GHC] #12882: Unexpected constraint when using ExistentialQuantification In-Reply-To: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> References: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> Message-ID: <061.91aa5b6f4aa9b5f415c767cb3115d4ec@haskell.org> #12882: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): OK - I got it to compile now, I was missing scoped type variables. Here is the more usual way to write your data type. {{{ {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE GADTs #-} import Data.Typeable data Elem t where Elem :: Typeable t => Int -> Elem t tst1 :: forall a. Elem a -> TypeRep tst1 (Elem _) = typeRep (Proxy :: Proxy a) }}} Then it is clear why you must pattern match on `Elem` in order to discover that you have the `Typeable` constraint. You could have another constructor which doesn't bind it. For example, {{{ data Elem t where Elem :: Typeable t => Int -> Elem t Elem2 :: t -> Elem t }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 15:03:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 15:03:07 -0000 Subject: [GHC] #12882: Unexpected constraint when using ExistentialQuantification In-Reply-To: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> References: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> Message-ID: <061.661ced869c667d3b18fa723e5bae34c0@haskell.org> #12882: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): rwbarton, mpickering: very interesting, thanks for clarification! By the way, is there any other way to create `Elem`-like newtype, which will just ensure GHC that this constraint would be meet? I dont want to pass the dictionary in runtime. I just want to tell the type system that if I ever created `Elem t`, `t` is Typeable. The reason behind it is that I dont want constraint on `t` to appear on functions processing `Elem t`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 15:40:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 15:40:44 -0000 Subject: [GHC] #12882: Unexpected constraint when using ExistentialQuantification In-Reply-To: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> References: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> Message-ID: <061.f8664d345c24b8a14261b70ffc2ce9ce@haskell.org> #12882: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): But presumably the reason you want the type checker to know `t` is an instance of `Typeable` is in order to use functions which use the constraint, like `typeRep`. And the `Typeable t` dictionary is exactly what will be used at runtime to implement that function. So, there is no getting around the need for the dictionary, either passed into your function as a constraint `Typeable t =>` or unpacked from the data as in `tst1`. (I'm a bit confused how you think this could work at runtime. Maybe you are imagining that a function receives information about its type parameters at runtime and could use that data to look up the needed `Typeable` instance in some global table? Actually, there is no type data at runtime aside from what you explicitly introduce in the form of `Typeable` contexts nor any table of instances. And even `Typeable` is not that special, and could be reimplemented to some extent by a used-defined class.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 15:53:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 15:53:57 -0000 Subject: [GHC] #12882: Unexpected constraint when using ExistentialQuantification In-Reply-To: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> References: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> Message-ID: <061.5eae081205358bc2cd364fb182de2e7e@haskell.org> #12882: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): rwbarton: hmm, I dont know so deeply how GHC solves the things under the hood, but I imagine GHC could easily allow such code: {{{ class Foo a where foo :: a -> Int newtype ImplicitFoo a = Foo a => ImplicitFoo a getFoo :: ImplicitFoo a -> Int getFoo (ImplicitFoo a) = foo a }}} The constraint in the newtype just tells that if `ImplicitFoo` was ever constructed by somebody, the constraint was already met, so there is no need to check it again and pass along functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 16:07:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 16:07:05 -0000 Subject: [GHC] #12882: Unexpected constraint when using ExistentialQuantification In-Reply-To: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> References: <046.1306f02c7d95ae813b2fa1dc102e886f@haskell.org> Message-ID: <061.04f7f74d2dcf812e31ae86c5274db866@haskell.org> #12882: Unexpected constraint when using ExistentialQuantification -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well there is no problem if you write `data` instead of `newtype`, above. But of course the `Foo a` dictionary must be stored within an `ImplicitFoo a`, so that it can provide the implementation of `foo` at runtime. You cannot think of the constraint `Foo a` as a box to be checked off to satisfy some bureaucratic type checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 17:42:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 17:42:34 -0000 Subject: [GHC] #12884: Parsing of literate files fails because of special character (#) Message-ID: <044.d42af63ce3801b10e87e7a8aaba2cbde@haskell.org> #12884: Parsing of literate files fails because of special character (#) -------------------------------------+------------------------------------- Reporter: bales | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: literate | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A sharp sign (#) in the documentation part of a literate haskell file causes the parser to fail. As I understand it, any line that doesn't start with a greater-than sign should be ignored. {{{#!hs #+ > module Empty where }}} The previous code leads to the following error: with ghc-7.8.3: Bug.lhs:1:2: lexical error at character '+'[[BR]] with ghc-8.0.1: Bug.lhs:1:1: error: parse error on input ‘#+’ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 17:44:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 17:44:23 -0000 Subject: [GHC] #12884: Parsing of literate files fails because of special character (#) In-Reply-To: <044.d42af63ce3801b10e87e7a8aaba2cbde@haskell.org> References: <044.d42af63ce3801b10e87e7a8aaba2cbde@haskell.org> Message-ID: <059.9da7e8956444f205081ed36958b0f914@haskell.org> #12884: Parsing of literate files fails because of special character (#) -------------------------------------+------------------------------------- Reporter: bales | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: literate Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bales: @@ -4,0 +4,2 @@ + Note: this error is only triggered when the sharp is the first character + on the line. New description: A sharp sign (#) in the documentation part of a literate haskell file causes the parser to fail. As I understand it, any line that doesn't start with a greater-than sign should be ignored. Note: this error is only triggered when the sharp is the first character on the line. {{{#!hs #+ > module Empty where }}} The previous code leads to the following error: with ghc-7.8.3: Bug.lhs:1:2: lexical error at character '+'[[BR]] with ghc-8.0.1: Bug.lhs:1:1: error: parse error on input ‘#+’ -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 19:48:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 19:48:31 -0000 Subject: [GHC] #12885: "too many iterations" causes constraint solving issue. Message-ID: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> #12885: "too many iterations" causes constraint solving issue. -------------------------------------+------------------------------------- Reporter: judahj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following file compiled fine with ghc-7.10, but fails in ghc-8.0.2-rc1 (as well as ghc-8.0.1). This is a simplified version of a compilation issue with ghc-8 and https://github.com/tensorflow/haskell. It seems similar to #12175, but even though that was fixed in ghc-8.0.2-rc1, the below code still doesn't compile. {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module ConstraintTest where import Data.Int import Data.Word import GHC.Exts (Constraint) import Lens.Family2 ((.~), (&), Lens') import Lens.Family2.Unchecked (lens) class MyType a where instance MyType Int8 instance MyType Int16 instance MyType Int32 instance MyType Int64 instance MyType Word8 instance MyType Word16 instance MyType Word32 -- Require every element in the list to be an instance of 'MyType'. type family MyTypes (as :: [*]) :: Constraint where MyTypes '[] = () MyTypes (a ': as) = (MyType a, MyTypes as) data Foo = Foo { fooInt :: Int } class Attr a where attr :: Lens' Foo a instance Attr Int where attr = lens fooInt (\f n -> f { fooInt = n }) test :: MyTypes '[Int8,Int16,Int32,Int64,Word8,Word16,Word32] => Foo test = attr .~ (3 :: Int) $ Foo 0 }}} Compilation error: {{{ tensorflow/tests/ConstraintTest.hs:1:1: error: solveWanteds: too many iterations (limit = 4) Unsolved: WC {wc_simple = [W] hole{a282} :: b_a25A ~ Int (CNonCanonical)} New superclasses found Set limit with -fconstraint-solver-iterations=n; n=0 for no limit }}} Some ways to change the test to make the compilation succeed: - Pass "-fconstraint-solver-iterations=0" to ghc. - Shorten the type-level list in the constraint of `test`. - Replace `Lens.Family2` with `Lens.Micro` from the `microlens` package. I think this is because `Lens.Family2`'s version of (.~) is higher-order than `Lens.Micro`: https://hackage.haskell.org/package/lens-family-1.2.1/docs/Lens- Family2.html#v:.-126- https://hackage.haskell.org/package/microlens-0.4.7.0/docs/Lens- Micro.html#v:.-126- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 20:54:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 20:54:23 -0000 Subject: [GHC] #12886: Proposal for throwLeft and throwLeftIO in Control.Exception Message-ID: <048.20cdb7217c9551470366c48ee53b317a@haskell.org> #12886: Proposal for throwLeft and throwLeftIO in Control.Exception -------------------------------------+------------------------------------- Reporter: yfeldblum | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There already exist some functions to translate between `Maybe` and `Exception`, and between `Either` and `Exception` in the module `Control.Exception`. Given an API like: {{{#!hs data MyException --... instance Exception MyException --... myUsefulFunction :: a -> b -> c -> Either MyException d myUsefulAction :: a -> b -> c -> IO (Either MyException d) }}} It sometimes the case that calling code that cannot sensibly handle `Left` results directly. This proposal is to add standard library functions that let calling code easily to turn `Left` results into thrown runtime exceptions, which might be caught and handled further up the call stack. {{{#!hs throwLeft :: Exception e => Either e a -> a throwLeftIO :: Exception e => Either e a -> IO a }}} Note that examples of functions named `throwLeft` may be found in the wild: https://www.stackage.org/lts-7.10/hoogle?q=throwLeft. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 20:54:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 20:54:41 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.8c7a99f663c0baccc78c83354eff5c4b@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 20:57:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 20:57:13 -0000 Subject: [GHC] #12886: Proposal for throwLeft and throwLeftIO in Control.Exception In-Reply-To: <048.20cdb7217c9551470366c48ee53b317a@haskell.org> References: <048.20cdb7217c9551470366c48ee53b317a@haskell.org> Message-ID: <063.4a693c1d59deb0ad4479101125096edf@haskell.org> #12886: Proposal for throwLeft and throwLeftIO in Control.Exception -------------------------------------+------------------------------------- Reporter: yfeldblum | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by yfeldblum): * Attachment "0001-Add-throwLeft-and-throwLeftIO-to- Control.Exception.patch" added. Implementation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 22:06:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 22:06:12 -0000 Subject: [GHC] #618: Dependency caching in ghc --make In-Reply-To: <047.cb339f4df789645f0d246a4cb70e5f2e@haskell.org> References: <047.cb339f4df789645f0d246a4cb70e5f2e@haskell.org> Message-ID: <062.7310917288498a0887b936becf4b2900@haskell.org> #618: Dependency caching in ghc --make -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Could SQLite be used as the storage backend for the cache? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 22:14:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 22:14:39 -0000 Subject: [GHC] #5567: LLVM: Improve alias analysis / performance In-Reply-To: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> References: <045.d9bd466c3bfd8b5c182f7fd75463d86a@haskell.org> Message-ID: <060.9264af92a4642903f19d2f64cf4f1a75@haskell.org> #5567: LLVM: Improve alias analysis / performance -------------------------------------+------------------------------------- Reporter: dterei | Owner: dterei Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Have the LLVM devs been asked about this? I think that GHC's use of CPS (and its non-use of the C stack) might be one of the problems. LLVM is designed for C-style code and its optimizations might not fire on the IR that GHC generates. I can think of a solution, but it would involve significant changes, both to the compiler and the RTS. The idea is to do a CPS => SSA transform and then lower to LLVM IR from the SSA form. The Haskell stack would become the C stack, with stack switching handled by the assembler code in `StgRun`. LLVM's GC support would be used to generate stack maps to be read by the RTS for GC purposes. Fortunately, I believe that these tasks are relatively independent. I suspect (from what others have said) that an equivalent of LLVM's `mem2reg` for the STG stack is what is needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 22:22:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 22:22:44 -0000 Subject: [GHC] #618: Dependency caching in ghc --make In-Reply-To: <047.cb339f4df789645f0d246a4cb70e5f2e@haskell.org> References: <047.cb339f4df789645f0d246a4cb70e5f2e@haskell.org> Message-ID: <062.c59889edde96cda1a633764ec137c064@haskell.org> #618: Dependency caching in ghc --make -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): dobenour: SQLite, or really any single file database, could be used, but this would change GHC's compilation model to output some extra files besides the files it normally outputs. I'm a little loathe to do this when we ought to be able to just read out the cached dependencies from the interface files we generate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 27 22:59:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 27 Nov 2016 22:59:58 -0000 Subject: [GHC] #12887: Make each RTS header self-contained Message-ID: <047.09675d2d273d8077cba9e874df27d215@haskell.org> #12887: Make each RTS header self-contained -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We should make each header in the RTS self-contained – that is, make sure that it is valid when included on its own. Otherwise, some tools (such as the YouCompleteMe semantic completion system for Vim) report spurious errors when editing header files. (Also, not sure if this belongs here, or as a task on Phabricator) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 00:24:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 00:24:10 -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.db87692484f1bfa5306f1cc66373dcda@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: new Priority: high | Milestone: 8.2.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 Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): as per http://git.haskell.org/ghc.git/commitdiff/fefe02c0324a25a52455a61f7f6e48be6d82d1ab this should be in for 8.0.2 right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 03:09:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 03:09:47 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.ad7dbdab65bd1aa89c8280d121a5475a@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by goldfire): Regardless of anything else: do please file a bug about the `tc_infer_args` problem, so that I have something to put in my queue. Otherwise, this seems to be humming nicely to a conclusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 03:32:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 03:32:39 -0000 Subject: [GHC] #12686: Attempt to promote a value to a type results in an internal error In-Reply-To: <046.3d98ed3f59b125593ac3e939cbafbd11@haskell.org> References: <046.3d98ed3f59b125593ac3e939cbafbd11@haskell.org> Message-ID: <061.9f4376e9e915cc530e9be6731da7817e@haskell.org> #12686: Attempt to promote a value to a type results in an internal error -------------------------------------+------------------------------------- Reporter: johnleo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T12686 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 Simon Peyton Jones ]: > I chose to squash this in the renamer. In contrast, I would choose to squash this by implementing dependent types. :) But that would have taken longer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 05:59:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 05:59:29 -0000 Subject: =?utf-8?b?W0dIQ10gIzEyODg4OiDigJhJZGVudGl0eSBpbnN0YW5jZeKAmTog?= =?utf-8?q?Outputable_SDoc?= Message-ID: <051.d16c20317c8bb02531acee4d18634b76@haskell.org> #12888: ‘Identity instance’: Outputable SDoc -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Is there reason why there isn't an ‘identity instance’¹ for `Outputable`? {{{#!hs class Outputable a where ppr :: a -> SDoc instance Outputabe SDoc where ppr :: SDoc -> SDoc ppr = id }}} A benefit: lets me always use `pprTraceIt :: Outputable a => String -> a -> a`, I know I can use `pprTrace` but I like not having to think about the type of what I'm tracing and neither functions work to debug something like `Either SDoc Name`. ---- ¹ For lack of a better term, something like {{{#!hs class Foo a where foo :: a -> A instance Foo A where foo :: A -> A foo = id @A }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 08:36:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 08:36:51 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.62709b70756058e0b63964146e47702d@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12843 #12675 | Differential Rev(s): #12789 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6ec2304f46c9a5423943c5bf29bd8a8c062b6560/ghc" 6ec2304f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6ec2304f46c9a5423943c5bf29bd8a8c062b6560" Fix an long-standing bug in OccurAnal This bug was beautifully characterised in Trac #12776, which showed a small program for which the inliner went into an infinite loop. Eeek. It turned out to be a genuine and long-standing bug in the occurrence analyer, specifically in the bit that identifies loop breakers. In this line pairs | isEmptyVarSet weak_fvs = reOrderNodes 0 bndr_set weak_fvs tagged_nodes [] | otherwise = loopBreakNodes 0 bndr_set weak_fvs loop_breaker_edges [] the 'tagged_nodes' should be 'loop_breaker_edges'. That's it! The diff looks a lot bigger because I did some work on comments and variable naming, but that's all it is. We were using the wrong set of dependencies! I'm astonished that this bug has not caused more trouble. It dates back to at least 2011 and maybe further. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 08:51:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 08:51:53 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.d7832edf11a9914751aabae065cb2140@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I believe this is ''not'' fixed by my fix to #12776, sadly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 10:29:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 10:29:14 -0000 Subject: [GHC] #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop In-Reply-To: <050.0467eff6823365d8109e507aa34c563f@haskell.org> References: <050.0467eff6823365d8109e507aa34c563f@haskell.org> Message-ID: <065.93309fb062f94c64ca7e6c0a02afea19@haskell.org> #12860: GeneralizedNewtypeDeriving + MultiParamTypeClasses sends typechecker into an infinite loop -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Maybe it'd be better to somehow get the "context too exotic" message, but that might be no more illuminating than the one above. And it's a bit of a corner case. So I'm moving this off my stack for now anyway. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 15:00:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 15:00:27 -0000 Subject: [GHC] #12887: Make each RTS header self-contained In-Reply-To: <047.09675d2d273d8077cba9e874df27d215@haskell.org> References: <047.09675d2d273d8077cba9e874df27d215@haskell.org> Message-ID: <062.857641b297204584e2287839af0ac487@haskell.org> #12887: Make each RTS header self-contained -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I don't object to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 15:21:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 15:21:51 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.49d51ec9e0a7dd22a542c0d02e0f05a2@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -16,0 +16,15 @@ + {{{ + $ /opt/ghc/8.0.2/bin/ghc Bug.hs + [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) + + Bug.hs:9:10: error: + • Overlapping instances for Arbitrary Int + arising from a use of ‘Bug.$dmshrink’ + Matching instances: + instance Arbitrary a -- Defined at Bug.hs:8:10 + instance Arbitrary Int -- Defined at Bug.hs:9:10 + • In the expression: Bug.$dmshrink @Int + In an equation for ‘shrink’: shrink = Bug.$dmshrink @Int + In the instance declaration for ‘Arbitrary Int’ + }}} + New description: `quickcheck-combinators-0.0.1` fails to build with GHC 8.0.2-rc1 (but does build with GHC 8.0.1) due to this issue. Here is a simplified example: {{{#!hs {-# LANGUAGE FlexibleInstances #-} module Bug where class Arbitrary a where shrink :: a -> [a] shrink _ = [] instance Arbitrary a instance Arbitrary Int }}} {{{ $ /opt/ghc/8.0.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:10: error: • Overlapping instances for Arbitrary Int arising from a use of ‘Bug.$dmshrink’ Matching instances: instance Arbitrary a -- Defined at Bug.hs:8:10 instance Arbitrary Int -- Defined at Bug.hs:9:10 • In the expression: Bug.$dmshrink @Int In an equation for ‘shrink’: shrink = Bug.$dmshrink @Int In the instance declaration for ‘Arbitrary Int’ }}} Is this expected? If so, we should make a note of this in the 8.0.2 release notes. -- Comment (by RyanGlScott): Making this even stranger, if you explicitly implement `shrink`: {{{#!hs {-# LANGUAGE FlexibleInstances #-} module Bug where class Arbitrary a where shrink :: a -> [a] shrink _ = [] instance Arbitrary a where shrink _ = [] instance Arbitrary Int where shrink _ = [] }}} then it compiles and both versions of GHC 8.0. However, when you try something like this (which is basically what happens under the hood with default class method implementations): {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Bug where class Arbitrary a where shrink :: a -> [a] shrink _ = [] instance Arbitrary a where shrink = dmshrink @a instance Arbitrary Int where shrink = dmshrink @Int dmshrink :: Arbitrary a => a -> [a] dmshrink _ = [] }}} Then this will fail to compile on GHC 8.0.1 //and// GHC 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 15:30:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 15:30:11 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.a2d1a2c4a7f3e4a7c9c7839de7fbb495@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): So it looks like what is going on here is that in GHC 8.0.1 and before, there was different code generated under the hood for default class method implementations. This code happened to work irrespective of whether any overlapping instances were marked with `OVERLAPPING` or not. That's not to say that leaving off `OVERLAPPING` pragmas couldn't have caused problems down the road in GHC 8.0.1, but in the particular case of default method implementations, it luckily didn't matter. In GHC 8.0.2, however (after https://ghc.haskell.org/trac/ghc/changeset/d2958bd08a049b61941f078e51809c7e63bc3354/ghc), GHC switched to using visible type application to implement default class method implementations. This now poses an issue for any overlapping instances with default method implementations, because in the code that gets generated now, e.g., {{{#!hs instance Arbitrary Int where shrink = dmshrink @Int }}} `dmshrink @Int` is forced to choose a particular `Arbitrary` instance, and without the `OVERLAPPING` annotation, GHC can't decide between the `Arbitrary a` instance and the `Arbitrary Int` instance. So on one hand, there is a somewhat good reason why this code now fails to typecheck. On the other hand, it's quite annoying—a nontrivial number of packages in the wild now fail to build with GHC 8.0.2, and there are probably more examples outside of Stackage that I haven't found. I'm not sure how to address this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 15:30:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 15:30:44 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.da21e1350448af55dccb838058d33315@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -16,15 +16,0 @@ - {{{ - $ /opt/ghc/8.0.2/bin/ghc Bug.hs - [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) - - Bug.hs:9:10: error: - • Overlapping instances for Arbitrary Int - arising from a use of ‘Bug.$dmshrink’ - Matching instances: - instance Arbitrary a -- Defined at Bug.hs:8:10 - instance Arbitrary Int -- Defined at Bug.hs:9:10 - • In the expression: Bug.$dmshrink @Int - In an equation for ‘shrink’: shrink = Bug.$dmshrink @Int - In the instance declaration for ‘Arbitrary Int’ - }}} - New description: `quickcheck-combinators-0.0.1` fails to build with GHC 8.0.2-rc1 (but does build with GHC 8.0.1) due to this issue. Here is a simplified example: {{{#!hs {-# LANGUAGE FlexibleInstances #-} module Bug where class Arbitrary a where shrink :: a -> [a] shrink _ = [] instance Arbitrary a instance Arbitrary Int }}} Is this expected? If so, we should make a note of this in the 8.0.2 release notes. -- Comment (by simonpj): Well there really is an issue here. Suppose you added to the program in the Description {{{ foo :: [Int] -> Int foo x = shrink x }}} then you'd ''expect'' to get the warning {{{ T12881.hs:15:9: error: • Overlapping instances for Arbitrary Int arising from a use of ‘shrink’ Matching instances: instance Arbitrary a -- Defined at T12881.hs:8:10 instance Arbitrary Int -- Defined at T12881.hs:10:10 • In the expression: shrink x In an equation for ‘foo’: foo x = shrink x }}} So, without the pragmas, or the global `-XOverlappingInstances`, the instance declarations for `Arbitrary` are effectively useless. Now, it's true that 8.0.2 is reporting that problem a bit more eagerly than before. I suppose we could switch on `-XOverlappingInstances` when typechecking the default methods in each instance declaration. But that feels like sweeping the real problem under the carpet: those instances really are useless unless you allow overlapping. So the right solution is to add those pragmas. We could mitigate for 8.0.3 (as suggested in the previous para) but I worry that the same thing would happen in 8.2. Advice? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 15:41:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 15:41:51 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.2919d40a22233c2b49b8c57ebf53c1dd@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, we're lucky in that: 1. There are "only" seven Stackage libraries affected by this bug 2. It's easy to convince people that their code in wrong in this case 3. There's an easy workaround I'll try to just patch up these libraries, add a note to the release guide about this, and declare victory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 16:06:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 16:06:04 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjg4ODog4oCYSWRlbnRpdHkgaW5zdGFuY2U=?= =?utf-8?q?=E2=80=99=3A_Outputable_SDoc?= In-Reply-To: <051.d16c20317c8bb02531acee4d18634b76@haskell.org> References: <051.d16c20317c8bb02531acee4d18634b76@haskell.org> Message-ID: <066.39f4fa8a3aa8ef78d6d0da5495c2bd50@haskell.org> #12888: ‘Identity instance’: Outputable SDoc -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've wondered this, too, thinking that the reason was to support better hygiene. But I think we should just have it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 16:07:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 16:07:54 -0000 Subject: [GHC] #12889: memory leak Message-ID: <051.9788c205b55da7e225d16eafba26def9@haskell.org> #12889: memory leak -------------------------------------+------------------------------------- Reporter: zoranbosnjak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This simple test program leaks memory for no obvious reason. {{{#!hs module Main where import Control.Monad import Control.Monad.Trans.Reader main :: IO () main = do runReaderT task () main task :: ReaderT () IO () task = forM_ [(1::Integer)..] $ \cnt -> do return cnt }}} However, there are some minor changes that (each individual change alone) make this program run in constant memory. 1. If I remove {{{#!hs module Main where }}} 2. If I remove recursive call to main 3. If I put task definition under the scope of main, like so {{{#!hs module Main where import Control.Monad import Control.Monad.Trans.Reader main :: IO () main = do runReaderT task () main where task :: ReaderT () IO () task = forM_ [(1::Integer)..] $ \cnt -> do return cnt }}} Any of the changes above make the program run OK, but I belive that this should be also true for the original test program. I am not sure where the problem is (if at all), but it's extremely difficult to isolate this kind of problem in the real application. Please check if anything can be done on the compiler or runtime to prevent this kind of problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 16:12:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 16:12:26 -0000 Subject: [GHC] #12886: Proposal for throwLeft and throwLeftIO in Control.Exception In-Reply-To: <048.20cdb7217c9551470366c48ee53b317a@haskell.org> References: <048.20cdb7217c9551470366c48ee53b317a@haskell.org> Message-ID: <063.6ccf27ce876bede07f05f57fe57c022c@haskell.org> #12886: Proposal for throwLeft and throwLeftIO in Control.Exception -------------------------------------+------------------------------------- Reporter: yfeldblum | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => ekmett Comment: This looks good to me. Assigning to @ekmett as per the core libraries process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 16:44:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 16:44:33 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.16c8640a18b362272809354ca9de8680@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12843 #12675 | Differential Rev(s): #12789 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"605af54aee76cd3d02afb60ff0b0dde052645fe7/ghc" 605af54a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="605af54aee76cd3d02afb60ff0b0dde052645fe7" Test Trac #12776 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 16:45:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 16:45:57 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.a2ebfc0c31df854f27dac6666d94a8a1@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That sounds good to me.. thanks Ryan. (Of course we are assuming that it is indeed "easy to convince people that their code is wrong". It could be that we have missed something, and there are good reasons... but let's see.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 16:47:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 16:47:19 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.7f4fd25a5b24e201f34b9592ab4a1b9c@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: merge Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T12776 Blocked By: | Blocking: Related Tickets: #12843 #12675 | Differential Rev(s): #12789 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/T12776 * status: new => merge Comment: Big thank you to sjcjoosten for making such a tractable test case. THANKS! It's great to have this one nailed. Worth merging this (or the key part anyway) to 8.0.3 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 16:53:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 16:53:20 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.8af0c3ab5734c6144e6fdff89df71c1d@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2760 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2760 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 16:57:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 16:57:32 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.14a5e5d8364522c9faf6c201d7165185@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2760 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): It is possible to write useful potentially-overlapping instances without marking them as overlapping, e.g. {{{#!hs {-# LANGUAGE FlexibleInstances #-} class C a where def :: a def = undefined instance C (Int, b) instance C (a, Char) }}} But happily GHC HEAD already accepts this case, somehow. (Maybe someone with 8.0.2-rc1 can confirm.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 17:01:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 17:01:58 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.1ffb058199032a715a5fc7d563de66e8@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2760 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:10 rwbarton]: > But happily GHC HEAD already accepts this case, somehow. (Maybe someone with 8.0.2-rc1 can confirm.) Indeed, GHC 8.0.2-rc1 accepts that program. Luckily, these instances aren't sufficiently overlapping to confuse GHC when it uses VTA to apply `@(Int, b)` or `@(a, Char)`. In any case, I made sure to use a phrase akin to "might fail to type- check" instead of "//will// fail to type-check" in Phab:D2760 so as not to exaggerate the severity of this problem ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 17:12:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 17:12:11 -0000 Subject: [GHC] #12885: "too many iterations" causes constraint solving issue. In-Reply-To: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> References: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> Message-ID: <060.ec69af6201694a398850872bfd0fb798@haskell.org> #12885: "too many iterations" causes constraint solving issue. -------------------------------------+------------------------------------- Reporter: judahj | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Aha! Happily, this patch (committed last week) fixes it {{{ commit 0476a64e70c91b326b53db2fc55adbbaa8e5c270 Author: Simon Peyton Jones Date: Tue Oct 25 15:22:17 2016 +0100 Fix a bug in mk_superclasses_of This bug meant that we were less eager about expanding tuple superclasses than we should have been; i.e. we stopped too soon. That's not fatal, beause we expand more superclasses later, but it's less efficient. }}} It's fine in HEAD. I suggest we just merge the patch across for 8.0.3. Here's a one-module test case {{{ {-# LANGUAGE TypeFamilies, ConstraintKinds #-} module Foo where import GHC.Exts f :: F [a] => a -> Bool f x = x == x type family F a :: Constraint type instance F [a] = (Show a, (Show a, (Show a, (Show a, (Show a, Show a, (Show a, (Show a, (Show a, (Show a, Eq a))))))))) }}} The Given `F [a]` expands to the nested tuple, and the bug is that we were only expanding one level of the tuple at a time. I'll add this test to HEAD, for what it's worth. Thanks for identifying this! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 17:16:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 17:16:10 -0000 Subject: [GHC] #12885: "too many iterations" causes constraint solving issue. In-Reply-To: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> References: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> Message-ID: <060.aa7f7ad023364acf542c4b30a7061039@haskell.org> #12885: "too many iterations" causes constraint solving issue. -------------------------------------+------------------------------------- Reporter: judahj | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"27a6bdf029491a7bbd50377932ae86ede5b5020a/ghc" 27a6bdf0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="27a6bdf029491a7bbd50377932ae86ede5b5020a" Test Trac #12885 ...which is fixed by commit 0476a64e70c91b326b53db2fc55adbbaa8e5c270 Author: Simon Peyton Jones Date: Tue Oct 25 15:22:17 2016 +0100 Fix a bug in mk_superclasses_of }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 17:30:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 17:30:38 -0000 Subject: [GHC] #12890: Stdcall - treating as CCall (bogus warning on win 64 bit) Message-ID: <046.3898c6536f65bd6a8d6f3b6770d3e433@haskell.org> #12890: Stdcall - treating as CCall (bogus warning on win 64 bit) -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect (amd64) | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On windows you generally have the stdcall calling convention so you're average foreign import looks like this: {{{ foreign import stdcall "someFile.h getFoo" getFoo :: IO Foo }}} But on a 64 bit system, GHC warns: {{{ C:\Some\Path.hs:35:1: warning: [-Wunsupported-calling-conventions] * the 'stdcall' calling convention is unsupported on this platform, treating as ccall * When checking declaration: foreign import stdcall safe "static someFile.h getFoo" getFoo :: IO Foo }}} Both stdcall & ccall are not applicable to a 64 bit system as far as I know, and if it was really treating it as ccall it would have segfaulted at runtime. So the warning is a bit of a lie anyway. So far some developers generally have resorted to creating c preprocessor macros like this: [https://www.mail-archive.com/cvs- libraries at haskell.org/msg09725.html] Apologies if this is a dupe, I thought someone already reported this a long time ago but I can't seem to find the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 17:36:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 17:36:32 -0000 Subject: [GHC] #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. In-Reply-To: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> References: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> Message-ID: <063.b50f70a2c87d06eb9f94726b93934107@haskell.org> #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. ---------------------------------+---------------------------------------- Reporter: rdwebster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by simonpj): Thanks. I worked this through, and it turns out to be a dup of #10083. It was fixed by {{{ commit 5a8fa2e662fce9ef03f0ec7891d7f81740e630bc Author: Edward Z. Yang Date: Thu May 12 20:33:43 2016 -0700 When a value Id comes from hi-boot, insert noinline. Fixes #10083. }}} For some reason, that fix never got merged to the 8.0 branch. I'm not sure if it's worth doing now. There are workarounds described in #10083: can you use them in `hprotoc`? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 17:44:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 17:44:01 -0000 Subject: [GHC] #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. In-Reply-To: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> References: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> Message-ID: <063.59684cd96be886e6778f206b7009f8aa@haskell.org> #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. ---------------------------------+---------------------------------------- Reporter: rdwebster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3aa936893cac8d7c3b242c882731e9a38a4ae425/ghc" 3aa93689/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3aa936893cac8d7c3b242c882731e9a38a4ae425" Comments only (related to #12789) It took me some time to find the right Note for the fix to #12789. This comment patch tries to add pointers from relevant places. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 17:47:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 17:47:27 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.5f81cee2cb6de8febc4b7398dc6aca35@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): How exactly do I reproduce this? `cabal install lambdahack` perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 17:51:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 17:51:08 -0000 Subject: [GHC] #12889: memory leak In-Reply-To: <051.9788c205b55da7e225d16eafba26def9@haskell.org> References: <051.9788c205b55da7e225d16eafba26def9@haskell.org> Message-ID: <066.a65ea6c8445f4d6f07cb0f1e53a5cc23@haskell.org> #12889: memory leak -------------------------------------+------------------------------------- Reporter: zoranbosnjak | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: Your program is retaining the evaluated list `[1,2,3,...]` which grows forever. You might say this is dumb, and in this case it is. But, if you had written {{{#!hs task = forM_ (filter expensiveTest [(1::Integer)..10000000]) $ \cnt -> do ... }}} then you might well have filed a bug wondering why your program is recalculating the list `filter expensiveTest [(1::Integer)..10000000]` for every call to `task`, whenever you make any of your changes 1, 2, 3. So, there is a real tension here. The normal behavior is to calculate a given expression once per time that its surrounding function is entered. Here there is no function around `[(1::Integer)..]` at all, so we calculate it just once during the lifetime of the program. If you remove the recursive call to `main` then the value is also used just once, so it can be GCed as it is generated, but normally this will lead to a space leak. The reason that the other changes cause `task` to be recalculated are more obscure, and probably not very interesting. If you want to tell GHC to always recalculate `task`, it's better to introduce an explicit function, like {{{#!hs task :: () -> ReaderT () IO () task () = forM_ [(1::Integer)..] $ \cnt -> do ... }}} (Even then GHC might decide to share the computation of `[(1::Integer)..]`, but then you have a different issue.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 19:46:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 19:46:05 -0000 Subject: [GHC] #12885: "too many iterations" causes constraint solving issue. In-Reply-To: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> References: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> Message-ID: <060.cab9dc7790afdb2f7603edb8e7fd4911@haskell.org> #12885: "too many iterations" causes constraint solving issue. -------------------------------------+------------------------------------- Reporter: judahj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.3 Comment: Judah, is it critical to you that this is fixed in 8.0.2? I'd prefer to punt this if possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 19:48:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 19:48:09 -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.9577965b9ea202435d8211f666463d8e@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Yes, I think killing off `ghc-split` would be a step in the right direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 19:52:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 19:52:04 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h Message-ID: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12846 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Public symbols that we export in the public headers (rooted from Rts.h) need to be added to the symbols table of the RTS. We currently do this by hand but the list can quickly grow out of sync. Investigate a way to automate either the inclusion or a check during build time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 19:53:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 19:53:27 -0000 Subject: [GHC] #12846: On Windows, runtime linker can't find function defined in GHC's RTS In-Reply-To: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> References: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> Message-ID: <065.7c964ca4e016003043db5c9997ad48d0@haskell.org> #12846: On Windows, runtime linker can't find function defined in GHC's RTS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12891 | Differential Rev(s): Phab:D2727 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed * related: => #12891 Comment: I've committed a specific fix for this issue, but I really want to see a more general solution. So I've made #12891 so I don't forget. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 19:55:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 19:55:41 -0000 Subject: [GHC] #12869: getChar doesn't work on a new Windows build In-Reply-To: <048.a9ae396b2f18efad7938113691fb259c@haskell.org> References: <048.a9ae396b2f18efad7938113691fb259c@haskell.org> Message-ID: <063.38211641ce65b17c02e4e0815b184f02@haskell.org> #12869: getChar doesn't work on a new Windows build -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hi, thanks for the report. Due you happen to have a way to reproduce this issue without being on the insider build? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 19:59:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 19:59:44 -0000 Subject: [GHC] #12873: hWaitForInput with socket as handle excepts on windows In-Reply-To: <044.1ddaa628578738df0ad8573626efc264@haskell.org> References: <044.1ddaa628578738df0ad8573626efc264@haskell.org> Message-ID: <059.57e4996ff1c365c0da407624d74134e7@haskell.org> #12873: hWaitForInput with socket as handle excepts on windows ----------------------------------+-------------------------------------- Reporter: bwurk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #7353 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by Phyx-): * related: => #7353 Comment: Hi, thanks for the report. Unfortunately the I/O system for Windows is a bit lacking at the moment. There is some progress in rewriting it with a proper one but I don't know the current progress. See #7353 . There may however be a workaround for this specific case. That will have to be investigated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 20:48:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 20:48:38 -0000 Subject: [GHC] #12890: Stdcall - treating as CCall (bogus warning on win 64 bit) In-Reply-To: <046.3898c6536f65bd6a8d6f3b6770d3e433@haskell.org> References: <046.3898c6536f65bd6a8d6f3b6770d3e433@haskell.org> Message-ID: <061.8945a347602f86c5a9ade2a4228c00c5@haskell.org> #12890: Stdcall - treating as CCall (bogus warning on win 64 bit) -------------------------------------+------------------------------------- Reporter: tim-m89 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Hi, Thanks for the report. Win32 now contains a header you can include instead of needing to define the macros over and over again see https://github.com/haskell/win32/commit/7f91a92f74b7d93081df49d01b408ae1cd9c2ff9 About the warning. While I agree, I don't know what the right thing here is. You most definitely should get a warning. But the Microsoft x64 calling convention doesn't really have a name we can refer to. And the Haskell FFI standard doesn't allow you to omit the calling convention https://www.haskell.org/onlinereport/haskell2010/haskellch8.html#x15-1540008.4. We default to `cdecl` because that means in this case `do whatever is native to the platform`. If you have any suggestions on how we can do better here, I'm all for it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 20:53:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 20:53:17 -0000 Subject: [GHC] #12558: GHCi Segmentation fault/access violation in generated code In-Reply-To: <044.674cfd9113ce879b5a603d01c0e07d10@haskell.org> References: <044.674cfd9113ce879b5a603d01c0e07d10@haskell.org> Message-ID: <059.1ee1aa05012d820acbefd29b8d6e64a3@haskell.org> #12558: GHCi Segmentation fault/access violation in generated code -------------------------------+------------------------------ Reporter: lazac | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------ Changes (by Phyx-): * status: infoneeded => closed * resolution: => invalid Comment: No information was provided in 2 months. If you're still having the problem and have a small repo, please re-open the ticket. It's worth nothing that several linker related segfaults were fixed for GHC 8.0.2. So that's worth trying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 20:58:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 20:58:32 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.422bd26f799ceae6253d4d6b296f6f3a@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 21:06:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 21:06:26 -0000 Subject: [GHC] #12892: Improve type safety in the RTS Message-ID: <047.5e93c3b59cc514c248a6a1c4d6466412@haskell.org> #12892: Improve type safety in the RTS -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS must (by virtue of its job) be type unsafe, but it doesn't need to be gratuitously so. Currently, there are a lot of dubious conversions, pointer casts that cast away `const`, and other questionable practices. This task covers improving the RTS's type safety. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 22:02:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 22:02:23 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.95c4ce2f103fbad80ee44772eb9259a7@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Nope. The latter snapshot, where 1000 is not enough, is on a branch. You can proceed as in the travis log: {{{ git clone --depth=50 --branch=simplifying-threaded-mode https://github.com/LambdaHack/LambdaHack.git LambdaHack/LambdaHack }}} To skip gtk2hs, which takes long to compile, try the vty version: {{{ cabal install -fvty }}} You may want to try with each optimization level in turn, because it was failing with any. For the original, less excessive, example, try this: {{{ git checkout master git reset --hard 842070fe78f07e2fb0bce829505dcfa8465ef40f cabal install -fvty }}} BTW, thank you for the fix! I wonder if it also fixes the various breakages of INLINE I was reporting in other tickets (https://ghc.haskell.org/trac/ghc/ticket/12603 and its Related Tickets). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 22:04:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 22:04:07 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjg4ODog4oCYSWRlbnRpdHkgaW5zdGFuY2U=?= =?utf-8?q?=E2=80=99=3A_Outputable_SDoc?= In-Reply-To: <051.d16c20317c8bb02531acee4d18634b76@haskell.org> References: <051.d16c20317c8bb02531acee4d18634b76@haskell.org> Message-ID: <066.bb7fcd4955f028cf5ddd44e718976847@haskell.org> #12888: ‘Identity instance’: Outputable SDoc -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: GHC API | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ​Phab:D2761 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * status: new => patch * differential: => ​Phab:D2761 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 22:08:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 22:08:01 -0000 Subject: [GHC] #12869: getChar doesn't work on a new Windows build In-Reply-To: <048.a9ae396b2f18efad7938113691fb259c@haskell.org> References: <048.a9ae396b2f18efad7938113691fb259c@haskell.org> Message-ID: <063.b799d95d8415d1a4e6d3c3b74a2a9860@haskell.org> #12869: getChar doesn't work on a new Windows build -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Darwin226): Unfortunately no. I can confirm it works on a non-insider build and I have two machines on that insider build on which in fails. Sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 22:11:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 22:11:21 -0000 Subject: [GHC] #12869: getChar doesn't work on a new Windows build In-Reply-To: <048.a9ae396b2f18efad7938113691fb259c@haskell.org> References: <048.a9ae396b2f18efad7938113691fb259c@haskell.org> Message-ID: <063.fd2c1e89c3918a02dc85864845c97da8@haskell.org> #12869: getChar doesn't work on a new Windows build -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Well, thanks for the heads up anyway. I'll try to see if I can find a changelog for that build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 22:43:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 22:43:22 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.b3994590003f996896b2a1f8f0e27dc7@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => fixed Comment: I have been looking this code over, and the failures shouldn't affect the performance since the RTS constantly changes affinity. So the fail would only affect a tiny slice of time. I'm not sure why from the hundreds of events only one or two fails, but double checking the code by hand I can't see a problem with the request, which leads me to believe the OS must be rejecting it for another reason than an invalid mask. Even with one processor group the example doesn't pass 90-93% on my machine. Which leads me to believe this is a general issue with the RTS and not this code. I think maybe because of the artificial nature of the testcase that the RTS might be doing a lot of GC, and that's eating time. If you want to know for sure please mail the mailing list. Because this code is correct, I will close this ticket as the logs show it being able to set the affinity over each of the cores correctly in all groups. About the defaults, you should really bring it up with the community if you feel that strongly about it. I am not really in a position to comment about what is sensible or not in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 23:18:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 23:18:29 -0000 Subject: [GHC] #12893: Profiling defeats stream fusion when using vector library Message-ID: <047.39ee7e0ddac148dfe9b639a1948b3bab@haskell.org> #12893: Profiling defeats stream fusion when using vector library -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: stream-fusion | Operating System: MacOS X profiling | Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have this problem where enabling profiling in Haskell undoes stream fusion and I’d like to do my profiling with stream fusion intact. The following reproduces my problem: {{{ $ git clone git at github.com:haskell-works/hw-tutorial-performance.git $ cd hw-tutorial-performance/ $ stack init $ stack build --executable-profiling $ time $(find .stack-work/dist/ -type f -name hw-tutorial-performance- rwhe) 1e7 5000000.5 real 0m4.432s user 0m3.484s sys 0m0.936s $ rm -rf .stack-work/ $ stack build $ time $(find .stack-work/dist/ -type f -name hw-tutorial-performance- rwhe) 1e7 5000000.5 real 0m0.034s user 0m0.018s sys 0m0.013s With profiling, my program takes over 4 seconds to run. Without profiling, it only takes 0.034 seconds. }}} The problem has nothing to do with stack. {{{ (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ ghc -fforce-recomp --make -O2 -funbox-strict-fields -rtsopts -optc-O2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 115,888 bytes allocated in the heap 3,480 bytes copied during GC 44,384 bytes maximum residency (1 sample(s)) 17,056 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.000s 0.005s 0.0049s 0.0049s INIT time 0.000s ( 0.002s elapsed) MUT time 0.010s ( 0.025s elapsed) GC time 0.000s ( 0.005s elapsed) EXIT time 0.000s ( 0.005s elapsed) Total time 0.012s ( 0.037s elapsed) %GC time 1.8% (13.1% elapsed) Alloc rate 11,904,262 bytes per MUT second Productivity 97.1% of total user, 31.2% of total elapsed real 0m0.057s user 0m0.012s sys 0m0.010s (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ ghc -prof -fforce-recomp --make -O2 -funbox-strict-fields -rtsopts -optc-O2 Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1] 08:12 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 3,012,099,000 bytes allocated in the heap 4,079,698,408 bytes copied during GC 1,162,199,352 bytes maximum residency (13 sample(s)) 19,313,368 bytes maximum slop 1990 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 4869 colls, 0 par 1.046s 1.055s 0.0002s 0.0017s Gen 1 13 colls, 0 par 1.230s 1.960s 0.1508s 0.5764s INIT time 0.000s ( 0.004s elapsed) MUT time 0.963s ( 0.825s elapsed) GC time 2.276s ( 3.016s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.009s ( 0.185s elapsed) Total time 3.251s ( 4.029s elapsed) %GC time 70.0% (74.8% elapsed) Alloc rate 3,126,345,026 bytes per MUT second Productivity 30.0% of total user, 24.2% of total elapsed real 0m4.197s user 0m3.251s sys 0m0.883s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 28 23:49:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 28 Nov 2016 23:49:13 -0000 Subject: [GHC] #12893: Profiling defeats stream fusion when using vector library In-Reply-To: <047.39ee7e0ddac148dfe9b639a1948b3bab@haskell.org> References: <047.39ee7e0ddac148dfe9b639a1948b3bab@haskell.org> Message-ID: <062.3600ad1f5d93cd7209d02d13736a9760@haskell.org> #12893: Profiling defeats stream fusion when using vector library -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: stream-fusion | profiling Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by newhoggy): Here is the an example of how I reproduce the problem assuming the vector library is already installed: {{{ (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1…1] 10:46 $ cat Main.hs module Main (main) where import System.Environment import Text.Printf import qualified Data.Vector.Unboxed as DVU main :: IO () main = do [d] <- map read `fmap` getArgs printf "%f\n" (mean (DVU.enumFromTo 1 d)) mean :: DVU.Vector Double -> Double mean xs = s / fromIntegral (n :: Int) where Pair n s = DVU.foldl k (Pair 0 0) xs k (Pair m t) x = Pair (m + 1) (t + x) {-# INLINE mean #-} data Pair = Pair !Int !Double (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1…1] 10:47 $ ghc -prof -rtsopts -fno-prof-count-entries -fno-prof-cafs -fno- prof-auto -fforce-recomp -O2 -funbox-strict-fields Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1…1] 10:47 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 3,012,099,000 bytes allocated in the heap 4,079,698,408 bytes copied during GC 1,162,199,352 bytes maximum residency (13 sample(s)) 19,313,368 bytes maximum slop 1990 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 4869 colls, 0 par 1.112s 1.123s 0.0002s 0.0017s Gen 1 13 colls, 0 par 1.333s 2.194s 0.1688s 0.7226s INIT time 0.000s ( 0.003s elapsed) MUT time 1.027s ( 0.880s elapsed) GC time 2.445s ( 3.317s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.009s ( 0.195s elapsed) Total time 3.483s ( 4.395s elapsed) %GC time 70.2% (75.5% elapsed) Alloc rate 2,932,567,762 bytes per MUT second Productivity 29.8% of total user, 23.6% of total elapsed real 0m4.565s user 0m3.484s sys 0m0.939s (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1…1] 10:47 $ ghc -rtsopts -fno-prof-count-entries -fno-prof-cafs -fno-prof- auto -fforce-recomp -O2 -funbox-strict-fields Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... (java-1.8.0 ghc-7.10.3) ✔ ~/wrk/haskell-works/hw-tutorial-performance/hw- tutorial-performance-rwhe [master|✚ 1…1] 10:47 $ time ./Main +RTS -sstderr -RTS 1e7 5000000.5 115,888 bytes allocated in the heap 3,480 bytes copied during GC 44,384 bytes maximum residency (1 sample(s)) 17,056 bytes maximum slop 1 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.000s 0.005s 0.0050s 0.0050s INIT time 0.000s ( 0.002s elapsed) MUT time 0.010s ( 0.026s elapsed) GC time 0.000s ( 0.005s elapsed) EXIT time 0.000s ( 0.005s elapsed) Total time 0.012s ( 0.039s elapsed) %GC time 1.4% (13.0% elapsed) Alloc rate 11,679,903 bytes per MUT second Productivity 97.5% of total user, 30.5% of total elapsed real 0m0.057s user 0m0.012s sys 0m0.008s }}} The first run with profiling is slow and uses a lot of memory. The second run without profiling is very fast and uses a negligible amount of memory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 00:19:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 00:19:01 -0000 Subject: [GHC] #11293: Compiler plugins don't work with profiling In-Reply-To: <045.b5b56c876d4358651f52b61f0cb4e70b@haskell.org> References: <045.b5b56c876d4358651f52b61f0cb4e70b@haskell.org> Message-ID: <060.05dd259bbd3091a467745f9fbd5708b1@haskell.org> #11293: Compiler plugins don't work with profiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): A similar problem applies to TH, although here you can use `-fexternal- interpreter` to ship the code to a GHC built with profiling to solve the problem. Let's talk about how to fix this. 1. The first design decision we have to make is whether or not we should maintain a separate package database for profiled libraries. This is more clear and direct: an entry in the traditional package database indicates hi/o files; an entry in the profiling package database indicates p_hi/p_o files; it also brings a bit of clarity on the implementation side because it's a bit more obvious if you're doing a lookup in the host or target database, and so it's clearer you need to do something different in these cases. On the other hand, changing this would cause a lot of churn on the tool-side. For now, I think that we should not split it up; if we did, `Packages` would need a bit of changing. 2. `Packages` knows nothing about profiling/non-profiling loading; the key player here is `LoadIface`. Here things get tricky. Right now, both `loadPluginInterface` and `loadSysInterface` go through the same code path `loadInterface` (via `loadInterfaceWithException`). We need to extract these into two distinct codepaths. The normal, non-plugin codepath should query and update the HPT and EPS as normal. However, the plugin codepath needs to query its OWN copy of EPS (and HPT, I suppose, if you want to support loading a plugin from the same package you're building). The hacky way to do this is to add some extra fields to `HscEnv` (but it's unclear to me if you also want to play this trick for dynamic/non-dynamic, so maybe you want to make a sub-datastructure for this business, so you can be polymorphic in the choice). The correct distinction is probably to have a host HPT/EPS (things that can be loaded into this GHCl plugins) and a target HPT/EPS (the thing you're compiling; other interfaces.) 3. Adding a new copy of HPT and EPS has deep implications: all code that interacts with this needs to be updated to look in the correct HPT/EPS. Of particular interest is `compiler/main/DynamicLoading.hs`; it interacts with interface loading via the plugin interfaces, but it gets a TyThing using `lookupTypeHscEnv`. With two copies of HPT/EPS, it will need a `lookupHostTypeHscEnv` invocation instead. Additionally, in GhcMake the HPT needs to be updating only the thing that it is actually building for. There is a bit of trickery needed here, because a common trick is for Cabal to build a package once without profiling, and then once again with profiling; those local interfaces need from the non-profiling pass somehow need to get shoved in the host/plugin HPT if we are to see them. Perhaps best not to do it at first. In any case, lots of functions need to be looked at, and a decision made. That's it, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 01:21:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 01:21:34 -0000 Subject: [GHC] #12885: "too many iterations" causes constraint solving issue. In-Reply-To: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> References: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> Message-ID: <060.4e708ecf557c94b4a2327a9f6672c952@haskell.org> #12885: "too many iterations" causes constraint solving issue. -------------------------------------+------------------------------------- Reporter: judahj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by judahj): Thanks for the quick response. It's not critical to fix this in 8.0.2. In particular, Simon's diagnosis helped point me to the workaround of replacing `MyTypes` with a regular class: {{{ class MyTypes (as :: [*]) where instance MyTypes '[] where instance (MyType a, MyTypes as) => MyTypes (a ': as) where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 03:13:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 03:13:26 -0000 Subject: [GHC] #12894: Bump directory Message-ID: <046.4beed447095342b2603c24699e3a82bd@haskell.org> #12894: Bump directory -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- dcoutts says that `canonicalizePath` in the version shipped with 8.0.1 is buggy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 05:01:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 05:01:44 -0000 Subject: [GHC] #11293: Compiler plugins don't work with profiling In-Reply-To: <045.b5b56c876d4358651f52b61f0cb4e70b@haskell.org> References: <045.b5b56c876d4358651f52b61f0cb4e70b@haskell.org> Message-ID: <060.37e2afbb5757c7a06d665b93b0bc7665@haskell.org> #11293: Compiler plugins don't work with profiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: angerman (added) Comment: It's interesting to note that this is not only restricted to profiling and non-profiling but crucial for cross compilation. It becomes more and more obvious to me that profiling and cross compilation seem to share a fair bit of preferred infrastructure. In the cross compilation setting the plugin database would have to hold packages compatible with the host, while the regular target database would hold packages for the target platform. Therefore I'm not certain this is or should be restricted to profiling /non-profiling only. I'm also uncertain if it would make sense at some point to have more than two package databases? What if I want to allow multi-target support down the line, would I need package databases for each target, or should they live in one package database and can share the interface files while having different object files? I somewhat doubt that would be practical generic solution due to cpp and architecture differences? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 07:02:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 07:02:04 -0000 Subject: [GHC] #12895: Lookup rules associated with functions/values in GHCI Message-ID: <050.77123088f451c66baebc2915daeb885f@haskell.org> #12895: Lookup rules associated with functions/values in GHCI -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It would be nice to have a way to look up in GHCi what rules can fire for a certain constant as the outmost symbol on the LHS. For example, something like {{{ ghci> :pragmas map {-# RULE "map" [~1] forall f xs. map f xs = build (\c n -> foldr (mapFB c f) n xs) #-} {-# RULE "map/coerce" [1] map coerce = coerce #-} }}} As the name suggests, I think we would also want to list applicable NOINLINE, INLINE, INLINABLE, CONLIKE, SPECIALIZE, etc pragmas too. This would simplify the process of debugging mis-firing rules. If this isn't too difficult, I'd love to try implementing it. I've been looking for some way of contributing to GHC. This initially came up here http://stackoverflow.com/q/38651602/3072788. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 07:23:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 07:23:10 -0000 Subject: [GHC] #11293: Compiler plugins don't work with profiling In-Reply-To: <045.b5b56c876d4358651f52b61f0cb4e70b@haskell.org> References: <045.b5b56c876d4358651f52b61f0cb4e70b@haskell.org> Message-ID: <060.14734610d7b1b27ada33ad9d78e8732d@haskell.org> #11293: Compiler plugins don't work with profiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I suggest just tackling the profiling problem as a way of avoiding the "biting off more than you can chew" problem. While it's reasonable to try to anticipate things the cross-compiling version will need, I also suspect that you'll have to rewrite a lot of code anyway in the cross-compiling case. So if you anticipate too much, you'll find that you tied yourself up in knots for code that you didn't actually need. This is open source; as long as you're persistent, we can take the time to rewrite several times ;) Let's talk about the question of separate or together package databases. Common sense seems to dictate two contradictory positions: 1. Profiling versions of library "ought" to be in the same package database (or, at least, that's how we do it today) 2. Different cross-compiler targets "ought" to be in different package databases The crux of the matter is what having separate package databases buys you: you can have multiple copies of the package with the *same* IPID, but compiled differently. Sometimes this occurs in the single package database today (think about the profiling and non-profiling versions of a library), but these have to be awkwardly squeezed into the same package database entry. "Fortunately", the package database entry looks no different whether or not profiling libraries are present, so distros that want to bundle profiling libraries separately from the real ones just drop in some appropriately named p_hi and _p.a files. But it is also a pain for cabal- install Nix-style local builds, which doesn't really want to be retroactively stuffing profiling libraries into preexisting installations. So, *why* would you want to ensure that the profiling and non-profiling versions of a library get the same symbol names (via the IPID)? In a world where Template Haskell obeys strict staging, I think the answer is, never. But when we blur the lines between compile time and run time (as is encouraged by our current TH model, where there is no difference between a compile time and a runtime dependency), there are situations where you have a Name from the compile time world, and you want to lift (well, the type-class is called that but IMO it goes the wrong way!) a name from the compile-time world to the run-time world. And now the outrageous coincidence of compile-time and run-time entities (e.g., profiling and non-profiling) being named the same way is very useful, because you can just slide it from one realm to the next and still have it mean something. (Of course, if a preprocessor macro caused a Name to stop existing, then you did something bad and GHC will probably panic. So this kind of punning is not very safe--empirically, it seems to have been OK for profiling because no one ever CPPs for profiling.) So, if you are going to insist on a strict staging separation (I think, from GHC's perspective, everything can be implemented correctly this way; it's just a matter of user code not using NameG and Typeable in naughty ways), then I don't see any reason to have multiple package databases. If I build a profiling version of library, it should get its own entry in the package database, with a different IPID than its vanilla version (even if it's built with the same things), and its own set of dependencies (on the profiling versions of its deps.) And if the IPIDs are different, they can totally coexist in the same package database. Now you can eagerly error if a profiling library is not present (rather than wait for the attempt to load p_hi to fail). You can even eliminate the p_ prefix for profiling objects/interface files. Some "soft" advice on this patchset. I think it is wise to reduce churn when making a big patch like this. It makes the patch more likely to succeed. So I think there are two reasonable things you can do with this analysis: 1. You can start by refactoring profiling so that it lives in a separate database, eliminating p_hi files. This is a lot of churn: Cabal, build systems, distro packaging, etc. will all have to update--hopefully for the better. While you are doing this, you will run into the blocking problem of handling plugins and TH, since they are trying to load code from the profiling database which will no longer exist. So then you'll solve this ticket, by adding a second EPS/HPT, etc, as described above. 2. OR, you could just solve the blocking problem first, introducing a new EPS/HPT, but assuming everything is in the same database, and then solve that problem later (or not at all), perhaps when you need cross compiling to work. P.S. You wonder if you will need two databases. Let me flip around your question: rather than databases, does it every make sense to have more than two EPSes in GHC? The only situation is if GHC is compiling code for two targets *at the same time.* I can't think this would ever be relevant for cross-compilation, but rather mysteriously GHC does try to generate dynamic and non-dynamic objects at the same time using `-dynamic-too`. Still, we get along just fine with one EPS even in this case, so I think two is enough. Obviously you can maintain more databases on disk, but GHC will only ever look at two at a time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 10:23:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 10:23:39 -0000 Subject: [GHC] #12895: Lookup rules associated with functions/values in GHCI In-Reply-To: <050.77123088f451c66baebc2915daeb885f@haskell.org> References: <050.77123088f451c66baebc2915daeb885f@haskell.org> Message-ID: <065.cad6f7990f97689a072fc0f5f9f2ab4d@haskell.org> #12895: Lookup rules associated with functions/values in GHCI -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I can see the value, and I don't think it'd be hard. Happy to advise. First look at how `:info` works, I suggest. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 10:41:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 10:41:53 -0000 Subject: [GHC] #12893: Profiling defeats stream fusion when using vector library In-Reply-To: <047.39ee7e0ddac148dfe9b639a1948b3bab@haskell.org> References: <047.39ee7e0ddac148dfe9b639a1948b3bab@haskell.org> Message-ID: <062.908274387a40ccfcf2dc85cd638e443c@haskell.org> #12893: Profiling defeats stream fusion when using vector library -------------------------------------+------------------------------------- Reporter: newhoggy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: stream-fusion | profiling Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's extremely difficult to combine (a) cost-centre profiling with (b) lots of optimisation. It's a research question and GHC doesn't solve it. If you want unrestricted optimisation, I'm afraid you are stuck with the (much lower level) `ticky-ticky` profiling system. It'd be great to improve this, but I don't know how. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 12:11:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 12:11:03 -0000 Subject: [GHC] #12877: Constant propagation with basic unboxed arithmetic instructions In-Reply-To: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> References: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> Message-ID: <060.e170cb4eaf7fb7906bffe3f233b49e6f@haskell.org> #12877: Constant propagation with basic unboxed arithmetic instructions -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2762 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D2762 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 13:23:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 13:23:29 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.dbfc2a55ca477a71b129983171cff241@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I wanted to start with HEAD, but I get {{{ Resolving dependencies... Configuring parsec-3.1.11... Configuring template-haskell-2.11.0.0... Building template-haskell-2.11.0.0... Building parsec-3.1.11... Failed to install template-haskell-2.11.0.0 Build log ( /home/simonpj/.cabal/logs/template-haskell-2.11.0.0.log ): cabal: Entering directory '/tmp/cabal-tmp-16852/template-haskell-2.11.0.0' Configuring template-haskell-2.11.0.0... Building template-haskell-2.11.0.0... Preprocessing library template-haskell-2.11.0.0... Language/Haskell/TH/Lib.hs:487:2: error: error: #error Remove deprecated familyNoKindD, familyKindD, closedTypeFamilyNoKindD and closedTypeFamilyKindD `gcc' failed in phase `C pre-processor'. (Exit code: 1) cabal: Leaving directory '/tmp/cabal-tmp-16852/template-haskell-2.11.0.0' Failed to install parsec-3.1.11 Build log ( /home/simonpj/.cabal/logs/parsec-3.1.11.log ): cabal: Entering directory '/tmp/cabal-tmp-16851/parsec-3.1.11' Configuring parsec-3.1.11... Building parsec-3.1.11... Preprocessing library parsec-3.1.11... [ 1 of 25] Compiling Text.Parsec.Pos (.hs -> .o) [ 2 of 25] Compiling Text.Parsec.Error (.hs -> .o) [ 3 of 25] Compiling Text.Parsec.Prim (.hs -> .o) [ 4 of 25] Compiling Text.Parsec.Combinator (.hs -> .o) [ 5 of 25] Compiling Text.Parsec.Expr (.hs -> .o) [ 6 of 25] Compiling Text.Parsec.Char (.hs -> .o) [ 7 of 25] Compiling Text.Parsec.ByteString.Lazy (.hs -> .o) [ 8 of 25] Compiling Text.Parsec.ByteString (.hs -> .o) [ 9 of 25] Compiling Text.Parsec (.hs -> .o) [10 of 25] Compiling Text.Parsec.Perm (.hs -> .o) [11 of 25] Compiling Text.Parsec.String (.hs -> .o) [12 of 25] Compiling Text.Parsec.Text (.hs -> .o) [13 of 25] Compiling Text.Parsec.Text.Lazy (.hs -> .o) [14 of 25] Compiling Text.Parsec.Token (.hs -> .o) Text/Parsec/Token.hs:524:27: error: • Could not deduce (Stream s m t0) arising from a use of ‘option’ from the context: Stream s m Char bound by the type signature for: makeTokenParser :: Stream s m Char => GenLanguageDef s u m -> GenTokenParser s u m at Text/Parsec/Token.hs:(351,1)-(352,63) The type variable ‘t0’ is ambiguous Relevant bindings include decimalFloat :: ParsecT s u1 m (Either Integer Double) (bound at Text/Parsec/Token.hs:523:5) fractFloat :: forall b a1 u a2. (Read b, Show a2) => a2 -> ParsecT s u m (Either a1 b) (bound at Text/Parsec/Token.hs:528:5) fractExponent :: forall a1 u a2. (Show a2, Read a1) => a2 -> ParsecT s u m a1 (bound at Text/Parsec/Token.hs:532:5) fraction :: forall u. ParsecT s u m [Char] (bound at Text/Parsec/Token.hs:546:5) exponent' :: forall u. ParsecT s u m [Char] (bound at Text/Parsec/Token.hs:552:5) int :: forall u. ParsecT s u m Integer (bound at Text/Parsec/Token.hs:561:5) reservedOp :: String -> ParsecT s u m () (bound at Text/Parsec/Token.hs:590:5) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) These potential instances exist: instance [safe] Monad m => Stream [tok] m tok -- Defined at Text/Parsec/Prim.hs:385:10 ...plus four instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In a stmt of a 'do' block: option (Left n) (fractFloat n) In the expression: do { n <- decimal; option (Left n) (fractFloat n) } In an equation for ‘decimalFloat’: decimalFloat = do { n <- decimal; option (Left n) (fractFloat n) } }}} My HEAD has `template-haskell` installed, so I'm not sure why it's trying to install a different version. Nor do I understand the error in `parsec`. I guess I can try with the `8.0 branch`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 13:49:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 13:49:29 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.97742b99d122c57e7c55bf0f2edbe17b@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2760 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"abd4a4c13e5dbaac8f1c28d8c9d9446e383f6037/ghc" abd4a4c1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="abd4a4c13e5dbaac8f1c28d8c9d9446e383f6037" Make note of #12881 in 8.0.2 release notes Summary: Resolves #12881. Test Plan: Read it, commit it, merge it, ship it Reviewers: hvr, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2760 GHC Trac Issues: #12881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 13:50:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 13:50:16 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.cf52669e024008fd90c204ad66acda3b@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2760 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 14:00:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 14:00:23 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.83ffc06a4cdc71b0b70966091da898b6@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm more worried about the `Iface Id out of scope` errors, which are outright wrong. How can I reproduce those? The "ticks-exhausted" thing may be just that there is a lot of inlining going on under library control, and so absolutely fine. Do you have a reason to suppose otherwise? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 14:15:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 14:15:39 -0000 Subject: [GHC] #12820: Regression around pattern synonyms and higher-rank types In-Reply-To: <047.8ff9e83595f6e43eb23a94e0b79eda39@haskell.org> References: <047.8ff9e83595f6e43eb23a94e0b79eda39@haskell.org> Message-ID: <062.d394856675e7f1524f184296ffa5ad5e@haskell.org> #12820: Regression around pattern synonyms and higher-rank types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. Works ok if you put the forall after the arrow {{{ pattern P x <- (((\ _ -> id) :: forall b. b -> forall c. c -> c) -> x) }}} Reason: we infer the type of `f`, and then try to decompose and arrow, instantiating if necessary. But we don't re-generalise. I suppose we could but this is a pretty exotic corner and it's not keeping me awake at night. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 14:16:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 14:16:49 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.b954ae52a40ca091f01b729351382b76@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Regarding HEAD build failures, I have the same problem with TH and HEAD on travis (https://travis-ci.org/LambdaHack/LambdaHack/jobs/177586413). I just ran it with -v2 flag for cabal, to get some more info: https://api .travis-ci.org/jobs/179766413/log.txt?deansi=true There are some panics there that may be of interest to GHC hackers. The package template-haskell seems to be required by free-4.12.4 bifunctors-5.4.1 aeson-1.0.2.1 enummapset-th-0.6.1.1 exceptions-0.8.3 functor-infix-0.0.4 tagged-0.8.5 Of these, e.g., https://hackage.haskell.org/package/functor-infix depends on (>=2.8 && <2.12), so that may be the reason for reinstallation. I don't see the problem with parsec in my log, perhaps because parsec is only needed with the -fvty flag. The travis log above is from a build with no flags (it uses gtk2hs). Yet another option is -fcurses, but it won't help with template-haskell, unfortunately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 14:21:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 14:21:59 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.25001298205602e23a127c29c37851da@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12602 | Differential Rev(s): Phab:D2533 Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): I don't feel it is a big issue now, so I'm leaving that topic. This fix in GHC 8.2 is enough for me. I'm waiting impatiently for GHC 8.2 to be released! Thanks a lot! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 14:57:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 14:57:30 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.fddba6630d8e2d28f70a94251b925ee8@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: This keeps bugging me. Is this ok or not? {{{ class Monad m => MonadSupply m where fresh :: m Integer default fresh :: MonadTrans t => t m Integer fresh = lift fresh }}} It's accepted right now. But I think it should not be; specifically, '''I think the type of the default method should differ from the main method only in its context'''. Thus if {{{ fresh :: C => blah }}} then the default method should look like {{{ default fresh :: C' => blah }}} with the same `blah`. So we should write {{{ class Monad m => MonadSupply m where fresh :: m Integer default fresh :: (MonadTrans t, MonadSupply m', m ~ t m') => m Integer -- NB: same 'm Integer' after the '=>' fresh = lift fresh }}} Why? Several reasons: * It would make no sense at all to have a type that was actually ''incompatible'' with the main method type, e.g. {{{ default fresh :: m Bool }}} That would ''always'' fail in an instance decl. * We use Visible Type Application to instantiate the default method in an instance, for reasons discussed in `Note [Default methods in instances]` in `TcInstDcls`. So we need to know exactly what the universally quantified type variables are, and when instantaited that way the type of the default method must match the expected type. With this change, the patches to Agda in comment:14 would all be signalled at the ''class'' decl, which is the right place, not the instance decl. The patches to Agda would still be needed, of course. Does that rule make sense to everyone? The [http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #class-default-signatures user manual] is silent on what rules the default signature should obey. It's just formalising the idea that the default signature should match the main one, but perhaps with some additional constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 15:07:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 15:07:39 -0000 Subject: [GHC] #12885: "too many iterations" causes constraint solving issue. In-Reply-To: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> References: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> Message-ID: <060.e600a2795b43edc8c3c810a342b185d7@haskell.org> #12885: "too many iterations" causes constraint solving issue. -------------------------------------+------------------------------------- Reporter: judahj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: 8.0.3 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 15:09:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 15:09:01 -0000 Subject: [GHC] #12885: "too many iterations" causes constraint solving issue. In-Reply-To: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> References: <045.e62f9c30ca78d31c70cf08299b80cc91@haskell.org> Message-ID: <060.95e8d122fa982fdb8b6e77203ed19831@haskell.org> #12885: "too many iterations" causes constraint solving issue. -------------------------------------+------------------------------------- Reporter: judahj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: 8.0.2 => 8.0.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 15:09:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 15:09:31 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.f2fea8927e403436baf6b2cdcfa9ee47@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simon, that sounds sensible to me. I was quite shocked myself to learn how many `DefaultSignatures` validity checks are shunted off until the site of instance declarations instead of the class declaration, and moreover, that there is no requirement that the normal type signature and the default type signature must be the same (modulo context differences). Of course, that all sounds wonderful in my head, but if tracking down these kinds of regressions have taught me anything, it's that fiddling with `DefaultSignatures` further is inevitably bound to break more code in the wild. I don't say that to discourage you from pursuing this change (which I think is a net positive), but be aware that there are probably Haskell programs that are abusing `DefaultSignatures` in wildly creative ways, so we'll likely step on their toes in some way. '''tl;dr''' If we change the typechecking rules for `DefaultSignatures` further, we should carefully consider whether it's worth introducing in a minor release :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 15:13:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 15:13:17 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.91db77b1fb941f836dd82b6d0cc47b4d@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh yes, any further change can be in 8.2. I'll proceed as I propose unless someone yells. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 15:39:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 15:39:25 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.6ec8b65c9e4c32bc14e869b852009008@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 11698 | Blocking: Related Tickets: | Differential Rev(s): Phab:D2104, Wiki Page: | Phab:D2655 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 16:05:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 16:05:04 -0000 Subject: [GHC] #10684: Error cascade when unrelated class derivation fails In-Reply-To: <045.c629d6ca48d10e5b203720966d06c869@haskell.org> References: <045.c629d6ca48d10e5b203720966d06c869@haskell.org> Message-ID: <060.b13a3a4f736296f37a3cc0a6b875b044@haskell.org> #10684: Error cascade when unrelated class derivation fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #12801 for another example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 16:13:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 16:13:21 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.5999df3f3a7f28607052c709113878de@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Regarding "ticks-exhausted", yes the inlining is excessive and I don't have any reason to suppose anything is amiss, apart of the fact that I need 10 times more ticks than the amount that triggers "panic! (the 'impossible' happened)". Regarding `Iface Id out of scope`, I've just reproduced it just as in the original report. Here is a quicker way to reproduce: {{{ git checkout master git reset --hard 842070fe78f07e2fb0bce829505dcfa8465ef40f cabal configure cabal build --ghc-option=-fsimpl-tick-factor=200 touch GameDefinition/Main.hs cabal build --ghc-option=-fsimpl-tick-factor=200 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 16:18:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 16:18:59 -0000 Subject: [GHC] #12718: Segmentation fault, runtime representation polymorphism In-Reply-To: <051.1845a6905973bf302772cb06f664a84f@haskell.org> References: <051.1845a6905973bf302772cb06f664a84f@haskell.org> Message-ID: <066.b7c9f493e3ac86a7556bb9eccf14965a@haskell.org> #12718: Segmentation fault, runtime representation polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #12779 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 16:19:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 16:19:21 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.304ea69d59cbba5649f1ad312231db9f@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 16:19:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 16:19:41 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.0b1987da426adc2bd83d876df8c2af29@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: typeable, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: typeable => typeable, LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 16:22:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 16:22:17 -0000 Subject: [GHC] #12709: GHC panic In-Reply-To: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> References: <051.a009400e83d63b75a3152f451e5c360e@haskell.org> Message-ID: <066.0770c1bd002504657f0de0ac653c52df@haskell.org> #12709: GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LevityPolymorphism Comment: We should rejec {{{ a :: BoxUnbox a = let u :: Num (a :: TYPE rep) => a u = 1 + 2 + 3 + 4 }}} because application `1 + blah` has a levity-polymorphic argument. See the paper. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 16:56:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 16:56:54 -0000 Subject: [GHC] #12820: Regression around pattern synonyms and higher-rank types In-Reply-To: <047.8ff9e83595f6e43eb23a94e0b79eda39@haskell.org> References: <047.8ff9e83595f6e43eb23a94e0b79eda39@haskell.org> Message-ID: <062.ecbbea1cf71d1da4e97482e1f820b6b8@haskell.org> #12820: Regression around pattern synonyms and higher-rank types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: Maybe this ''is'' what kept me awake last night. Or maybe it was my cat who felt the need to lovingly stroke my face roughly hourly. Until she was banished to the kitchen. No, I'm not overly bothered by this. But it is subtly wrong, according to any bidirectional accounting of a type system that accommodates view patterns and has principal types. I'll put this in my queue. At the bottom. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 17:01:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 17:01:44 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.60e3baf37382298e15f752b2b2c1de4f@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I like that your proposal is clear on the status of a program like {{{ class Monad m => MonadSupply m where fresh :: m Integer default fresh :: (Monad n, MonadTrans t) => t n Integer -- NB: not m fresh = lift fresh }}} which does seem like a reasonable attempt at writing a correct default signature. But it's not obvious how to type check in the presence of what amount to two type signatures for the same declaration. On the other hand, it's mildly unsatisfactory that in order to write your recommended version, you need to enable another language extension that in turn enables `MonoLocalBinds` by default, which can affect unrelated declarations in the module. It feels like the use of type equalities here is fairly mild and shouldn't logically entail the need for reasoning about local type equalities in pattern matches and so on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 17:47:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 17:47:42 -0000 Subject: [GHC] #12894: Bump directory In-Reply-To: <046.4beed447095342b2603c24699e3a82bd@haskell.org> References: <046.4beed447095342b2603c24699e3a82bd@haskell.org> Message-ID: <061.02e4177a83eab4ada26a04853b9db6fa@haskell.org> #12894: Bump directory -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The problem is specifically https://github.com/haskell/directory/issues/63. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 18:06:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 18:06: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.315d1abd054c4579753012bdd158ac09@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: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #12759 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #12759 Comment: Indeed, I believe this should have been fixed by #12759. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 18:06:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 18:06:24 -0000 Subject: [GHC] #12759: Latest Debian GCC breaks GHC In-Reply-To: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> References: <044.486464eb4c2bd2fafaa87b512dadd156@haskell.org> Message-ID: <059.aaea80b1c4fe8d67b43acea1965738cd@haskell.org> #12759: Latest Debian GCC breaks GHC -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12755, #11834, | Differential Rev(s): Phab:D2707 #9007 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #12755, #11834 => #12755, #11834, #9007 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 18:19:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 18:19:54 -0000 Subject: [GHC] #12896: Consider using compact regions in GHC itself to reduce GC overhead Message-ID: <047.4913bc95579abdcd37d52f2b35894734@haskell.org> #12896: Consider using compact regions in GHC itself to reduce GC overhead -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In make mode, GHC keeps a lot of in-memory data structures about modules it has built and interface files it has read. These data structures are long-lived and immutable (at least, per module/mutually recursive module group/package), so they may be candidates for storing in compact regions to reduce the work done by the GC. Potential problem: if we rely heavily on lazy evaluation in these structures for the purpose of avoiding work that will never be needed, then we can't store them in a compact region (since the contents of a compact region must be fully evaluated). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 19:00:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 19:00:07 -0000 Subject: [GHC] #12776: Panic Simplifier ticks exhausted since ghc 8 In-Reply-To: <049.733544d3a8e60b86f28a261013106260@haskell.org> References: <049.733544d3a8e60b86f28a261013106260@haskell.org> Message-ID: <064.75ed16d273253503ba7d054c4972d57a@haskell.org> #12776: Panic Simplifier ticks exhausted since ghc 8 -------------------------------------+------------------------------------- Reporter: sjcjoosten | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T12776 Blocked By: | Blocking: Related Tickets: #12843 #12675 | Differential Rev(s): #12789 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.3 Comment: Punting to 8.0.3 in the interest of getting 8.0.2 out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 19:09:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 19:09:27 -0000 Subject: [GHC] #11629: reify returns Dec that use ConT instead of PromotedT In-Reply-To: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> References: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> Message-ID: <060.760cb835e9624ac1332d4bcaabb24d96@haskell.org> #11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2188 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 19:40:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 19:40:04 -0000 Subject: [GHC] #12799: Itimer.c doesn't compile on iOS non-threaded RTS In-Reply-To: <046.68b9ced4f506a0574776364d7cfde1a4@haskell.org> References: <046.68b9ced4f506a0574776364d7cfde1a4@haskell.org> Message-ID: <061.f41183040f726e95d09d212859862774@haskell.org> #12799: Itimer.c doesn't compile on iOS non-threaded RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1732d7ac43ca578deca39ea5a63cbf34f3cd9dd5/ghc" 1732d7ac/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1732d7ac43ca578deca39ea5a63cbf34f3cd9dd5" Define thread primitives if they're supported. On iOS, we use the pthread-based implementation of Itimer.c even for a non-threaded RTS. Since 999c464, this relies on synchronization primitives like Mutex, so ensure those primitives are defined whenever they are supported, even if !THREADED_RTS. Fixes #12799. Reviewers: erikd, austin, simonmar, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2712 GHC Trac Issues: #12799 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 19:40:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 19:40:04 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.5c19e602ea23c619672e760eda69c991@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f1fc8cbf511c88cb88bf9f46724ee2711f54891a/ghc" f1fc8cbf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f1fc8cbf511c88cb88bf9f46724ee2711f54891a" Make diagnostics slightly more colorful This is a preliminary commit to add colors to diagnostics (warning and error messages). The aesthetic changes are: - 'warning', 'error', and 'fatal' are all colored magenta, red, and red respectively. - The warning annotation [-Wsomething] shares the same color. - Warnings and errors are also bolded (this is consistent with what other compilers do). A new flag has been added to control the behavior: -fdiagnostics-color=(always|auto|never) This flag is 'auto' by default. However, auto-detection is not implemented yet, so it effectively it defaults to off. Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2716 GHC Trac Issues: #8809 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 19:40:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 19:40:04 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.ad73cde9055ffb81045e1003efffb656@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2728 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3ec856308cbfb89299daba56337eda866ac88d6e/ghc" 3ec85630/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3ec856308cbfb89299daba56337eda866ac88d6e" Replace -fshow-source-paths with -fhide-source-paths This patch reverts the change introduced with 587dcccfdfa7a319e27300a4f3885071060b1f8e and restores the previous default output of GHC (i.e., show source path and object path for each compiled module). The -fhide-source-paths flag can be used to hide these paths and reduce the line noise. Reviewers: gracjan, nomeata, austin, bgamari, simonmar, hvr Reviewed By: hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2728 GHC Trac Issues: #12851 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 19:40:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 19:40:04 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.8d970ace60708e1eaa205ed48a5f219b@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"52222f9bf705ad64bc4a212088d153d8918b6173/ghc" 52222f9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="52222f9bf705ad64bc4a212088d153d8918b6173" Detect color support Test Plan: validate Reviewers: erikd, Phyx, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2717 GHC Trac Issues: #8809 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 19:40:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 19:40:57 -0000 Subject: [GHC] #12851: Regression: GHC doesn't show filepaths by default anymore In-Reply-To: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> References: <042.6d84b237049d2a3418d6692ac8e951aa@haskell.org> Message-ID: <057.44cba0fb5ab6092be36220b53662c36e@haskell.org> #12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2728 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I believe the above should resolve this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 19:41:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 19:41:15 -0000 Subject: [GHC] #12799: Itimer.c doesn't compile on iOS non-threaded RTS In-Reply-To: <046.68b9ced4f506a0574776364d7cfde1a4@haskell.org> References: <046.68b9ced4f506a0574776364d7cfde1a4@haskell.org> Message-ID: <061.9e584dbdd2e1a54be4043eb216a0587a@haskell.org> #12799: Itimer.c doesn't compile on iOS non-threaded RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 20:48:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 20:48:12 -0000 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> References: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> Message-ID: <064.620efdfaa72a05c794a7bd91e1601fa9@haskell.org> #2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): Adamse: I think this would be great for haddock too, and am excited someone wants to proceed! I know that a number of people have an interest in this, and am trying to get some further eyes on the proposal to confirm it makes sense, but on first glance it looks like a reasonable approach. Even step 1 on its own would be great, as an opportunity for lots of tooling (ghci included) to start making use of the data. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 21:02:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 21:02:16 -0000 Subject: [GHC] #12897: yesod-auth-1.4.13.2 failed during the building phase. Message-ID: <051.9eecd9aa0233266e05fba7c937315f68@haskell.org> #12897: yesod-auth-1.4.13.2 failed during the building phase. -------------------------------------+------------------------------------- Reporter: onomatopoeia | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Resolving dependencies... Configuring yesod-auth-1.4.13.2... Building yesod-auth-1.4.13.2... Failed to install yesod-auth-1.4.13.2 Build log ( /Users/simonrobins/.cabal/logs/yesod-auth-1.4.13.2.log ): Configuring yesod-auth-1.4.13.2... Building yesod-auth-1.4.13.2... Preprocessing library yesod-auth-1.4.13.2... [ 1 of 12] Compiling Yesod.PasswordStore ( Yesod/PasswordStore.hs, dist/build/Yesod/PasswordStore.dyn_o ) Yesod/PasswordStore.hs:166:31: Warning: Defaulting the following constraint(s) to type ‘Integer’ (Integral b0) arising from a use of ‘^’ at Yesod/PasswordStore.hs:166:31 (Num b0) arising from the literal ‘32’ at Yesod/PasswordStore.hs:166:32-33 In the first argument of ‘(-)’, namely ‘2 ^ 32’ In the first argument of ‘(*)’, namely ‘(2 ^ 32 - 1)’ In the second argument of ‘(>)’, namely ‘(2 ^ 32 - 1) * hLen’ Yesod/PasswordStore.hs:419:1: Warning: Defined but not used: ‘toStrict’ Yesod/PasswordStore.hs:422:1: Warning: Defined but not used: ‘fromStrict’ [ 2 of 12] Compiling Yesod.Auth.Message ( Yesod/Auth/Message.hs, dist/build/Yesod/Auth/Message.dyn_o ) Yesod/Auth/Message.hs:23:1: Warning: The import of ‘mappend’ from module ‘Data.Monoid’ is redundant Yesod/Auth/Message.hs:698:1: Warning: Defined but not used: ‘croatianMessage’ Yesod/Auth/Message.hs:459:1: Warning: Pattern match(es) are overlapped In an equation for ‘finnishMessage’: finnishMessage Password = ... Yesod/Auth/Message.hs:459:1: Warning: Pattern match(es) are non-exhaustive In an equation for ‘finnishMessage’: Patterns not matched: CurrentPassword [ 3 of 12] Compiling Yesod.Auth.Routes ( Yesod/Auth/Routes.hs, dist/build/Yesod/Auth/Routes.dyn_o ) [ 4 of 12] Compiling Yesod.Auth ( Yesod/Auth.hs, dist/build/Yesod/Auth.dyn_o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/jf/bqzbd3l92vvbl4wb9vdkv8f80000gn/T/ghc55090_0/libghc_15.dylib, 5): no suitable image found. Did find: /var/folders/jf/bqzbd3l92vvbl4wb9vdkv8f80000gn/T/ghc55090_0/libghc_15.dylib: malformed mach-o: load commands size (36560) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: yesod-1.4.3 depends on yesod-auth-1.4.13.2 which failed to install. yesod-auth-1.4.13.2 failed during the building phase. The exception was: ExitFailure 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 21:17:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 21:17:37 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.68b4593b6dbc163bb77f3a2f04090b40@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Phyx has put in a herculean effort to try to fix up the testsuite driver in Phab:D2684. Unfortunately, while the result works on Harbormaster and RyanGlScott's machine, it still fails for me. However, it turns out that only mingw-w64 Python 2.7 is affected. Given that maintaining Python 2 support is already becoming rather tiresome and that Python 3 seems to work just fine, I say let's just deprecate Python 2 support in the testsuite driver. I've proposed this as Phab:D2766. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 21:46:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 21:46:58 -0000 Subject: [GHC] #10614: Show constraints in ``Found hole...'' In-Reply-To: <047.e629c8600a92660c55de2127511a14cd@haskell.org> References: <047.e629c8600a92660c55de2127511a14cd@haskell.org> Message-ID: <062.0cf83069b92cd37a5adfb2b3383a525f@haskell.org> #10614: Show constraints in ``Found hole...'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D2767 -------------------------------------+------------------------------------- Changes (by zyla): * status: new => patch * differential: => https://phabricator.haskell.org/D2767 Comment: I've submitted a patch to Phabicator. There are some problems though: - `pprSkolInfo` is reused for printing the source of the constraints, and the messages become quite long. - It doesn't yet detect duplicates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 22:43:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 22:43:34 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.d59eae2d685e077d739492993687006f@haskell.org> #12096: Attach stacktrace information to SomeException -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mnislaih): * cc: mnislaih (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 23:03:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 23:03:04 -0000 Subject: [GHC] #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. In-Reply-To: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> References: <048.80c7f8f8fb78ebac354daad6fd49948f@haskell.org> Message-ID: <063.a9c2c5d8497baf71f7d3a474b3fb9ce6@haskell.org> #12789: "Simplifier ticks exhausted" compiling mutually recursive modules with GHC 8. ---------------------------------+---------------------------------------- Reporter: rdwebster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by rdwebster): Thanks for investigating. I have a workaround for the problem, so I am not blocked by this. I decided to restructure the protobuf messages so that there is no longer this recursive module import situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 23:16:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 23:16:08 -0000 Subject: [GHC] #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 In-Reply-To: <044.9c8bab5a25e1b9b83e76116a3cc77c77@haskell.org> References: <044.9c8bab5a25e1b9b83e76116a3cc77c77@haskell.org> Message-ID: <059.e84094d679661cbc972ccf2501cc0917@haskell.org> #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 23:16:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 23:16:20 -0000 Subject: [GHC] #11219: Implement fine-grained `-Werror=...` facility In-Reply-To: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> References: <042.5bdc58470a03f2bc4f044a0a96cc781d@haskell.org> Message-ID: <057.6b99887504e833372675a417c1b8416f@haskell.org> #11219: Implement fine-grained `-Werror=...` facility -------------------------------------+------------------------------------- Reporter: hvr | Owner: quchen Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11796 | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 23:16:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 23:16:25 -0000 Subject: [GHC] #12796: hschooks.c #include path is incorrect In-Reply-To: <046.be652681697ce65090aa6a04158d2f64@haskell.org> References: <046.be652681697ce65090aa6a04158d2f64@haskell.org> Message-ID: <061.a8bc82ef1fc96312a0d22e828da049ee@haskell.org> #12796: hschooks.c #include path is incorrect -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 23:21:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 23:21:08 -0000 Subject: [GHC] #12898: Upgrade Stack failed Message-ID: <045.600c97de7624963d0388c4515db686d9@haskell.org> #12898: Upgrade Stack failed ----------------------------------------+---------------------------- Reporter: Bugger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- (Please note that I am new here and not sure whether it is the right place to post this...) I was trying to do stack upgrade via shell and received following output (cf. attachement): As it links here with "Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug" I will just post it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 29 23:21:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 29 Nov 2016 23:21:41 -0000 Subject: [GHC] #12898: Upgrade Stack failed In-Reply-To: <045.600c97de7624963d0388c4515db686d9@haskell.org> References: <045.600c97de7624963d0388c4515db686d9@haskell.org> Message-ID: <060.86488e452c47321fa1e99106911950f7@haskell.org> #12898: Upgrade Stack failed -----------------------------+---------------------------------------- Reporter: Bugger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Changes (by Bugger): * Attachment "Terminal Saved Output" added. output from shell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 00:11:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 00:11:50 -0000 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> References: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> Message-ID: <064.1aa2125c54b52d39698f0e56c0f04b1b@haskell.org> #2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): Doing some more investigations it might make more sense to add the docs to `HscTypes.ModIface` in a fashion similar to how Haddock does in its `Interface` type. This would also add the possibility of docs for unexported entities as Haddock currently supports. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 00:58:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 00:58:08 -0000 Subject: [GHC] #12899: ghc panics at random places with -jX Message-ID: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> #12899: ghc panics at random places with -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Affected versions: pretty much all the things from early ghc8 until most recent. Symptoms: Out of 106 clean builds 36 failed with random ghc panic. By random I mean no two are alike. There are 525 files in a project and compilation goes in parallel with -j8. Other than panic in 21 cases it generates type errors (types are perfectly fine and whatever is under "with actual type" is something that probably exists in the same file or at least in the project itself but totally unrelated to what type an expression actually is. And even in those cases where ghc fails at the same file it usually results in different panic messages. What was checked: Stale interface files: No, ghc is told to use a separate build directory build system removes it bad memory/random file system corruption: No, ghc 7.10 builds the same codebase just fine and it also fails on other machines strange packages in user package database: No, ghc is told to ignore those ghc was reinstalled several times with system package db wiped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 00:58:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 00:58:48 -0000 Subject: [GHC] #12899: ghc panics at random places with -jX In-Reply-To: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> References: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> Message-ID: <059.ac491dbedc59acfe07fbb8122ec51741@haskell.org> #12899: ghc panics at random places with -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pacak): * Attachment "panics" added. A list of various panics messages (each one listed twice) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:10:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:10:35 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.5a6eb96c970f7ebea80db6d691bb7a60@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Is there anything left before we can do this? If not I will go ahead and put a patch up on Phabricator that makes `-split-objs` a deprecated synonym for `-split-sections`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:13:54 -0000 Subject: [GHC] #12004: Windows unexpected failures In-Reply-To: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> References: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> Message-ID: <060.658767d1f029fc64dcd855e0ed297b9d@haskell.org> #12004: Windows unexpected failures -------------------------------------+------------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | Phab:D2759 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0ce59be3a2723f814a3e929fd32a44ff4e890a49/ghc" 0ce59be/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ce59be3a2723f814a3e929fd32a44ff4e890a49" Fix testsuite threading, timeout, encoding and performance issues on Windows In a land far far away, a project called Cygwin was born. Cygwin used newlib as it's standard C library implementation. But Cygwin wanted to emulate POSIX systems as closely as possible. So it implemented `execv` using the Windows function `spawnve`. Specifically ``` spawnve (_P_OVERLAY, path, argv, cur_environ ()) ``` `_P_OVERLAY` is crucial, as it makes the function behave *sort of* like execv on linux. the child process replaces the original process. With one major difference because of the difference in process models on Windows: the original process signals the caller that it's done. this is why the file is still locked. because it's still running, control was returned because the parent process was destroyed, but the child is still running. I think it's just pure dumb luck, that the older runtimes are slow enough to give the process time to terminate before we tried deleting the file. Which explains why you do have sporadic failures even on older runtimes like 2.5.0, of a test or two (like T7307). So this patch fixes a couple of things. I leverage the existing `timeout.exe` to implement a workaround for this issue. a) The old timeout used to start the process then assign it to the job. This is slightly faulty since child processes are only assigned to a job is their parent were assigned at the time they started. So this was a race condition. I now create the process suspended, assign it to the job and then resume it. Which means all child processes are not running under the same job. b) First things, Is to prevent dangling child processes. I mark the job with `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` so when the last process in the job is done, it insures all processes under the job are killed. c) Secondly, I change the way we wait for results. Instead of waiting for the parent process to terminate, I wait for the job itself to terminate. There's a slight subtlety there, we can't wait on the job itself. Instead we have to create an I/O Completion port and wait for signals on it. See https://blogs.msdn.microsoft.com/oldnewthing/20130405-00/?p=4743 This fixes the issues on all runtimes for me and makes T7307 pass consistenly. The threading was also simplified by hiding all the locking in a single semaphore and a completion class. Futhermore some additional error reporting was added. For encoding the testsuite now no longer passes a file handle to the subprocess since on windows, sh.exe seems to acquire a lock on the file that is not released in a timely fashion. I suspect this because cygwin seems to emulate console handles by creating file handles and using those for std handles. So when we give it an existing file handle it just locks the file. I what's happening is that it's not releasing the handle until all shared cygwin processes are dead. Which explains why it worked in single threaded mode. So now instead we pass a pipe and do not interpret the resulting data. Any bytes written to stdin or read out of stdout/stderr are done so in binary mode and we do not interpret the data. The reason for this is that we have encoding tests in GHC which pass invalid utf-8. If we try to handle the data as text then python will throw an exception instead of a test comparison failing. Also I have fixed the ability to override `PYTHON` when calling `make tests`. This now works the same as with `.\validate`. Finally, after cleaning up the locks I was able to make the abort behavior work correctly as I believe it was intended: when you press Ctrl+C and send an interrupt signal, the testsuite finishes the active tests and then gracefully exits showing you a report of the progress it did make. So using Ctrl+C will not just *die* as it did before. These changes lift the restriction on which python version you use (msys/mingw) or which runtime or python 3 or python 2. All combinations should now be supported. Test Plan: PATH=/usr/local/bin:/mingw64/bin:$APPDATA/cabal/bin:$PATH && PYTHON=/usr/bin/python THREADS=9 make test THREADS=9 make test PATH=/usr/local/bin:/mingw64/bin:$APPDATA/cabal/bin:$PATH && PYTHON=/usr/bin/python ./validate --quiet --testsuite-only Reviewers: erikd, RyanGlScott, bgamari, austin Subscribers: jrtc27, mpickering, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2684 GHC Trac Issues: #12725, #12554, #12661, #12004 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:13:54 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.3eb7abc447f39e06251dc2551c881a93@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0ce59be3a2723f814a3e929fd32a44ff4e890a49/ghc" 0ce59be/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ce59be3a2723f814a3e929fd32a44ff4e890a49" Fix testsuite threading, timeout, encoding and performance issues on Windows In a land far far away, a project called Cygwin was born. Cygwin used newlib as it's standard C library implementation. But Cygwin wanted to emulate POSIX systems as closely as possible. So it implemented `execv` using the Windows function `spawnve`. Specifically ``` spawnve (_P_OVERLAY, path, argv, cur_environ ()) ``` `_P_OVERLAY` is crucial, as it makes the function behave *sort of* like execv on linux. the child process replaces the original process. With one major difference because of the difference in process models on Windows: the original process signals the caller that it's done. this is why the file is still locked. because it's still running, control was returned because the parent process was destroyed, but the child is still running. I think it's just pure dumb luck, that the older runtimes are slow enough to give the process time to terminate before we tried deleting the file. Which explains why you do have sporadic failures even on older runtimes like 2.5.0, of a test or two (like T7307). So this patch fixes a couple of things. I leverage the existing `timeout.exe` to implement a workaround for this issue. a) The old timeout used to start the process then assign it to the job. This is slightly faulty since child processes are only assigned to a job is their parent were assigned at the time they started. So this was a race condition. I now create the process suspended, assign it to the job and then resume it. Which means all child processes are not running under the same job. b) First things, Is to prevent dangling child processes. I mark the job with `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` so when the last process in the job is done, it insures all processes under the job are killed. c) Secondly, I change the way we wait for results. Instead of waiting for the parent process to terminate, I wait for the job itself to terminate. There's a slight subtlety there, we can't wait on the job itself. Instead we have to create an I/O Completion port and wait for signals on it. See https://blogs.msdn.microsoft.com/oldnewthing/20130405-00/?p=4743 This fixes the issues on all runtimes for me and makes T7307 pass consistenly. The threading was also simplified by hiding all the locking in a single semaphore and a completion class. Futhermore some additional error reporting was added. For encoding the testsuite now no longer passes a file handle to the subprocess since on windows, sh.exe seems to acquire a lock on the file that is not released in a timely fashion. I suspect this because cygwin seems to emulate console handles by creating file handles and using those for std handles. So when we give it an existing file handle it just locks the file. I what's happening is that it's not releasing the handle until all shared cygwin processes are dead. Which explains why it worked in single threaded mode. So now instead we pass a pipe and do not interpret the resulting data. Any bytes written to stdin or read out of stdout/stderr are done so in binary mode and we do not interpret the data. The reason for this is that we have encoding tests in GHC which pass invalid utf-8. If we try to handle the data as text then python will throw an exception instead of a test comparison failing. Also I have fixed the ability to override `PYTHON` when calling `make tests`. This now works the same as with `.\validate`. Finally, after cleaning up the locks I was able to make the abort behavior work correctly as I believe it was intended: when you press Ctrl+C and send an interrupt signal, the testsuite finishes the active tests and then gracefully exits showing you a report of the progress it did make. So using Ctrl+C will not just *die* as it did before. These changes lift the restriction on which python version you use (msys/mingw) or which runtime or python 3 or python 2. All combinations should now be supported. Test Plan: PATH=/usr/local/bin:/mingw64/bin:$APPDATA/cabal/bin:$PATH && PYTHON=/usr/bin/python THREADS=9 make test THREADS=9 make test PATH=/usr/local/bin:/mingw64/bin:$APPDATA/cabal/bin:$PATH && PYTHON=/usr/bin/python ./validate --quiet --testsuite-only Reviewers: erikd, RyanGlScott, bgamari, austin Subscribers: jrtc27, mpickering, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2684 GHC Trac Issues: #12725, #12554, #12661, #12004 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:13:54 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.c9cefe01a2ddf8a7a6d48a5abb6dd65d@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"0ce59be3a2723f814a3e929fd32a44ff4e890a49/ghc" 0ce59be/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ce59be3a2723f814a3e929fd32a44ff4e890a49" Fix testsuite threading, timeout, encoding and performance issues on Windows In a land far far away, a project called Cygwin was born. Cygwin used newlib as it's standard C library implementation. But Cygwin wanted to emulate POSIX systems as closely as possible. So it implemented `execv` using the Windows function `spawnve`. Specifically ``` spawnve (_P_OVERLAY, path, argv, cur_environ ()) ``` `_P_OVERLAY` is crucial, as it makes the function behave *sort of* like execv on linux. the child process replaces the original process. With one major difference because of the difference in process models on Windows: the original process signals the caller that it's done. this is why the file is still locked. because it's still running, control was returned because the parent process was destroyed, but the child is still running. I think it's just pure dumb luck, that the older runtimes are slow enough to give the process time to terminate before we tried deleting the file. Which explains why you do have sporadic failures even on older runtimes like 2.5.0, of a test or two (like T7307). So this patch fixes a couple of things. I leverage the existing `timeout.exe` to implement a workaround for this issue. a) The old timeout used to start the process then assign it to the job. This is slightly faulty since child processes are only assigned to a job is their parent were assigned at the time they started. So this was a race condition. I now create the process suspended, assign it to the job and then resume it. Which means all child processes are not running under the same job. b) First things, Is to prevent dangling child processes. I mark the job with `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` so when the last process in the job is done, it insures all processes under the job are killed. c) Secondly, I change the way we wait for results. Instead of waiting for the parent process to terminate, I wait for the job itself to terminate. There's a slight subtlety there, we can't wait on the job itself. Instead we have to create an I/O Completion port and wait for signals on it. See https://blogs.msdn.microsoft.com/oldnewthing/20130405-00/?p=4743 This fixes the issues on all runtimes for me and makes T7307 pass consistenly. The threading was also simplified by hiding all the locking in a single semaphore and a completion class. Futhermore some additional error reporting was added. For encoding the testsuite now no longer passes a file handle to the subprocess since on windows, sh.exe seems to acquire a lock on the file that is not released in a timely fashion. I suspect this because cygwin seems to emulate console handles by creating file handles and using those for std handles. So when we give it an existing file handle it just locks the file. I what's happening is that it's not releasing the handle until all shared cygwin processes are dead. Which explains why it worked in single threaded mode. So now instead we pass a pipe and do not interpret the resulting data. Any bytes written to stdin or read out of stdout/stderr are done so in binary mode and we do not interpret the data. The reason for this is that we have encoding tests in GHC which pass invalid utf-8. If we try to handle the data as text then python will throw an exception instead of a test comparison failing. Also I have fixed the ability to override `PYTHON` when calling `make tests`. This now works the same as with `.\validate`. Finally, after cleaning up the locks I was able to make the abort behavior work correctly as I believe it was intended: when you press Ctrl+C and send an interrupt signal, the testsuite finishes the active tests and then gracefully exits showing you a report of the progress it did make. So using Ctrl+C will not just *die* as it did before. These changes lift the restriction on which python version you use (msys/mingw) or which runtime or python 3 or python 2. All combinations should now be supported. Test Plan: PATH=/usr/local/bin:/mingw64/bin:$APPDATA/cabal/bin:$PATH && PYTHON=/usr/bin/python THREADS=9 make test THREADS=9 make test PATH=/usr/local/bin:/mingw64/bin:$APPDATA/cabal/bin:$PATH && PYTHON=/usr/bin/python ./validate --quiet --testsuite-only Reviewers: erikd, RyanGlScott, bgamari, austin Subscribers: jrtc27, mpickering, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2684 GHC Trac Issues: #12725, #12554, #12661, #12004 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:13:54 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.bfaeb22b789a991764a9145888a381fd@haskell.org> #12725: T7037 is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | Phab:D2759 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0ce59be3a2723f814a3e929fd32a44ff4e890a49/ghc" 0ce59be/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ce59be3a2723f814a3e929fd32a44ff4e890a49" Fix testsuite threading, timeout, encoding and performance issues on Windows In a land far far away, a project called Cygwin was born. Cygwin used newlib as it's standard C library implementation. But Cygwin wanted to emulate POSIX systems as closely as possible. So it implemented `execv` using the Windows function `spawnve`. Specifically ``` spawnve (_P_OVERLAY, path, argv, cur_environ ()) ``` `_P_OVERLAY` is crucial, as it makes the function behave *sort of* like execv on linux. the child process replaces the original process. With one major difference because of the difference in process models on Windows: the original process signals the caller that it's done. this is why the file is still locked. because it's still running, control was returned because the parent process was destroyed, but the child is still running. I think it's just pure dumb luck, that the older runtimes are slow enough to give the process time to terminate before we tried deleting the file. Which explains why you do have sporadic failures even on older runtimes like 2.5.0, of a test or two (like T7307). So this patch fixes a couple of things. I leverage the existing `timeout.exe` to implement a workaround for this issue. a) The old timeout used to start the process then assign it to the job. This is slightly faulty since child processes are only assigned to a job is their parent were assigned at the time they started. So this was a race condition. I now create the process suspended, assign it to the job and then resume it. Which means all child processes are not running under the same job. b) First things, Is to prevent dangling child processes. I mark the job with `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` so when the last process in the job is done, it insures all processes under the job are killed. c) Secondly, I change the way we wait for results. Instead of waiting for the parent process to terminate, I wait for the job itself to terminate. There's a slight subtlety there, we can't wait on the job itself. Instead we have to create an I/O Completion port and wait for signals on it. See https://blogs.msdn.microsoft.com/oldnewthing/20130405-00/?p=4743 This fixes the issues on all runtimes for me and makes T7307 pass consistenly. The threading was also simplified by hiding all the locking in a single semaphore and a completion class. Futhermore some additional error reporting was added. For encoding the testsuite now no longer passes a file handle to the subprocess since on windows, sh.exe seems to acquire a lock on the file that is not released in a timely fashion. I suspect this because cygwin seems to emulate console handles by creating file handles and using those for std handles. So when we give it an existing file handle it just locks the file. I what's happening is that it's not releasing the handle until all shared cygwin processes are dead. Which explains why it worked in single threaded mode. So now instead we pass a pipe and do not interpret the resulting data. Any bytes written to stdin or read out of stdout/stderr are done so in binary mode and we do not interpret the data. The reason for this is that we have encoding tests in GHC which pass invalid utf-8. If we try to handle the data as text then python will throw an exception instead of a test comparison failing. Also I have fixed the ability to override `PYTHON` when calling `make tests`. This now works the same as with `.\validate`. Finally, after cleaning up the locks I was able to make the abort behavior work correctly as I believe it was intended: when you press Ctrl+C and send an interrupt signal, the testsuite finishes the active tests and then gracefully exits showing you a report of the progress it did make. So using Ctrl+C will not just *die* as it did before. These changes lift the restriction on which python version you use (msys/mingw) or which runtime or python 3 or python 2. All combinations should now be supported. Test Plan: PATH=/usr/local/bin:/mingw64/bin:$APPDATA/cabal/bin:$PATH && PYTHON=/usr/bin/python THREADS=9 make test THREADS=9 make test PATH=/usr/local/bin:/mingw64/bin:$APPDATA/cabal/bin:$PATH && PYTHON=/usr/bin/python ./validate --quiet --testsuite-only Reviewers: erikd, RyanGlScott, bgamari, austin Subscribers: jrtc27, mpickering, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2684 GHC Trac Issues: #12725, #12554, #12661, #12004 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:13:54 -0000 Subject: [GHC] #12004: Windows unexpected failures In-Reply-To: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> References: <045.5ea81afe7a35bbc5a069ce4325c9151d@haskell.org> Message-ID: <060.dcd53b096309488142f691f21eac26bc@haskell.org> #12004: Windows unexpected failures -------------------------------------+------------------------------------- Reporter: enolan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | Phab:D2759 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dd9ba503bd4a2b3851098a7fa69e15682ab1c536/ghc" dd9ba50/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dd9ba503bd4a2b3851098a7fa69e15682ab1c536" Update test output for Windows Following D2684 these two tests need to be updated: * T7037: timeout.exe now waits until all processes are finished. this makes T7037 reliable. So enabled. * T876: Unknown reason, allocations are much lower than before. Test Plan: ./validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2759 GHC Trac Issues: #12725, #12004 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:13:54 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.c86ab7059fcce43ca77c2903c2e4b5e6@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | ------------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"20c06143a7bfc6548351e610350a8e1c0d8a0bb9/ghc" 20c06143/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="20c06143a7bfc6548351e610350a8e1c0d8a0bb9" Update Mingw-w64 bindist for Windows This updates the binary dists for windows to GCC 6.2.0 and binutils 2.27.2 which has fixes required for LLVM. Test Plan: ./validate Reviewers: simonmar, erikd, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2749 GHC Trac Issues: #12871, #8974 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:13:54 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.705e5b0741099c33372b99e81858fc08@haskell.org> #12725: T7037 is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | Phab:D2759 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dd9ba503bd4a2b3851098a7fa69e15682ab1c536/ghc" dd9ba50/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dd9ba503bd4a2b3851098a7fa69e15682ab1c536" Update test output for Windows Following D2684 these two tests need to be updated: * T7037: timeout.exe now waits until all processes are finished. this makes T7037 reliable. So enabled. * T876: Unknown reason, allocations are much lower than before. Test Plan: ./validate Reviewers: austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2759 GHC Trac Issues: #12725, #12004 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:13:54 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.df06c3b449908157ea47f08cdfda1eb8@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"605bb9b4608121c462fb3d9f9281e7427f7ccc72/ghc" 605bb9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="605bb9b4608121c462fb3d9f9281e7427f7ccc72" testsuite: Use python3 by default Summary: It turns out that Phyx's fix for #12554 (D2684) still fails with mingw-w64 python 2.7. However, Python 3 (both msys2 and mingw-w64) work fine. Given that supporting Python 2 has already become rather tiresome (as @thomie warned it would), let's just move to python3 by default. Test Plan: Validate Reviewers: austin, Phyx Reviewed By: Phyx Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2766 GHC Trac Issues: #12554 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:13:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:13:54 -0000 Subject: [GHC] #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 In-Reply-To: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> References: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> Message-ID: <059.6c092c9945ed9ee30abe1fbe422c2d3a@haskell.org> #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"20c06143a7bfc6548351e610350a8e1c0d8a0bb9/ghc" 20c06143/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="20c06143a7bfc6548351e610350a8e1c0d8a0bb9" Update Mingw-w64 bindist for Windows This updates the binary dists for windows to GCC 6.2.0 and binutils 2.27.2 which has fixes required for LLVM. Test Plan: ./validate Reviewers: simonmar, erikd, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2749 GHC Trac Issues: #12871, #8974 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:16:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:16:32 -0000 Subject: [GHC] #12554: Testsuite exhibits large amount of framework failures In-Reply-To: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> References: <044.21e24ec5b622fd576e24d33b5e3b81ac@haskell.org> Message-ID: <059.91924ee99d61c6305857cfa74ba5d308@haskell.org> #12554: Testsuite exhibits large amount of framework failures -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: This should at long last be fixed by the above two patches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:17:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:17:13 -0000 Subject: [GHC] #12725: T7037 is broken on Windows In-Reply-To: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> References: <046.1d13a5b9c4eac32c3a44a7d2083f2c48@haskell.org> Message-ID: <061.6eb9b63f9374e06418286b49b211590d@haskell.org> #12725: T7037 is broken on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2684 Wiki Page: | Phab:D2759 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed @@ -3,1 +3,1 @@ - the `execv` call failing but this doesn't seem to be thew case; no code + the `execv` call failing but this doesn't seem to be the case; no code New description: `T7037` appears to fail on Windows. Namely, `stdout` appears to be empty, whereas the expected output is `"ok"`. I had suspected that the issue was the `execv` call failing but this doesn't seem to be the case; no code after `execv` is executed. A problem for another day... -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:18:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:18:28 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.fecabc816e48a7fce12f79147e7191a6@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I think this is now as fixed as it is going to be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:20:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:20:03 -0000 Subject: [GHC] #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 In-Reply-To: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> References: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> Message-ID: <059.30cb5aa3fc70624025878f8349b82d13@haskell.org> #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:20:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:20:27 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.56d4bcd892992e0ddce79fdb72a8e1a5@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults ------------------------------------+-------------------------------------- Reporter: awson | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | ------------------------------------+-------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This should be fixed with the toolchain bump. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:45:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:45:11 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.51e111a8964adc5ae2f24b5ac899af5a@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): +1 to comment:15 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 02:47:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 02:47:46 -0000 Subject: [GHC] #12900: Common up identical info tables Message-ID: <047.1ac34d5a9db6e2754edb76e031d69a42@haskell.org> #12900: Common up identical info tables -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{#!hs data Bool' = No | Yes }}} It is clear that this is identical to `Bool` at runtime, and so GHC should be able to reuse `Bool`'s code. The same holds for all other pairs of isomorphic data types. I think that a **massive** space savings could be achieved this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 04:46:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 04:46:28 -0000 Subject: [GHC] #12901: Levity polymorphic expressions mustn't be floated out Message-ID: <045.824b9429e978b9ce967c7d331fdd0c97@haskell.org> #12901: Levity polymorphic expressions mustn't be floated out -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have been trying to add the following code into GHC: {{{#!hs {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ViewPatterns #-} pattern AppOp1 :: PrimOp -> Arg CoreBndr -> CoreExpr pattern OpVal :: PrimOp -> Arg CoreBndr pattern AppOp1 op x = App (OpVal op) x pattern OpVal op <- Var (isPrimOpId_maybe -> Just op) where OpVal op = Var (mkPrimOpId op) }}} It triggers the following CoreLint error: {{{ : warning: [RHS of lvl_spfb :: r] RuntimeRep-polymorphic binder: lvl_spfb :: (r :: TYPE rep) }}} Indeed: {{{#!hs $mAppOp1 :: forall (r :: TYPE rep). CoreExpr -> (PrimOp -> Arg CoreBndr -> r) -> (Void# -> r) -> r [LclIdX, Arity=3] $mAppOp1 = \ (@ (rep_agRe :: RuntimeRep)) (@ (r_agRf :: TYPE rep)) (scrut_agRh :: CoreExpr) (cont_agRi :: PrimOp -> Arg CoreBndr -> r) (fail_agRj :: Void# -> r) -> let { fail_spbW :: Void# -> r [LclId, Arity=1] fail_spbW = \ _ [Occ=Dead, OS=OneShot] -> fail_agRj void# } in let { lvl_spfb :: r [LclId] lvl_spfb = fail_spbW void# } in case scrut_agRh of { __DEFAULT -> fail_spbW void#; App ds_dj2u x_afoV -> $mOpVal @ rep @ r ds_dj2u (\ (op_afoU :: PrimOp) -> cont_agRi op_afoU x_afoV) (\ _ [Occ=Dead] -> lvl_spfb) }}} According to the levity polymorphism paper `lvl_spfb` shouldn't have been floated out in a let-binding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 04:48:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 04:48:33 -0000 Subject: [GHC] #12901: Levity polymorphic expressions mustn't be floated out In-Reply-To: <045.824b9429e978b9ce967c7d331fdd0c97@haskell.org> References: <045.824b9429e978b9ce967c7d331fdd0c97@haskell.org> Message-ID: <060.23a391b936267cb939e52267c2ec9a6a@haskell.org> #12901: Levity polymorphic expressions mustn't be floated out -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2769 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D2769 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 07:58:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 07:58:37 -0000 Subject: [GHC] #12900: Common up identical info tables In-Reply-To: <047.1ac34d5a9db6e2754edb76e031d69a42@haskell.org> References: <047.1ac34d5a9db6e2754edb76e031d69a42@haskell.org> Message-ID: <062.1944091d91e8a47d7420859532fae5d5@haskell.org> #12900: Common up identical info tables -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I've been thinking about this idea for a while, I think it's a great idea. I'd be willing to work on that if @simonpj or others can comment on how possible this is. I agree that we could save massive amount of space. I think what we can do is, we can give same info tables same names, so if we have {{{#!haskell data X = A | B data Bool = True | False }}} Both of these get the same info table `hs_s_s_info` (`s` is for "singleton"). Similarly, {{{#!haskell data Either a b = Left a | Right b }}} gets info table `hs_p_p_info` ('p' is for "pointer") etc. Then when linking we ignore multiple definitions of same info table symbols (not sure if this is possible easily). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 08:34:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 08:34:43 -0000 Subject: [GHC] #12900: Common up identical info tables In-Reply-To: <047.1ac34d5a9db6e2754edb76e031d69a42@haskell.org> References: <047.1ac34d5a9db6e2754edb76e031d69a42@haskell.org> Message-ID: <062.27e89257c53070d36df014091b271270@haskell.org> #12900: Common up identical info tables -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): We discussed this on the IRC channel and @ezyang pointed out two things: - Assuming this is only for merging same info tables, we can go even further by reordering fields so that {{{data T1 = T1 Int# Bool}}} and {{{data T2 = T2 Bool Int#}}} would get same info tables. This obviously needs a lot more work but saves more space. - This breaks {{{-h}}} which works even in non-profiled mode. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 08:58:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 08:58:26 -0000 Subject: [GHC] #8516: Add (->) representation and the Invariant class to GHC.Generics In-Reply-To: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> References: <046.4bd98a18c7a25f1a7eb2c50c7cbb4858@haskell.org> Message-ID: <061.dd2ffd8acda2bdb7c0d6cf5a9ebe0537@haskell.org> #8516: Add (->) representation and the Invariant class to GHC.Generics -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by songzh): * cc: songzh (added) Comment: Replying to [ticket:8516 nfrisby]: > We currently disallow any use of the parameter in the domain of (->). > > {{{ > newtype F a = F ((a -> Int) -> Int) deriving Generic1 > > :4:38: > Can't make a derived instance of `Generic1 (F g)': > Constructor `F' must use the last type parameter only as the last argument of a data type, newtype, or (->) > In the data declaration for `F' > }}} > > !DeriveFunctor succeeds for this F. > > I'd like to add this representation type to GHC.Generics and !DeriveGeneric. > > {{{ > newtype (f :->: g) a = FArrow1 (f a -> g a) > }}} > > We could then represent the first example above. We could also derive the more interesting Generic1 (F g). > > {{{ > newtype F g a = F (g a -> Int) deriving Generic1 > > type instance Rep1 (F g) = Rec1 g :->: Rec0 Int > > instance Generic1 (F g) where > to x = F $ unRec0 . unArrow1 x . Rec1 > from (F x) = FArrow1 $ Rec0 . x . unRec1 > }}} > > Admittedly, there's not many generic definitions impeded by not having (:->:). Contra- and in-variant types are uncommon. > > I'm suggesting this feature without strong motivating examples because I think this would streamline the implementation of -XDeriveGenerics in some ways while also making it more general — assuming that we added the Invariant class to base or ghc-prim. > > {{{ > class Invariant t where > invmap :: (a -> b) -> (b -> a) -> t a -> t b > > invmap_covariant :: Functor t => (a -> b) -> (b -> a) -> t a -> t b > invmap_covariant f _ = fmap f > > instance (Invariant f,Invariant g) => Invariant (FArrow f g) where > invmap co contra (FArrow h) = FArrow $ invmap co contra . h . invmap contra co > }}} > > (Of course, Invariant should be a super class of Functor. :/ ) > > Now we can handle quite involved examples: > > {{{ > newtype F g h a = F (g (h a)) deriving Generic1 > > instance Invariant g => Generic1 (F g h) where > to x = invmap unRec1 Rec1 $ unComp1 x > from (F x) = Comp1 $ invmap Rec1 unRec1 > }}} > > All of that said, I'm mostly opening this ticket so I can get feedback on difficulties I might not be anticipating and have a place to reference from the compiler source code comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 09:30:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 09:30:28 -0000 Subject: [GHC] #12900: Common up identical info tables In-Reply-To: <047.1ac34d5a9db6e2754edb76e031d69a42@haskell.org> References: <047.1ac34d5a9db6e2754edb76e031d69a42@haskell.org> Message-ID: <062.45ed26317b7544078ba7f115a43a05a0@haskell.org> #12900: Common up identical info tables -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Why do you say "massive" amount of space? Do you have data? My guess would be that, except in pathological situation (e.g. thousands of identical data types) the saving would be vanishingly small. Also I think that info tables contain strings that identify the type for debuggers etc; ghci has such a debugger built in. You'd lose this entirely. So I'm a skeptical that the gain justifies the pain (implementation complexity, loss of functionality). But data might convince! If you are looking for code space saving, then I think a more profitable place might be commoning up bits of Cmm code. E.g. consider {{{ f x y = case x of True -> False; False -> y }}} We push a return address, evaluate `x`; when we come back we take a conditional jump based on the tag and, in the `True` case we just return a fixed constructor `False`. Lots of code just returns `False`! If all that code was commoned up, we might get a big space saving. Maybe there are some sequences that are SO common we can put them in a big library, always available in the RTS, so all libraries could share. We'd need automation to find these common sequences and see which ones happened a lot. I remember a PhD student trying this years ago (20 yrs?) with some success. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 09:44:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 09:44:41 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.bd015014b6c9b82b8ba7f5943094fcb8@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jystic): * cc: jystic (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 09:48:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 09:48:43 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.7d9fe8e125772b84d6968308fd44254f@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @awson never put his patches up. So at the moment, `-split-sections` does not work on PE targets. So no, you can't flip it on yet. I'm working on getting things up and running. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 09:57:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 09:57:48 -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.5dceb44aee53e4ccddbcc3202f8a0efe@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by olsner): Replying to [comment:24 dobenour]: > I think we can deprecate it on other systems too, except (possibly) OS X (which I believe bundles Perl with the OS). I think GHC on OS X doesn't even support `-split-objs`, rather it uses the builtin subsections and `-dead_strip` linker flag, so that wouldn't be a blocker. It's just Windows support for split sections that we might want to wait for before we start ripping stuff out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 10:04:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 10:04:07 -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.0a6018f2d7ce3c61a8ca04348e6e924e@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Indeed. I'm working on the PE support. There is some experimental code in binutils but this is virtually untested code. It was added by copying the elf implementation and modifying it. The ones who implemented it did not have access to a Windows machine apparently so it was committed as experimental so people could provide feedback. But very little useful feedback was provided afaik. tl;dr: We will probably be the ones putting this through extensive testing. And I do expect some issues. So I have reservations dropping `split-objs` for `8.2` unless we get this tested enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 10:32:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 10:32:33 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2312828=3A_Generalize_functions_from_?= =?utf-8?b?RGF0YS5NYXliZSAo4oCYY2F0TWF5YmVz4oCZLCDigJhtYXBNYXli?= =?utf-8?b?ZeKAmSk=?= In-Reply-To: <051.dbb4ef05364e6c4421b04dd57fb22742@haskell.org> References: <051.dbb4ef05364e6c4421b04dd57fb22742@haskell.org> Message-ID: <066.28d3a8718c894c43382b6cfd7f66f5b7@haskell.org> #12828: Generalize functions from Data.Maybe (‘catMaybes’, ‘mapMaybe’) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Made a [https://mail.haskell.org/pipermail/libraries/2016-November/027453.html thread]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 10:54:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 10:54:17 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core In-Reply-To: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> References: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> Message-ID: <061.9088160f7d5e660c3e631097f66552a4@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Typeable, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: Typeable => Typeable, LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 11:22:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 11:22:32 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.64f72bb2ad29adc38d485cdee4604120@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. I followed your repro steps above, and it all worked fine... not `Iface Id out of scope`. Here's the last two steps {{{ simonpj at cam-05-unx:~/tmp/LambdaHack/LambdaHack$ touch GameDefinition/Main.hs simonpj at cam-05-unx:~/tmp/LambdaHack/LambdaHack$ cabal build --ghc-option =-fsimpl-tick-factor=200 Building LambdaHack-0.5.1.0... Preprocessing library LambdaHack-0.5.1.0... Preprocessing executable 'LambdaHack' for LambdaHack-0.5.1.0... [15 of 15] Compiling Main ( GameDefinition/Main.hs, dist/build/LambdaHack/LambdaHack-tmp/Main.o ) Linking dist/build/LambdaHack/LambdaHack ... }}} The first step failed, so I skipped it. {{{ bash$ git checkout master error: pathspec 'master' did not match any file(s) known to git. bash$ git branch * simplifying-threaded-mode }}} Maybe we should give up on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 11:28:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 11:28:32 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.e1fbdf58a891f7ffcea9ea27f1b0e34d@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Oh, I'm sorry, I asked you to make a clone with only one branch, so no wonder it has no others. Please start with {{{ git clone https://github.com/LambdaHack/LambdaHack.git }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 11:28:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 11:28:37 -0000 Subject: [GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM In-Reply-To: <045.352c8bb25c33b092176709513059d519@haskell.org> References: <045.352c8bb25c33b092176709513059d519@haskell.org> Message-ID: <060.f4e7aa6ba48c12a577a59b7fda28705c@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 11:55:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 11:55:21 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.cd133ddd18b571e5e3061ac1b9121772@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * status: new => closed * resolution: => invalid Comment: Hmm, but then, the commit exists also on that branch. So apparently you can't reproduce that. I will try this myself again when I install 8.0.2 or 8.0.3 and open a new ticket, if the problem persists for me. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 11:57:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 11:57:41 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.6c20aee8a9dc5196de3fd6a503c29373@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): BTW, should I open a new bug report with the panic I spotted in the travis log? (https://api.travis-ci.org/jobs/179766413/log.txt?deansi=true) {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161125 for x86_64-unknown-linux): Can't serialise IfaceTcTyVar u_aDzT[sk:1] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/iface/IfaceType.hs:1331:10 in ghc:IfaceType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 12:43:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 12:43:23 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.3458cb68945405f5e16faaff8afc8db6@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): `Can't serialise IfaceTcTyVar`: This will be very recent (ie HEAD only). I fixed one of these yesterday; can you try again? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 12:50:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 12:50:27 -0000 Subject: [GHC] #12902: Improve handle decoding error messages Message-ID: <049.84b11ac5d1612376fb2833134fa62843@haskell.org> #12902: Improve handle decoding error messages -------------------------------------+------------------------------------- Reporter: Profpatsch | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When handle decoding encounters a byte sequence it cannot handle and `ErrorOnCodingFailure` is set, at the moment [https://hackage.haskell.org/package/base-4.9.0.0/docs/src/GHC.IO.Encoding.Failure.html#ioe_decodingError an IO error with a pretty non-descriptive messages is thrown] (`invalid byte sequence`). The user should get a bit more Information in that case: 1) What was the byte sequence that caused the error (and if possible where in the input, of course hard with handles) 2) A stack trace of the functions that caused this (probably from `hGetContents` and similar upwards It’s a very hard-to-debug error with the current implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 12:50:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 12:50:52 -0000 Subject: [GHC] #12902: Improve handle decoding error messages In-Reply-To: <049.84b11ac5d1612376fb2833134fa62843@haskell.org> References: <049.84b11ac5d1612376fb2833134fa62843@haskell.org> Message-ID: <064.ff7eea16084195437d379d1c53a41340@haskell.org> #12902: Improve handle decoding error messages -------------------------------------+------------------------------------- Reporter: Profpatsch | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Profpatsch: @@ -13,1 +13,1 @@ - `hGetContents` and similar upwards + `hGetContents` and similar upwards) New description: When handle decoding encounters a byte sequence it cannot handle and `ErrorOnCodingFailure` is set, at the moment [https://hackage.haskell.org/package/base-4.9.0.0/docs/src/GHC.IO.Encoding.Failure.html#ioe_decodingError an IO error with a pretty non-descriptive messages is thrown] (`invalid byte sequence`). The user should get a bit more Information in that case: 1) What was the byte sequence that caused the error (and if possible where in the input, of course hard with handles) 2) A stack trace of the functions that caused this (probably from `hGetContents` and similar upwards) It’s a very hard-to-debug error with the current implementation. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 12:51:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 12:51:42 -0000 Subject: [GHC] #12832: GHC infers too simplified contexts In-Reply-To: <046.c1f3ff2a9ca4d830d3e52f2f57c4f3ec@haskell.org> References: <046.c1f3ff2a9ca4d830d3e52f2f57c4f3ec@haskell.org> Message-ID: <061.b5c3dc3508aa82158763db45194a64d3@haskell.org> #12832: GHC infers too simplified contexts -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There is a reason for this behaviour. I won't say that it is a ''good'' reason, but it's not an accident. See this note in `TcInstDcls`: {{{ Note [Subtle interaction of recursion and overlap] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider this class C a where { op1,op2 :: a -> a } instance {-# OVERLAPPING #-} C [Int] where ... instance {-# OVERLAPPABLE #-} C a => C [a] where op1 x = op2 x ++ op2 x op2 x = ... ... When type-checking the C [a] instance, we need a C [a] dictionary (for the call of op2). If we look up in the instance environment, we find an overlap. And in *general* the right thing is to complain (see Note [Overlapping instances] in InstEnv). But in *this* case it's wrong to complain, because we just want to delegate to the op2 of this same instance. Why is this justified? Because we generate a (C [a]) constraint in a context in which 'a' cannot be instantiated to anything that matches other overlapping instances, or else we would not be executing this version of op1 in the first place. It might even be a bit disguised: nullFail :: C [a] => [a] -> [a] nullFail x = op2 x ++ op2 x instance C a => C [a] where op1 x = nullFail x Precisely this is used in package 'regex-base', module Context.hs. See the overlapping instances for RegexContext, and the fact that they call 'nullFail' just like the example above. The DoCon package also does the same thing; it shows up in module Fraction.hs. Conclusion: when typechecking the methods in a C [a] instance, we want to treat the 'a' as an *existential* type variable, in the sense described by Note [Binding when looking up instances]. That is why isOverlappableTyVar responds True to an InstSkol, which is the kind of skolem we use in tcInstDecl2. }}} In your example, from {{{ instance Run m Int where run = test }}} we get a Wanted `[W] Test m Int` constraint. Because it's in an instance decl, the `m` type variable has the above magic overlap property, we apply the instance declaration to get `[W] (Foo m, Bar m, Baz m)`. I don't say this is great, but I'm not sure what else to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 12:53:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 12:53:06 -0000 Subject: [GHC] #12587: InstanceSigs doesn't work with ambigous types In-Reply-To: <048.684ad96c32ef897522b527a46dc2a754@haskell.org> References: <048.684ad96c32ef897522b527a46dc2a754@haskell.org> Message-ID: <063.3adb035258c6afa6f134ec732bf75097@haskell.org> #12587: InstanceSigs doesn't work with ambigous types -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: In your instance decl (I have renamed the forall'd variable). {{{ instance Bar Int where bar :: forall c. (Foo c) => Int -- error here bar = undefined where x :: c x = undefined }}} GHC is trying to check that the instance signature you ''provide'': {{{ bar :: forall c. Foo c => Int }}} is more general than the one that is ''required'': {{{ bar :: forall b. Foo b => Int }}} To to that it * instantiates the required one, giving `[W] Foo b0` * unifies provided and requied types `Int ~ Int` * checks that it can prove the required `[W] Foo b0` from the given `Foo c`. But it can't prove that because nothing tells GHC to instantiate `b0` to `c`. I think this is fair enough: it really is an ambiguous type. The same thing would happen if you used an auxiliary function {{{ instance Bar Int where bar = barInt barInt :: forall c. (Foo c) => Int -- error here barInt = undefined where x :: c x = undefined }}} Indeed, it'd be surprising if this didn't work but the previous code did. So I think it's fine. Yell if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 13:43:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 13:43:55 -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.22ced67e7bc968ea81915108752a5e0d@haskell.org> #10510: Testsuite driver does not run tests in parallel on Windows ---------------------------------+---------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Test Suite | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This has been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 13:57:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 13:57:10 -0000 Subject: [GHC] #12903: SIGINT is not handled in forked process Message-ID: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> #12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If haskell program is forked in a toplevel hander that sends UserInterrupt in the main thread doesn't work, because Thread 1 doesn't exists in forked program, so that action is noop. Minimal example: {{{#!hs import Control.Concurrent import Control.Exception import System.Posix main = do pid <- forkProcess $ do handle (\UserInterrupt{} -> putStrLn "caught") $ threadDelay 2000000 signalProcess sigINT pid threadDelay 2000000 }}} Expected result: "caught" printed to stdout. Actual result: nothing is printed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 14:03:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 14:03:02 -0000 Subject: [GHC] #12903: SIGINT is not handled in forked process In-Reply-To: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> References: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> Message-ID: <060.0263411fbffbb2a63d5ee737f4f539fd@haskell.org> #12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by qnikst): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 14:05:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 14:05:04 -0000 Subject: [GHC] #12903: SIGINT is not handled in forked process In-Reply-To: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> References: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> Message-ID: <060.be3b1ebba27c438577b606a9a747de52@haskell.org> #12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2770 Wiki Page: | -------------------------------------+------------------------------------- Changes (by qnikst): * differential: => Phab:D2770 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 14:26:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 14:26:37 -0000 Subject: [GHC] #12843: Simplifier ticks exhausted When trying UnfoldingDone $ In-Reply-To: <054.387101971e684cfe92badff94537620a@haskell.org> References: <054.387101971e684cfe92badff94537620a@haskell.org> Message-ID: <069.e7b29aad11bf86062ddbe3681e7c197e@haskell.org> #12843: Simplifier ticks exhausted When trying UnfoldingDone $ -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12776 #12789 | Differential Rev(s): #12675 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Oh, great, thanks for the fix. I just tried and it failed, but the HEAD on travis is ghc-head_8.1.20161125+git.0.f8c966c, so your fix is not yet included. If the problem persists when the HEAD is updated on travis, I will open a new ticket. BTW, I've tried on travis and couldn't reproduce `Iface Id out of scope` on any GHC version, with any optimization flags, so I'd probably need to recompile in a sandbox on my machine and attach sandbox config for reproduction, which is probably too much trouble for anybody willing to investigate (assuming it's enough to repro). Let's hope somebody finds a less fragile example or that it's caused by some bitrot on my machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 14:34:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 14:34:42 -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.6b97038af5207b2a5f1c839212217d8c@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by dobenour): Is there some reason we can't just use the Microsoft linker on Windows? It has supported the equivalent of `--gc-sections` since forever. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 14:39:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 14:39:12 -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.976938130711de0d5c18f9e90d8cd6a3@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by dobenour): Replying to [comment:26 olsner]: > Replying to [comment:24 dobenour]: > > I think we can deprecate it on other systems too, except (possibly) OS X (which I believe bundles Perl with the OS). > > I think GHC on OS X doesn't even support `-split-objs`, rather it uses the builtin subsections and `-dead_strip` linker flag, so that wouldn't be a blocker. > > It's just Windows support for split sections that we might want to wait for before we start ripping stuff out. In that case, the Darwin support in the splitter is dead code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 15:22:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 15:22:14 -0000 Subject: [GHC] #12792: Wrong error message when using a data type as a class instance head In-Reply-To: <046.395f5e366c8e645bf9b11f3e4c1c270f@haskell.org> References: <046.395f5e366c8e645bf9b11f3e4c1c270f@haskell.org> Message-ID: <061.9ac99980e37d349d4a22663348968e20@haskell.org> #12792: Wrong error message when using a data type as a class instance head -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: newcomer => Comment: I sort of agree but it's architecturally difficult. * The "not a visible method" message comes from the renamer * The kind error comes from the type checker It's not clear to me how to make the latter suppress the former. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 15:24:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 15:24:30 -0000 Subject: [GHC] #12900: Common up identical info tables In-Reply-To: <047.1ac34d5a9db6e2754edb76e031d69a42@haskell.org> References: <047.1ac34d5a9db6e2754edb76e031d69a42@haskell.org> Message-ID: <062.e7ffbf093ef3df7f8ec0d6197049f336@haskell.org> #12900: Common up identical info tables -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): simonpj: I remember reading that one of the reasons GHC-compiled binaries tend to be large is that each data type has its own info table and entry code. I suspect that most data types have one of a few common forms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 15:25:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 15:25:07 -0000 Subject: [GHC] #12792: Wrong error message when using a data type as a class instance head In-Reply-To: <046.395f5e366c8e645bf9b11f3e4c1c270f@haskell.org> References: <046.395f5e366c8e645bf9b11f3e4c1c270f@haskell.org> Message-ID: <061.d66e858dea012f50fd8fed68daa951e5@haskell.org> #12792: Wrong error message when using a data type as a class instance head -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Do we need full kind-checking? The renamer already knows the concrete TyCon that is heading the instance. Shouldn’t `isClassTyCon` be sufficient here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 15:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 15:26:59 -0000 Subject: [GHC] #12792: Wrong error message when using a data type as a class instance head In-Reply-To: <046.395f5e366c8e645bf9b11f3e4c1c270f@haskell.org> References: <046.395f5e366c8e645bf9b11f3e4c1c270f@haskell.org> Message-ID: <061.6022d6b882685abb8889d3e9801ecd70@haskell.org> #12792: Wrong error message when using a data type as a class instance head -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): We don't have `TyCon`s in the renamer; only `Name`s. (Unless imported, or from an earlier GHCi line. So yes, for imported things one could do better. Maybe that is useful enough to do.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 15:30:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 15:30:36 -0000 Subject: [GHC] #1791: heap overflow should generate an exception In-Reply-To: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> References: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> Message-ID: <059.a0fa108253276df9d6c610898019a6fa@haskell.org> #1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 6.8 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * cc: simonmar (added) Comment: How difficult would this be to actually implement? I can think of several valid use cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 15:47:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 15:47:16 -0000 Subject: [GHC] #12900: Common up identical info tables In-Reply-To: <047.1ac34d5a9db6e2754edb76e031d69a42@haskell.org> References: <047.1ac34d5a9db6e2754edb76e031d69a42@haskell.org> Message-ID: <062.28cd5253520fe44ea46050f381dd1d15@haskell.org> #12900: Common up identical info tables -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Maybe start by measuring the total code size used by constructors (say in the `ghc` library itself). Slightly tricky because the starts of info tables aren't marked by symbols, I think. I'd be surprised if they account for more than about 10% of the total code size, myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 15:52:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 15:52:12 -0000 Subject: [GHC] #12792: Wrong error message when using a data type as a class instance head In-Reply-To: <046.395f5e366c8e645bf9b11f3e4c1c270f@haskell.org> References: <046.395f5e366c8e645bf9b11f3e4c1c270f@haskell.org> Message-ID: <061.2c3d86ad43736d6a96584c0a3cf28bab@haskell.org> #12792: Wrong error message when using a data type as a class instance head -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Unless imported, or from an earlier GHCi line. So yes, for imported things one could do better. Maybe that is useful enough to do. I think it would. (I’m still not convined that it’s not possible otherwise. If the renamer knows about what “Names” have which “methods” (and it seems it does, given the error message), then surely it must know what “Names” can have “methods” in the first place – namely classes. But I should just try it myself, or at least read the code carefully, instead of rambling here.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 16:00:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 16:00:10 -0000 Subject: [GHC] #1791: heap overflow should generate an exception In-Reply-To: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> References: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> Message-ID: <059.2d2215d474ee13f7e684670597a946e8@haskell.org> #1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 6.8 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by rwbarton: @@ -0,0 +1,10 @@ + Heap overflow should produce a `HeapOverflow` exception that can be + caught, rather than shutting down the entire RTS immediately. + + [Original ticket description follows. The submitter happened to expose + another bug, which was that heap overflow was not detected at all when a + single allocation exceeded the maximum heap size. The program below now + exits with a "Heap exhausted" message.] + + ---- + New description: Heap overflow should produce a `HeapOverflow` exception that can be caught, rather than shutting down the entire RTS immediately. [Original ticket description follows. The submitter happened to expose another bug, which was that heap overflow was not detected at all when a single allocation exceeded the maximum heap size. The program below now exits with a "Heap exhausted" message.] ---- I want to use the -M option for the goals that are stated in the manual. {{{ ./TestProgram +RTS -M5m -RTS }}} Expected output: {{{ Something like "out of heap space" }}} Actual result: {{{ Machine going into a state where it swaps memory }}} This is the code for TestProgram: {{{ import Control.Monad.ST import Data.Array.ST import Data.Array.MArray import Data.Array.Base(unsafeNewArray_) main = print (runST (do make_empty_table >> return ())) make_empty_table:: ST s (STArray s (Int, Int) (Maybe ep)) make_empty_table = unsafeNewArray_ ((1, 1), (16384, 16384)) }}} This was tested with 6.9.20071018 on an athlon-xp, and confirmed by dcoutts also on x86-64 with ghc-6.8.0.20071015. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 16:04:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 16:04:21 -0000 Subject: [GHC] #1791: heap overflow should generate an exception In-Reply-To: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> References: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> Message-ID: <059.2d1ec2ee9e568fd6b5e8404dfbd79c40@haskell.org> #1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 6.8 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): There are a few questions to nail down, like under what precise conditions the exception is thrown, and to which threads. The actual implementation probably isn't all that difficult. Start by making a proposal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 18:06:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 18:06:28 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on all systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.0f1350f2dbb71df04ca05b90e168db69@haskell.org> #10352: Properly link Haskell shared libs on all systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5987 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: Phyx- => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 18:40:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 18:40:58 -0000 Subject: [GHC] #12898: Upgrade Stack failed In-Reply-To: <045.600c97de7624963d0388c4515db686d9@haskell.org> References: <045.600c97de7624963d0388c4515db686d9@haskell.org> Message-ID: <060.29d63589b39323fbc1fcd96e429ccdc4@haskell.org> #12898: Upgrade Stack failed ------------------------------+---------------------------------------- Reporter: Bugger | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------+---------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate Comment: Duplicate of #12479. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 18:48:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 18:48:32 -0000 Subject: [GHC] #12886: Proposal for throwLeft and throwLeftIO in Control.Exception In-Reply-To: <048.20cdb7217c9551470366c48ee53b317a@haskell.org> References: <048.20cdb7217c9551470366c48ee53b317a@haskell.org> Message-ID: <063.1b90dec1aabbb711cbbabd9e04b7b04b@haskell.org> #12886: Proposal for throwLeft and throwLeftIO in Control.Exception -------------------------------------+------------------------------------- Reporter: yfeldblum | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I thought the core libraries process was to make a proposal on `libraries@`? Was there one already? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 18:59:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 18:59:16 -0000 Subject: [GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM In-Reply-To: <045.352c8bb25c33b092176709513059d519@haskell.org> References: <045.352c8bb25c33b092176709513059d519@haskell.org> Message-ID: <060.6cf106c983ef8442ad83fe32f7feaa25@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) Comment: Yikes. Interestingly, the way the `Eq (Fix f)` instance is constructed plays a large role in the slowdown. Since it's a newtype, GHC defaults to deriving that instance via `GeneralizedNewtypeDeriving`, i.e., {{{#!hs instance Eq (f (Fix f)) => Eq (Fix f) where (==) = coerce ((==) :: f (Fix f) -> f (Fix f) -> Bool) :: Fix f -> Fix f -> Bool }}} But if you implement it the "stock" way, i.e., {{{#!hs instance Eq (f (Fix f)) => Eq (Fix f) where In x == In y = x == y }}} Then it compiles instantly. So perhaps the coercion solver is to blame here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 19:44:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 19:44:57 -0000 Subject: [GHC] #12833: GHCi In-Reply-To: <051.4ded213ac1a58670bab81411457b3c2f@haskell.org> References: <051.4ded213ac1a58670bab81411457b3c2f@haskell.org> Message-ID: <066.3ee2cd46e8c4b522592407c4f9a1fe5d@haskell.org> #12833: GHCi -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Well the simple answer is because `let type A = Int` is not valid Haskell, and the same for your other examples. I suppose we could implement this, but it seems needless (when `:{` exists) and confusing (it is irregular, and presumably wouldn't be supported in a Haskell source file). (Also, the title of this ticket is not very good.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 20:09:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 20:09:12 -0000 Subject: [GHC] #12904: GHC 7.10.3 Binary distribution is broken. Message-ID: <044.790a692aeebadd351e256bc3db3b65d9@haskell.org> #12904: GHC 7.10.3 Binary distribution is broken. --------------------------------+------------------------------------------ Reporter: Phyx- | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86 | Type of failure: Installing GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------------ The GHC i386 binary for Windows hosted on https://downloads.haskell.org/~ghc/7.10.3/ghc-7.10.3-i386-unknown- mingw32.tar.xz is broken. {{{ Tamar at Rage MINGW64 ~/Temp $ wget https://downloads.haskell.org/~ghc/7.10.3/ghc-7.10.3-i386-unknown- mingw32.tar.xz --2016-11-30 19:32:15-- https://downloads.haskell.org/~ghc/7.10.3/ghc-7.10.3-i386-unknown- mingw32.tar.xz Resolving downloads.haskell.org (downloads.haskell.org)... 151.101.16.68 Connecting to downloads.haskell.org (downloads.haskell.org)|151.101.16.68|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 131297148 (125M) [application/octet-stream] Saving to: ‘ghc-7.10.3-i386-unknown-mingw32.tar.xz’ ghc-7.10.3-i386-unknown-mingw32.tar.xz 100%[==========================================================================================================================================>] 125.21M 3.11MB/s in 42s 2016-11-30 19:32:58 (2.98 MB/s) - ‘ghc-7.10.3-i386-unknown-mingw32.tar.xz’ saved [131297148/131297148] Tamar at Rage MINGW64 ~/Temp $ xz -d ghc-7.10.3-i386-unknown-mingw32.tar.xz Tamar at Rage MINGW64 ~/Temp $ tar xf ghc-7.10.3-i386-unknown-mingw32.tar ghc-7.10.3/ Tamar at Rage MINGW64 ~/Temp $ ghc-7.10.3/bin/ghc-pkg.exe check Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\mtl-2.2.1\html\mtl.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\mtl-2.2.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\QuickCheck-2.9.2\html\QuickCheck.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\QuickCheck-2.9.2\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\tf-random-0.5\html\tf-random.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\tf-random-0.5\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\primitive-0.6.2.0\html\primitive.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\primitive-0.6.2.0\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\random-1.1\html\random.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\random-1.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\semigroups-0.18.2\html\semigroups.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\semigroups-0.18.2\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\unordered-containers-0.2.7.1\html\unordered- containers.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\unordered-containers-0.2.7.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\tagged-0.8.5\html\tagged.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\tagged-0.8.5\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\hashable-1.2.4.0\html\hashable.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\hashable-1.2.4.0\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\transformers-compat-0.5.1.4\html\transformers- compat.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\transformers-compat-0.5.1.4\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\text-1.2.2.1\html\text.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\text-1.2.2.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\Cabal-1.24.1.0\html\Cabal.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\Tamar\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.10.3\Cabal-1.24.1.0\html doesn't exist or isn't a directory There are problems in package QuickCheck-2.8.2: Warning: library-dirs: C:/ProgramData/chocolatey/lib/ghc- devel-x86/msys32/usr/local\i386-windows- ghc-7.10.3\QuickCheck-2.8.2-FVXBHVG9RbOFIRbzutBVgm doesn't exist or isn't a directory Warning: haddock-interfaces: C:/ProgramData/chocolatey/lib/ghc- devel-x86/msys32/usr/local\doc\i386-windows- ghc-7.10.3\QuickCheck-2.8.2\html\QuickCheck.haddock doesn't exist or isn't a file Warning: haddock-html: C:/ProgramData/chocolatey/lib/ghc- devel-x86/msys32/usr/local\doc\i386-windows- ghc-7.10.3\QuickCheck-2.8.2\html doesn't exist or isn't a directory dependency "random-1.1-7QYmtoQynVDOpQqT5qt8s" doesn't exist dependency "tf-random-0.5-2tObRpM5RdhFns5AGGuShR" doesn't exist import-dirs: C:/ProgramData/chocolatey/lib/ghc- devel-x86/msys32/usr/local\i386-windows- ghc-7.10.3\QuickCheck-2.8.2-FVXBHVG9RbOFIRbzutBVgm doesn't exist or isn't a directory cannot find any of ["Test\\QuickCheck.hi","Test\\QuickCheck.p_hi","Test\\QuickCheck.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Arbitrary.hi","Test\\QuickCheck\\Arbitrary.p_hi","Test\\QuickCheck\\Arbitrary.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Gen.hi","Test\\QuickCheck\\Gen.p_hi","Test\\QuickCheck\\Gen.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Gen\\Unsafe.hi","Test\\QuickCheck\\Gen\\Unsafe.p_hi","Test\\QuickCheck\\Gen\\Unsafe.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Monadic.hi","Test\\QuickCheck\\Monadic.p_hi","Test\\QuickCheck\\Monadic.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Modifiers.hi","Test\\QuickCheck\\Modifiers.p_hi","Test\\QuickCheck\\Modifiers.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Property.hi","Test\\QuickCheck\\Property.p_hi","Test\\QuickCheck\\Property.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Test.hi","Test\\QuickCheck\\Test.p_hi","Test\\QuickCheck\\Test.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Text.hi","Test\\QuickCheck\\Text.p_hi","Test\\QuickCheck\\Text.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Poly.hi","Test\\QuickCheck\\Poly.p_hi","Test\\QuickCheck\\Poly.dyn_hi"] cannot find any of ["Test\\QuickCheck\\State.hi","Test\\QuickCheck\\State.p_hi","Test\\QuickCheck\\State.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Random.hi","Test\\QuickCheck\\Random.p_hi","Test\\QuickCheck\\Random.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Exception.hi","Test\\QuickCheck\\Exception.p_hi","Test\\QuickCheck\\Exception.dyn_hi"] cannot find any of ["Test\\QuickCheck\\Function.hi","Test\\QuickCheck\\Function.p_hi","Test\\QuickCheck\\Function.dyn_hi"] cannot find any of ["Test\\QuickCheck\\All.hi","Test\\QuickCheck\\All.p_hi","Test\\QuickCheck\\All.dyn_hi"] cannot find any of ["libHSQuickCheck-2.8.2-FVXBHVG9RbOFIRbzutBVgm.a","libHSQuickCheck-2.8.2-FVXBHVG9RbOFIRbzutBVgm.p_a","libHSQuickCheck-2.8.2 -FVXBHVG9RbOFIRbzutBVgm-ghc7.10.3.so","libHSQuickCheck-2.8.2 -FVXBHVG9RbOFIRbzutBVgm-ghc7.10.3.dylib","HSQuickCheck-2.8.2 -FVXBHVG9RbOFIRbzutBVgm-ghc7.10.3.dll"] on library path There are problems in package primitive-0.6.1.0: Warning: library-dirs: C:/ProgramData/chocolatey/lib/ghc- devel-x86/msys32/usr/local\i386-windows- ghc-7.10.3\primitive-0.6.1.0-DWCFovCQaj03LmIiVkz6kr doesn't exist or isn't a directory Warning: include-dirs: C:/ProgramData/chocolatey/lib/ghc- devel-x86/msys32/usr/local\i386-windows- ghc-7.10.3\primitive-0.6.1.0-DWCFovCQaj03LmIiVkz6kr\include doesn't exist or isn't a directory Warning: haddock-interfaces: C:/ProgramData/chocolatey/lib/ghc- devel-x86/msys32/usr/local\doc\i386-windows- ghc-7.10.3\primitive-0.6.1.0\html\primitive.haddock doesn't exist or isn't a file Warning: haddock-html: C:/ProgramData/chocolatey/lib/ghc- devel-x86/msys32/usr/local\doc\i386-windows- ghc-7.10.3\primitive-0.6.1.0\html doesn't exist or isn't a directory import-dirs: C:/ProgramData/chocolatey/lib/ghc- devel-x86/msys32/usr/local\i386-windows- ghc-7.10.3\primitive-0.6.1.0-DWCFovCQaj03LmIiVkz6kr doesn't exist or isn't a directory cannot find any of ["Control\\Monad\\Primitive.hi","Control\\Monad\\Primitive.p_hi","Control\\Monad\\Primitive.dyn_hi"] cannot find any of ["Data\\Primitive.hi","Data\\Primitive.p_hi","Data\\Primitive.dyn_hi"] cannot find any of ["Data\\Primitive\\MachDeps.hi","Data\\Primitive\\MachDeps.p_hi","Data\\Primitive\\MachDeps.dyn_hi"] cannot find any of ["Data\\Primitive\\Types.hi","Data\\Primitive\\Types.p_hi","Data\\Primitive\\Types.dyn_hi"] cannot find any of ["Data\\Primitive\\Array.hi","Data\\Primitive\\Array.p_hi","Data\\Primitive\\Array.dyn_hi"] cannot find any of ["Data\\Primitive\\ByteArray.hi","Data\\Primitive\\ByteArray.p_hi","Data\\Primitive\\ByteArray.dyn_hi"] cannot find any of ["Data\\Primitive\\Addr.hi","Data\\Primitive\\Addr.p_hi","Data\\Primitive\\Addr.dyn_hi"] cannot find any of ["Data\\Primitive\\MutVar.hi","Data\\Primitive\\MutVar.p_hi","Data\\Primitive\\MutVar.dyn_hi"] cannot find any of ["Data\\Primitive\\Internal\\Compat.hi","Data\\Primitive\\Internal\\Compat.p_hi","Data\\Primitive\\Internal\\Compat.dyn_hi"] cannot find any of ["Data\\Primitive\\Internal\\Operations.hi","Data\\Primitive\\Internal\\Operations.p_hi","Data\\Primitive\\Internal\\Operations.dyn_hi"] cannot find any of ["libHSprimitive-0.6.1.0-DWCFovCQaj03LmIiVkz6kr.a","libHSprimitive-0.6.1.0-DWCFovCQaj03LmIiVkz6kr.p_a","libHSprimitive-0.6.1.0 -DWCFovCQaj03LmIiVkz6kr-ghc7.10.3.so","libHSprimitive-0.6.1.0 -DWCFovCQaj03LmIiVkz6kr-ghc7.10.3.dylib","HSprimitive-0.6.1.0 -DWCFovCQaj03LmIiVkz6kr-ghc7.10.3.dll"] on library path The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. QuickCheck-2.8.2 primitive-0.6.1.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 20:12:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 20:12:51 -0000 Subject: [GHC] #12904: GHC 7.10.3 Binary distribution is broken. In-Reply-To: <044.790a692aeebadd351e256bc3db3b65d9@haskell.org> References: <044.790a692aeebadd351e256bc3db3b65d9@haskell.org> Message-ID: <059.de28445ba7653e4151c8714fb8301580@haskell.org> #12904: GHC 7.10.3 Binary distribution is broken. ------------------------------------------+------------------------------- Reporter: Phyx- | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------- Comment (by bgamari): Hmm, I wonder what happened here. This is quite unfortunate. I'll try to build a new distribution tonight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 20:31:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 20:31:24 -0000 Subject: [GHC] #12904: GHC 7.10.3 Binary distribution is broken. In-Reply-To: <044.790a692aeebadd351e256bc3db3b65d9@haskell.org> References: <044.790a692aeebadd351e256bc3db3b65d9@haskell.org> Message-ID: <059.f2e98b20df3e21c1b1278fbe5b56d098@haskell.org> #12904: GHC 7.10.3 Binary distribution is broken. ------------------------------------------+------------------------------- Reporter: Phyx- | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: So sorry for the noise. After I posted it I took I noticed one of the paths. The install seemed to have been picking up some old global package database somewhere for 7.10.3 and breaking on that. So the problem is between keyboard and chair.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 20:43:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 20:43:23 -0000 Subject: [GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM In-Reply-To: <045.352c8bb25c33b092176709513059d519@haskell.org> References: <045.352c8bb25c33b092176709513059d519@haskell.org> Message-ID: <060.85cfcced1a31646585b31a68eb0b22ed@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The solver for `Coercible` is known to struggle with recursive newtypes, where coercibility is (I believe) undecidable. Maybe we should use "stock" for recursive newtypes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 21:01:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 21:01:47 -0000 Subject: [GHC] #11821: Internal error: not in scope during type checking, but it passed the renamer In-Reply-To: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> References: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> Message-ID: <061.448a7b215376893f4e55a652a86677eb@haskell.org> #11821: Internal error: not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11821 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2146 Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I've stumbled on this bug with a smaller example: {{{ {-# LANGUAGE TypeInType, ConstraintKinds #-} import Data.Proxy type SameKind (a :: k1) (b :: k2) = ('Proxy :: Proxy k1) ~ ('Proxy :: Proxy k2) }}} And the error message with GHC 8.0 is {{{ SameKind.hs:3:77: error: • GHC internal error: ‘k2’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [arZ :-> Type variable ‘k1’ = k1, as0 :-> Type variable ‘a’ = a, as2 :-> Type variable ‘b’ = b, rq7 :-> ATcTyCon SameKind] • In the first argument of ‘Proxy’, namely ‘k2’ In the kind ‘Proxy k2’ In the second argument of ‘~’, namely ‘(Proxy :: Proxy k2)’ }}} The bug is indeed fixed in GHC 8.0.2. I'm posting this because I believe a smaller test case would be a valuable addition to the test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 22:00:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 22:00:56 -0000 Subject: [GHC] #12792: Wrong error message when using a data type as a class instance head In-Reply-To: <046.395f5e366c8e645bf9b11f3e4c1c270f@haskell.org> References: <046.395f5e366c8e645bf9b11f3e4c1c270f@haskell.org> Message-ID: <061.218e773e06457e0c6a494f870bb1c22b@haskell.org> #12792: Wrong error message when using a data type as a class instance head -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * priority: normal => low Comment: Related, but still minor: GHC would happily suggest a data type constructor where a class name is expected. {{{#!hs Prelude> data Bar a Prelude> instance Baz a :3:10: Not in scope: type constructor or class ‘Baz’ Perhaps you meant ‘Bar’ (line 2) }}} I read more through the code and see now why this is not easily done. The renamer does not know which names have methods, but for methods it knows what name they belong to (their parent, also just a name), so this can be caught early in the renamer. But since this parent information is “untyped”, we can actually trick the compiler in passing through the renamer, by using a record label (whose parent is the data type) as a class name: {{{#!hs data List a = List { bar :: a} instance List Int where bar = bar }}} produces {{{ [1 of 1] Compiling Main (.hs -> .o) /tmp/T12792.hs:2:10: error: • Expected a constraint, but ‘List Int’ has kind ‘*’ • In the instance declaration for ‘List Int’ }}} I get one way of getting saner behavior and early error reporting here would be to change the `NameSpace` type to distinguish between TyCons and classes, and at every use of namespaces pay close attention where one, the other, or both are valid. Since a `Name` knows it `NameSpace`, this would fix the problem at hand. But it would be quite a bit of work, and without other obvious benefits, not worth it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 22:46:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 22:46:28 -0000 Subject: [GHC] #12905: Core lint with pattern synonym Message-ID: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> #12905: Core lint with pattern synonym -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Yet another program from the type-indexed `Typeable` effort which breaks GHC (`master` branch as of 3bd1dd4d75fde3b922d4de08c16f29bdeb8e05d7) with a core lint error, {{{#!hs {-# LANGUAGE GADTs, TypeOperators, PatternSynonyms, TypeInType, PolyKinds, RankNTypes #-} module T where import GHC.Exts import Data.Kind import Data.Type.Equality data TypeRep (a :: k) where TrTyCon :: TypeRep (a :: k) TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep (a :: k1 -> k2) -> TypeRep (b :: k1) -> TypeRep (a b) TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRFun arg res <- TrFun arg res where TRFun arg res = TrFun arg res }}} This program produces many core lint errors, although all of them fall into only a few classes. Here's one, {{{ *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the coercion ‘Sym (Sym cobox_a3fT |> Sym cobox_a3fU)’ Kind application error in type ‘((->) |> <*>_N ->_N <*>_N ->_N Sym cobox) a’ Function kind = * -> * -> k Arg kinds = [(a, TYPE r1)] }}} {{{ : warning: [RHS of $d~~_a3fO :: (fun :: k) ~~ ((a -> b) :: *)] Kind application error in coercion ‘Sym (Sym (<(->)>_N |> ((<*>_N -> <*>_N -> Sym cobox_a3fU) ; Sym (<*>_N -> <*>_N -> Sym cobox_a3fH))) |> (<*>_N -> <*>_N -> Sym cobox_a3fU)) _N’ Function kind = * -> * -> * Arg kinds = [(a, TYPE r1)] }}} It appears that this is yet another case of the kind of `(->)` being too restrictive (#11714) since `a -> b` appears to be lifted to the coercion `TyConAppCo role (->) [a, b]`. Adding a `FunCo` constructor to `Coercion` would likely be an easy way to resolve this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 23:53:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 23:53:12 -0000 Subject: [GHC] #12905: Core lint with pattern synonym In-Reply-To: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> References: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> Message-ID: <061.3ead8828cb1dddd1fe0487a12eeb0768@haskell.org> #12905: Core lint with pattern synonym -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -67,3 +67,0 @@ - - Adding a `FunCo` constructor to `Coercion` would likely be an easy way to - resolve this. New description: Yet another program from the type-indexed `Typeable` effort which breaks GHC (`master` branch as of 3bd1dd4d75fde3b922d4de08c16f29bdeb8e05d7) with a core lint error, {{{#!hs {-# LANGUAGE GADTs, TypeOperators, PatternSynonyms, TypeInType, PolyKinds, RankNTypes #-} module T where import GHC.Exts import Data.Kind import Data.Type.Equality data TypeRep (a :: k) where TrTyCon :: TypeRep (a :: k) TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep (a :: k1 -> k2) -> TypeRep (b :: k1) -> TypeRep (a b) TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRFun arg res <- TrFun arg res where TRFun arg res = TrFun arg res }}} This program produces many core lint errors, although all of them fall into only a few classes. Here's one, {{{ *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the coercion ‘Sym (Sym cobox_a3fT |> Sym cobox_a3fU)’ Kind application error in type ‘((->) |> <*>_N ->_N <*>_N ->_N Sym cobox) a’ Function kind = * -> * -> k Arg kinds = [(a, TYPE r1)] }}} {{{ : warning: [RHS of $d~~_a3fO :: (fun :: k) ~~ ((a -> b) :: *)] Kind application error in coercion ‘Sym (Sym (<(->)>_N |> ((<*>_N -> <*>_N -> Sym cobox_a3fU) ; Sym (<*>_N -> <*>_N -> Sym cobox_a3fH))) |> (<*>_N -> <*>_N -> Sym cobox_a3fU)) _N’ Function kind = * -> * -> * Arg kinds = [(a, TYPE r1)] }}} It appears that this is yet another case of the kind of `(->)` being too restrictive (#11714) since `a -> b` appears to be lifted to the coercion `TyConAppCo role (->) [a, b]`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 23:53:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 23:53:33 -0000 Subject: [GHC] #12905: Core lint with pattern synonym In-Reply-To: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> References: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> Message-ID: <061.aef97013b06cb5b2722367a4f3bd816f@haskell.org> #12905: Core lint with pattern synonym -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -64,3 +64,3 @@ - It appears that this is yet another case of the kind of `(->)` being too - restrictive (#11714) since `a -> b` appears to be lifted to the coercion - `TyConAppCo role (->) [a, b]`. + This may be yet another case of the kind of `(->)` being too restrictive + (#11714) since `a -> b` appears to be lifted to the coercion `TyConAppCo + role (->) [a, b]`. New description: Yet another program from the type-indexed `Typeable` effort which breaks GHC (`master` branch as of 3bd1dd4d75fde3b922d4de08c16f29bdeb8e05d7) with a core lint error, {{{#!hs {-# LANGUAGE GADTs, TypeOperators, PatternSynonyms, TypeInType, PolyKinds, RankNTypes #-} module T where import GHC.Exts import Data.Kind import Data.Type.Equality data TypeRep (a :: k) where TrTyCon :: TypeRep (a :: k) TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). TypeRep (a :: k1 -> k2) -> TypeRep (b :: k1) -> TypeRep (a b) TrFun :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). TypeRep a -> TypeRep b -> TypeRep (a -> b) pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRFun arg res <- TrFun arg res where TRFun arg res = TrFun arg res }}} This program produces many core lint errors, although all of them fall into only a few classes. Here's one, {{{ *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the coercion ‘Sym (Sym cobox_a3fT |> Sym cobox_a3fU)’ Kind application error in type ‘((->) |> <*>_N ->_N <*>_N ->_N Sym cobox) a’ Function kind = * -> * -> k Arg kinds = [(a, TYPE r1)] }}} {{{ : warning: [RHS of $d~~_a3fO :: (fun :: k) ~~ ((a -> b) :: *)] Kind application error in coercion ‘Sym (Sym (<(->)>_N |> ((<*>_N -> <*>_N -> Sym cobox_a3fU) ; Sym (<*>_N -> <*>_N -> Sym cobox_a3fH))) |> (<*>_N -> <*>_N -> Sym cobox_a3fU)) _N’ Function kind = * -> * -> * Arg kinds = [(a, TYPE r1)] }}} This may be yet another case of the kind of `(->)` being too restrictive (#11714) since `a -> b` appears to be lifted to the coercion `TyConAppCo role (->) [a, b]`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 30 23:55:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 30 Nov 2016 23:55:49 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.b6654f458ebaf684dd56261bb5e5f9ba@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: typeable, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): @simonpj, I believe we need `typeRepKind`. However, I'm well on my way to implementing it. Unfortunately I'm somewhat blocked on #12905. -- Ticket URL: GHC The Glasgow Haskell Compiler