From ghc-devs at haskell.org Thu Feb 1 00:14:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 00:14:55 -0000 Subject: [GHC] #2893: Implement "Quantified constraints" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.291e86556f1eb2716b9745e98e565247@haskell.org> #2893: Implement "Quantified constraints" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4353 Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > See: [wiki:QuantifiedContexts Quantified constraints wiki page] New description: See: [wiki:QuantifiedConstraints Quantified constraints wiki page] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 00:19:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 00:19:20 -0000 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints In-Reply-To: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> References: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> Message-ID: <061.ebb66e8754b00887bbaeebf4a7b09da8@haskell.org> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.8.2 checker) | Keywords: Resolution: | QuantifedConstraints 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: => QuantifedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 00:21:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 00:21:39 -0000 Subject: [GHC] #12245: Deriving Data at higher kinds In-Reply-To: <046.fc248d7aec0de3523dca25d70e6f7b1d@haskell.org> References: <046.fc248d7aec0de3523dca25d70e6f7b1d@haskell.org> Message-ID: <061.0864d358609cd9b28b693142f077f9d0@haskell.org> #12245: Deriving Data at higher kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T12245 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 00:23:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 00:23:57 -0000 Subject: [GHC] #2256: Incompleteness of type inference: must quantify over implication constraints In-Reply-To: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> References: <046.2c6c7c4440a32ff5fbe5ad1f48bf6276@haskell.org> Message-ID: <061.62c08a31c6acd81e1415feae89dd7210@haskell.org> #2256: Incompleteness of type inference: must quantify over implication constraints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler (Type | Version: 6.8.2 checker) | Keywords: Resolution: | QuantifiedConstraints 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: QuantifedConstraints => QuantifiedConstraints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 00:50:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 00:50:37 -0000 Subject: [GHC] #12245: Deriving Data at higher kinds In-Reply-To: <046.fc248d7aec0de3523dca25d70e6f7b1d@haskell.org> References: <046.fc248d7aec0de3523dca25d70e6f7b1d@haskell.org> Message-ID: <061.38098fb1a697f505cd9c5eee90090d3b@haskell.org> #12245: Deriving Data at higher kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T12245 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): With [https://phabricator.haskell.org/D4353 D4353] this can be written as: {{{#!hs {-# Language QuantifiedConstraints #-} {-# Language StandaloneDeriving #-} {-# Language DeriveDataTypeable #-} {-# Language FlexibleInstances #-} {-# Language UndecidableInstances #-} {-# Language KindSignatures #-} {-# Language RankNTypes #-} {-# Language ConstraintKinds #-} import Data.Data (Data) import Data.Typeable import Data.Kind (Constraint) data Foo f = Foo (f Bool) (f Int) type LevelUp cls f = (forall xx. cls xx => cls (f xx) :: Constraint) deriving instance (Typeable f, LevelUp Data f) => Data (Foo f) }}} Can this ticket be closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 01:04:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 01:04:06 -0000 Subject: [GHC] #14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int)) Message-ID: <051.f7a27f9ae9b44fe3d201fa376deb4e42@haskell.org> #14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int)) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (based on WIP [https://phabricator.haskell.org/D4353 -XQuantifiedConstraints]) Could GHC infer the context for deriving `Data (Foo f)` (#12245)? {{{#!hs data Foo f = Foo (f Bool) (f Int) deriving stock Data {- Generates: instance (Typeable f, (forall xx. Data xx => Data (f xx))) => Data (Foo f) -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 02:28:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 02:28:06 -0000 Subject: [GHC] #14695: ghc --interactive error: "gcc: error: libgmp.so: No such file or directory" In-Reply-To: <043.14a5c82c2a46e2165050d731a268a622@haskell.org> References: <043.14a5c82c2a46e2165050d731a268a622@haskell.org> Message-ID: <058.82a05041dba0efdccf4400a687e4d514@haskell.org> #14695: ghc --interactive error: "gcc: error: libgmp.so: No such file or directory" -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4330 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.4.1 => 8.6.1 Comment: I don't believe the regressing patch is present in `ghc-8.4` and consequently comment:5 shouldn't be necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 02:30:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 02:30:21 -0000 Subject: [GHC] #14732: -fdefer-typed-holes breaks a correct program In-Reply-To: <052.1b96714b25f21170dafc623293b00787@haskell.org> References: <052.1b96714b25f21170dafc623293b00787@haskell.org> Message-ID: <067.4940ddc80832a178c51b51a529797df0@haskell.org> #14732: -fdefer-typed-holes breaks a correct program -------------------------------------+------------------------------------- Reporter: MitchellSalad | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 03:00:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 03:00:48 -0000 Subject: [GHC] #14673: Unary Unboxed Tuple Type Constructor In-Reply-To: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> References: <049.d9c870f0c2ef1490b284fbb19f566786@haskell.org> Message-ID: <064.577bf70f9291f4ab2d6b0c7dde77633b@haskell.org> #14673: Unary Unboxed Tuple Type Constructor -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: 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: core-libraries-committee@… (added) * milestone: => 8.6.1 Comment: This being a GHC-specific name, it's not clear that this is under the purview of the CLC. That being said, I'll let them chime in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 03:15:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 03:15:31 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.5377671ae1794991e213d1f33eac9d04@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3221 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 03:16:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 03:16:36 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.c9e6b19c74fcb994d2a08e2d42066cc6@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | Milestone: 8.6.1 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:D3723 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: The patch isn't ready yet and at this point it's too late at this point for non-necessary interface changes. Bumping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 03:59:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 03:59:36 -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.dad16efa364b4cd7174f6ac319f809de@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * milestone: 8.4.1 => Comment: At this point it's quite unclear when this will happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:00:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:00:38 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.436edab79f6477e6e4b5bada1370ea93@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | ApplicativeDo, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: ApplicativeDo => ApplicativeDo, newcomer * priority: high => normal * milestone: 8.4.1 => 8.6.1 Comment: This certainly won't happen for 8.4 but it very well may be done for 8.6 if you, the motivated reader, picks it up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:29:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:29:28 -0000 Subject: [GHC] #14702: Runtime is keeping hold to too much memory In-Reply-To: <044.b992e44759d80aa79bda392097ed4c31@haskell.org> References: <044.b992e44759d80aa79bda392097ed4c31@haskell.org> Message-ID: <059.c92ab245c1024bd3e7a8f0d510c17d5e@haskell.org> #14702: Runtime is keeping hold to too much memory -------------------------------------+------------------------------------- Reporter: blaze | Owner: blaze Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4338 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0171e09e4d073d8466953ebbf01292e55829fb20/ghc" 0171e09e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0171e09e4d073d8466953ebbf01292e55829fb20" Make RTS keep less memory (fixes #14702) Currently runtime keeps hold to 4*used_memory. This includes, in particular, nursery, which can be quite large on multiprocessor machines: 16 CPUs x 64Mb each is 1GB. Multiplying it by 4 means whatever actual memory usage is, runtime will never release memory under 4GB, and this is quite excessive for processes which only need a lot of memory shortly (think building data structures from large files). This diff makes multiplier to apply only to GC-managed memory, leaving all "static" allocations alone. Test Plan: make test TEST="T14702" Reviewers: bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14702 Differential Revision: https://phabricator.haskell.org/D4338 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:29:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:29:28 -0000 Subject: [GHC] #14676: GHCI doesn't recover from bad :add In-Reply-To: <045.ccd6c837250f0c0b76f1bf7950e53b8c@haskell.org> References: <045.ccd6c837250f0c0b76f1bf7950e53b8c@haskell.org> Message-ID: <060.78fb23535574bc4077f331bea17a744d@haskell.org> #14676: GHCI doesn't recover from bad :add -------------------------------------+------------------------------------- Reporter: Juzley | Owner: Juzley Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0bff9e677f0569bc8a7207c20cddddfd67e2448f/ghc" 0bff9e67/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0bff9e677f0569bc8a7207c20cddddfd67e2448f" Don't add targets that can't be found in GHCi When using the :add command in haxlsh/ghci, a module/file that can't be found is still added to the list of targets, resulting in an error message for the bad module/file for every subsequent usage of the command. The add command should verify that the module/file can be found before adding it to the list of targets. Also add a ":show targets" command to show the currently added list of commands, and an ":unadd" command to remove a target. Test Plan: Add a new GHCi testcase that checks that :add doesn't remember either files or modules that could not be found, and that both the new :show and :unadd commands work as expected. Reviewers: simonmar, bgamari Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14676 Differential Revision: https://phabricator.haskell.org/D4321 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:29:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:29:46 -0000 Subject: [GHC] #10855: GHC rejects code that Haskell 2010 report accepts In-Reply-To: <047.18e6e77fdcbdaa2d5abe96a152166a71@haskell.org> References: <047.18e6e77fdcbdaa2d5abe96a152166a71@haskell.org> Message-ID: <062.fe7ed0fdb4b1c045f96489672925af4f@haskell.org> #10855: GHC rejects code that Haskell 2010 report accepts -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.3 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"be84823b956f0aa09c58d94d1901f2dff13546b4/ghc" be84823/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be84823b956f0aa09c58d94d1901f2dff13546b4" Implement BlockArguments (#10843) This patch implements the BlockArguments extension, as proposed at https://github.com/ghc-proposals/ghc-proposals/pull/90. It also fixes #10855 as a side-effect. This patch adds a large number of shift-reduce conflicts to the parser. All of them concern the ambiguity as to where constructs like `if` and `let` end. Fortunately they are resolved correctly by preferring shift. The patch is based on @gibiansky's ArgumentDo implementation (D1219). Test Plan: ./validate Reviewers: goldfire, bgamari, alanz, mpickering Reviewed By: bgamari, mpickering Subscribers: Wizek, dfeuer, gibiansky, rwbarton, thomie, mpickering, carter GHC Trac Issues: #10843, #10855 Differential Revision: https://phabricator.haskell.org/D4260 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:29:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:29:46 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.fe872c5f1821b091cb0903a46ae827ba@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: akio Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11706 | Differential Rev(s): Phab:D1219, Wiki Page: | Phab:D4260 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"be84823b956f0aa09c58d94d1901f2dff13546b4/ghc" be84823/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be84823b956f0aa09c58d94d1901f2dff13546b4" Implement BlockArguments (#10843) This patch implements the BlockArguments extension, as proposed at https://github.com/ghc-proposals/ghc-proposals/pull/90. It also fixes #10855 as a side-effect. This patch adds a large number of shift-reduce conflicts to the parser. All of them concern the ambiguity as to where constructs like `if` and `let` end. Fortunately they are resolved correctly by preferring shift. The patch is based on @gibiansky's ArgumentDo implementation (D1219). Test Plan: ./validate Reviewers: goldfire, bgamari, alanz, mpickering Reviewed By: bgamari, mpickering Subscribers: Wizek, dfeuer, gibiansky, rwbarton, thomie, mpickering, carter GHC Trac Issues: #10843, #10855 Differential Revision: https://phabricator.haskell.org/D4260 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:29:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:29:46 -0000 Subject: [GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances In-Reply-To: <050.313c7572181a73220f1b076de5274da4@haskell.org> References: <050.313c7572181a73220f1b076de5274da4@haskell.org> Message-ID: <065.4e3ccd76919b7890588617a0cf2ec058@haskell.org> #13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: deriving 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:D4337 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1a911f217a18c8c0362ab2bf2b6ec7f7da015622/ghc" 1a911f21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1a911f217a18c8c0362ab2bf2b6ec7f7da015622" Sequester deriving-related validity check into cond_stdOK Currently, any standalone-derived instance must satisfy the property that the tycon of the data type having an instance being derived for it must be either a normal ADT tycon or a data family tycon. But there are several other primitive tycons—such as `(->)`, `Int#`, and others—which cannot have standalone-derived instances (via the `anyclass` strategy) as a result of this check! See https://ghc.haskell.org/trac/ghc/ticket/13154#comment:8 for an example of where this overly conservative restriction bites. Really, this validity check only makes sense in the context of `stock` deriving, where we need the property that the tycon is that of a normal ADT or a data family in order to inspect its data constructors. Other deriving strategies don't require this validity check, so the most sensible way to fix this error is to move the logic of this check into `cond_stdOK`, which is specific to `stock` deriving. This makes progress towards fixing (but does not entirely fix) Test Plan: make test TEST=T13154a Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13154 Differential Revision: https://phabricator.haskell.org/D4337 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:29:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:29:46 -0000 Subject: [GHC] #14725: memory leak: forkOS not releasing thread local `Task` struct upon end of thread In-Reply-To: <050.9267e809dc9eb2e9ccacbd64b8668a58@haskell.org> References: <050.9267e809dc9eb2e9ccacbd64b8668a58@haskell.org> Message-ID: <065.2920e19ead2d8265d655a9f84e1c1eee@haskell.org> #14725: memory leak: forkOS not releasing thread local `Task` struct upon end of thread -------------------------------------+------------------------------------- Reporter: RobertZabel | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: forkOS memory | leak Operating System: POSIX | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4346 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"382c12d18f3d64e01502a5c8bbc64d4aa4842e3e/ghc" 382c12d1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="382c12d18f3d64e01502a5c8bbc64d4aa4842e3e" rts: Ensure that forkOS releases Task on termination Test Plan: validate Reviewers: simonmar, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14725 Differential Revision: https://phabricator.haskell.org/D4346 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:29:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:29:46 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.dc14b4631ce6b5adc94c919b657e7d0e@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: AndreasK Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 (CodeGen) | 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): Phab:D4348 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"add4e1f11b88cd603f6c01bc135eb576e1922a8e/ghc" add4e1f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="add4e1f11b88cd603f6c01bc135eb576e1922a8e" Mark xmm6 as caller saved in the register allocator for windows. This prevents the register being picked up as a scratch register. Otherwise the allocator would be free to use it before a call. This fixes #14619. Test Plan: ci, repro case on #14619 Reviewers: bgamari, Phyx, erikd, simonmar, RyanGlScott, simonpj Reviewed By: Phyx, RyanGlScott, simonpj Subscribers: simonpj, RyanGlScott, Phyx, rwbarton, thomie, carter GHC Trac Issues: #14619 Differential Revision: https://phabricator.haskell.org/D4348 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:29:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:29:46 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.b445f84343a7012a77cd661a95402b84@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e4ab65bd57b2c39f4af52879654514bb6d5b42a0/ghc" e4ab65bd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e4ab65bd57b2c39f4af52879654514bb6d5b42a0" Optimize coercionKind (Trac #11735) Reviewers: simonpj, goldfire, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11735 Differential Revision: https://phabricator.haskell.org/D4355 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:29:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:29:46 -0000 Subject: [GHC] #14740: Unboxed tuple allowed in context: ((##)) => () In-Reply-To: <051.8b8e98ba0843035c110393441bb1b895@haskell.org> References: <051.8b8e98ba0843035c110393441bb1b895@haskell.org> Message-ID: <066.6b115d13fa6b22401f341ea567110676@haskell.org> #14740: Unboxed tuple allowed in context: ((##)) => () -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Parser) | Resolution: | Keywords: UnboxedTuples Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14740 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4359 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ced9fbd3913e1316498961bc389bfb1e141221a1/ghc" ced9fbd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ced9fbd3913e1316498961bc389bfb1e141221a1" UnboxedTuples can't be used as constraints Fixes #14740. Test Plan: make test TEST="14740" Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14740 Differential Revision: https://phabricator.haskell.org/D4359 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:31:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:31:28 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.b163098ce0f1c5285b397a3c3757fd33@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: akio Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11706 | Differential Rev(s): Phab:D1219, Wiki Page: | Phab:D4260 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 Comment: Thanks Akio! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:32:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:32:02 -0000 Subject: [GHC] #14702: Runtime is keeping hold to too much memory In-Reply-To: <044.b992e44759d80aa79bda392097ed4c31@haskell.org> References: <044.b992e44759d80aa79bda392097ed4c31@haskell.org> Message-ID: <059.dd0f955e215d08f9f5e94fa8774f2c39@haskell.org> #14702: Runtime is keeping hold to too much memory -------------------------------------+------------------------------------- Reporter: blaze | Owner: blaze Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 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:D4338 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:33:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:33:31 -0000 Subject: [GHC] #14676: GHCI doesn't recover from bad :add In-Reply-To: <045.ccd6c837250f0c0b76f1bf7950e53b8c@haskell.org> References: <045.ccd6c837250f0c0b76f1bf7950e53b8c@haskell.org> Message-ID: <060.c79b9af295f5c9145b221eae8155be8f@haskell.org> #14676: GHCI doesn't recover from bad :add -------------------------------------+------------------------------------- Reporter: Juzley | Owner: Juzley Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.6.1 Comment: Going to merge to `ghc-8.4` as this is a rather annoying usability issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:36:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:36:00 -0000 Subject: [GHC] #14740: Unboxed tuple allowed in context: ((##)) => () In-Reply-To: <051.8b8e98ba0843035c110393441bb1b895@haskell.org> References: <051.8b8e98ba0843035c110393441bb1b895@haskell.org> Message-ID: <066.1e10eede312f344e4ee29793c525a4fc@haskell.org> #14740: Unboxed tuple allowed in context: ((##)) => () -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Parser) | Resolution: | Keywords: UnboxedTuples Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14740 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4359 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.6.1 Comment: Thanks for picking this up, sighingnow! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:37:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:37:16 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.c9fd5e37cafaad8acf7374e8be25fda7@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Phab:D4009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: trommler => (none) * priority: high => highest * status: closed => new * resolution: fixed => Comment: Reopening to ensure I don't forget to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:39:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:39:51 -0000 Subject: [GHC] #14706: T11489 fails if run as root In-Reply-To: <046.a14b90f533f833e4ef6e5c85c8add140@haskell.org> References: <046.a14b90f533f833e4ef6e5c85c8add140@haskell.org> Message-ID: <061.f03017211ca3ebfa4df01a159a4e3679@haskell.org> #14706: T11489 fails if run as root -------------------------------------+------------------------------------- Reporter: bgamari | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.5 Integration | 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:D4360 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4360 * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 04:44:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 04:44:28 -0000 Subject: [GHC] #14725: memory leak: forkOS not releasing thread local `Task` struct upon end of thread In-Reply-To: <050.9267e809dc9eb2e9ccacbd64b8668a58@haskell.org> References: <050.9267e809dc9eb2e9ccacbd64b8668a58@haskell.org> Message-ID: <065.a0bf3401d12e19b6c3cc359bda1441d0@haskell.org> #14725: memory leak: forkOS not releasing thread local `Task` struct upon end of thread -------------------------------------+------------------------------------- Reporter: RobertZabel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.2.2 Resolution: fixed | Keywords: forkOS memory | leak Operating System: POSIX | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4346 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Fixed and merged to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:32:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:32:04 -0000 Subject: [GHC] #14312: Head does not build on Windows with the default make config. In-Reply-To: <047.086b87bb9b3dcf2f7a921149fa31eda2@haskell.org> References: <047.086b87bb9b3dcf2f7a921149fa31eda2@haskell.org> Message-ID: <062.80a1abc165c2967dd078aeb458ea2baa@haskell.org> #14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.1 Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4080 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * milestone: => 8.4.1 Comment: Phyx-, does this need to make it into 8.4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:32:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:32:35 -0000 Subject: [GHC] #14312: Head does not build on Windows with the default make config. In-Reply-To: <047.086b87bb9b3dcf2f7a921149fa31eda2@haskell.org> References: <047.086b87bb9b3dcf2f7a921149fa31eda2@haskell.org> Message-ID: <062.a8d778e1d08160b873b91b77f23c53cf@haskell.org> #14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4080 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Ahh, judging from the release notes the answer is clearly no. Re- milestoning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:36:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:36:57 -0000 Subject: [GHC] #14715: GHC 8.4.1-alpha regression with PartialTypeSignatures In-Reply-To: <050.adc4992a794b331cf0bfd2207ccd29b6@haskell.org> References: <050.adc4992a794b331cf0bfd2207ccd29b6@haskell.org> Message-ID: <065.c65a4a33205b6fdad3c533a648e26392@haskell.org> #14715: GHC 8.4.1-alpha regression with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha1 checker) | Keywords: Resolution: fixed | PartialTypeSignatures 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 * resolution: => fixed Comment: Merged with e6c147442fbeb161bbed209126186056f371d60c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:38:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:38:36 -0000 Subject: [GHC] #14723: GHC 8.4.1-alpha loops infinitely when typechecking In-Reply-To: <050.41938dfcc2cea4d35c5568a864ac48d8@haskell.org> References: <050.41938dfcc2cea4d35c5568a864ac48d8@haskell.org> Message-ID: <065.4f07e446c5cf5eb0daaf760a1073dd1c@haskell.org> #14723: GHC 8.4.1-alpha loops infinitely when typechecking -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | polykinds/T14723 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 77cdf60c8a68d2208cd8109d82b5f83b17bf0e91. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:39:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:39:02 -0000 Subject: [GHC] #14732: -fdefer-typed-holes breaks a correct program In-Reply-To: <052.1b96714b25f21170dafc623293b00787@haskell.org> References: <052.1b96714b25f21170dafc623293b00787@haskell.org> Message-ID: <067.88e72ca03e97fdcfb6b2a06c46db8da0@haskell.org> #14732: -fdefer-typed-holes breaks a correct program -------------------------------------+------------------------------------- Reporter: MitchellSalad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14732 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with d3573e4ae63d6ae1ac0cd4bf5692a9bcd39ba733. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:39:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:39:41 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.07134b80d2cf07087a71c1bb53d223ab@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: AndreasK Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: fixed | 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): Phab:D4348 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged with fe485f2961324d3b798d4dc8b1ccd27e887fa213. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:40:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:40:01 -0000 Subject: [GHC] #14676: GHCI doesn't recover from bad :add In-Reply-To: <045.ccd6c837250f0c0b76f1bf7950e53b8c@haskell.org> References: <045.ccd6c837250f0c0b76f1bf7950e53b8c@haskell.org> Message-ID: <060.782829a012dc71178f2cdf3831ce591d@haskell.org> #14676: GHCI doesn't recover from bad :add -------------------------------------+------------------------------------- Reporter: Juzley | Owner: Juzley Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged with 8f668bdaa1909c28a041db1680585bbf7d833987. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:41:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:41:15 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.d9ed57897ffa22be9976d733d1a3149a@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752 #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => Comment: This is a rather open-ended and non-trivial issue; removing milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:41:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:41:35 -0000 Subject: [GHC] #10599: Template Haskell doesn't allow `newName "type"` In-Reply-To: <048.829d4ff7778a587a956aa230325a65a0@haskell.org> References: <048.829d4ff7778a587a956aa230325a65a0@haskell.org> Message-ID: <063.adf9488a678c9e1bb9edbb96194e0cca@haskell.org> #10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * milestone: 8.4.1 => 8.6.1 Comment: Nor will it happen for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:42:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:42:31 -0000 Subject: [GHC] #13576: Runtime crashes on arm64 (iOS) In-Reply-To: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> References: <049.870e50852d766ed0e0b96a146b5b4e33@haskell.org> Message-ID: <064.cdd9ab797c2bf91c1d35ada789cece9d@haskell.org> #13576: Runtime crashes on arm64 (iOS) ----------------------------------+---------------------------------- Reporter: jp.rider63 | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: aarch64 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Changes (by bgamari): * status: new => infoneeded * milestone: 8.4.1 => 8.6.1 Comment: This won't be fixed for 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:43:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:43:52 -0000 Subject: [GHC] #13994: STG lint failure on master In-Reply-To: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> References: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> Message-ID: <061.7992f3c57f04eb9f9f88ff696f02986d@haskell.org> #13994: STG lint failure on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest Comment: We should verify that this is fixed before the release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:44:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:44:18 -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.dc855d6338a5818879f7f330a5919200@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: normal | Milestone: 8.6.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal * milestone: 8.4.1 => 8.6.1 Comment: Perhaps this will make 8.4.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:45:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:45:47 -0000 Subject: [GHC] #14069: RTS linker maps code as writable In-Reply-To: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> References: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> Message-ID: <061.9cc913f07426b717c1ce6d22ef09faf3@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomer * milestone: 8.4.1 => 8.6.1 Comment: This won't be fixed for 8.4, although I do hope someone picks it up for 8.6. This strikes me as a rather serious yet easy-to-fix security issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:46:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:46:40 -0000 Subject: [GHC] #14013: Bad monads performance In-Reply-To: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> References: <046.88692e0e9cdbd43d8ff52c2ba6a9781b@haskell.org> Message-ID: <061.b4be6cc9848831f01b3dc5e865cc6dc2@haskell.org> #14013: Bad monads performance -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.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.4.1 => 8.6.1 Comment: What is the status of this, Simon? Regardless, presumably nothing will change for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:47:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:47:35 -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.9194516c0034f70e0b86347ef729531b@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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 bgamari): * priority: high => normal * milestone: 8.4.1 => Comment: Given how there has been little progress on this, un-milestoning and downgrading priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:48:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:48:18 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.5131bf24517699f092273cf6ccbf2399@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.1 (Linker) | Keywords: linker, Resolution: | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: linker => linker, newcomer * milestone: 8.4.1 => 8.6.1 Comment: This is something that we should try to fix (along with #14069) in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:48:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:48:47 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.95ca2d399d24757601cd7fddc4ad2c27@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer 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): * keywords: => newcomer * milestone: 8.4.1 => 8.6.1 Comment: Won't happen for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:49:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:49:49 -0000 Subject: [GHC] #13930: Cabal configure regresses in space/time In-Reply-To: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> References: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> Message-ID: <061.704eb2140595d067c3318c8392f195dc@haskell.org> #13930: Cabal configure regresses in space/time -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13982 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.4.2 Comment: What is the status of this, osa1? Were you able to reproduce this? Regardless, it's unlikely this will be fixed for 8.4.1.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:50:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:50:19 -0000 Subject: [GHC] #5775: Inconsistency in demand analysis In-Reply-To: <041.59a17f321cd8e5e5a5552bb1b43821e2@haskell.org> References: <041.59a17f321cd8e5e5a5552bb1b43821e2@haskell.org> Message-ID: <056.5adadccd7555c1c17f877a8dad73158b@haskell.org> #5775: Inconsistency in demand analysis -------------------------------------+------------------------------------- Reporter: rl | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.5 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.4.1 => Comment: Unmilestoning due to lack of progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:53:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:53:13 -0000 Subject: [GHC] #14508: Bring up Appveyor for Windows CI In-Reply-To: <046.b1e7fd0356de10b29814d8db318f756c@haskell.org> References: <046.b1e7fd0356de10b29814d8db318f756c@haskell.org> Message-ID: <061.5849112af5d5b23ef0654e22239dc9da@haskell.org> #14508: Bring up Appveyor for Windows CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: 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 have fixed up the Appveyor support and have [[https://github.com/appveyor/ci/issues/517|requested]] an increased time limit. We'll see what happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:56:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:56:27 -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.36695dac6dade01c7dab36bf5c976c3a@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.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 bgamari): * milestone: 8.4.1 => 8.6.1 Comment: This won't happen for 8.4. > bgamari: What is your approach for fixing this? Do you think it could be adapted to address the hs-boot visibility problems in ​trac:14092? Essentially it is to find all of the places where we use unfoldings and make them conditional on `DynFlags`. Then we can eliminate the conditional reading of unfoldings from interface files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:57:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:57:25 -0000 Subject: [GHC] #13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown In-Reply-To: <049.12eb233680e8d62e08f397274c91a741@haskell.org> References: <049.12eb233680e8d62e08f397274c91a741@haskell.org> Message-ID: <064.982ffd1c4d5919e1dd07da40b68a0d22@haskell.org> #13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Is this still reproducible? If so this won't be fixed for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:57:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:57:49 -0000 Subject: [GHC] #13650: Implement KPush in types In-Reply-To: <047.e26721ad30e2e3d90c01c9e924788439@haskell.org> References: <047.e26721ad30e2e3d90c01c9e924788439@haskell.org> Message-ID: <062.362f4f289a0233ac7c6513c0f8a728ed@haskell.org> #13650: Implement KPush in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: This won't happen for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 05:58:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 05:58:57 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.96c77397013c91023a8f29fc0fb5f579@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Keywords: newcomer, Resolution: | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157 | Differential Rev(s): Phab:D3973, Wiki Page: | Phab:D3999 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * milestone: 8.4.1 => 8.6.1 Comment: I'll need to take a look at this. Unfortunately it likely won't happen before 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:00:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:00:26 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.dcab6f9b656c3c762dff6c0347857f03@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: This certainly won't be resolved for 8.4. Full determinism would be great however; do holler if this sounds like a fun to project to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:01:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:01:10 -0000 Subject: [GHC] #14155: GHC mentions unlifted types out of the blue (to me anyway) In-Reply-To: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> References: <051.e9a8763157e763f2ef920c4bfc2f101b@haskell.org> Message-ID: <066.34aaed2605227990dc5835e72d37d9ff@haskell.org> #14155: GHC mentions unlifted types out of the blue (to me anyway) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: What is the status of this, goldfire? Regardless, it's unlikely that this will happen for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:01:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:01:43 -0000 Subject: [GHC] #12178: Allow inline pragmas on pattern synonyms In-Reply-To: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> References: <049.c0b5177720c745c7c76b88f1c76a960e@haskell.org> Message-ID: <064.7122a8de36ddcea0c066c400445da744@haskell.org> #12178: Allow inline pragmas on pattern synonyms -------------------------------------+------------------------------------- Reporter: mpickering | Owner: osa1 Type: feature request | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: PatternSynonyms => PatternSynonyms, newcomer * milestone: 8.4.1 => 8.6.1 Comment: Perhaps we'll be able to get this done for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:02:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:02:22 -0000 Subject: [GHC] #14468: Why does alanz's branch blow up GHC's heap? In-Reply-To: <046.be390aa8ac1f4abd294d2b3b0f58b57c@haskell.org> References: <046.be390aa8ac1f4abd294d2b3b0f58b57c@haskell.org> Message-ID: <061.8dfdd2600659438f2f1ffc7685d589fd@haskell.org> #14468: Why does alanz's branch blow up GHC's heap? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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.4.1 => 8.6.1 Comment: At this point alanz's branch won't be making it for 8.4, sadly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:03:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:03:33 -0000 Subject: [GHC] #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array In-Reply-To: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> References: <048.3858df3b3399782d9452f01ad23b4ddd@haskell.org> Message-ID: <063.4672c34202cfa6c80f67ea7a0bef85b4@haskell.org> #13763: Performance regression (~34%) in 8.2.1, poor register allocation(?) in an inner loop over an array -------------------------------------+------------------------------------- Reporter: jberryman | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (NCG) | Version: 8.2.1-rc2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Sadly this didn't quite make 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:04:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:04:11 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.13c2cdae9f5a65062ef1cb5213e0897d@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: This won't be resolved for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:07:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:07:11 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.03dd0fc6080419e9cf2cf4746952f11e@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: highest => high * owner: bgamari => (none) * milestone: 8.4.1 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:07:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:07:39 -0000 Subject: [GHC] #14123: Figure out invariants surrounding ticks in Core In-Reply-To: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> References: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> Message-ID: <061.daba8c737506058c1750e4ba278f9fb8@haskell.org> #14123: Figure out invariants surrounding ticks in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13233, #14122, | Differential Rev(s): #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Sadly this won't be happening for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:08:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:08:34 -0000 Subject: [GHC] #13380: raiseIO# result looks wrong In-Reply-To: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> References: <045.2229f235cc1c98494d8d5c885068e972@haskell.org> Message-ID: <060.741b602077354fd935188ebc08a52e06@haskell.org> #13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => Comment: It's unlikely that this will be fixed for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:08:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:08:56 -0000 Subject: [GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic In-Reply-To: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> References: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> Message-ID: <061.c309579c55bc91cd420362d616a27547@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Generics, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: Generics => Generics, newcomer * milestone: 8.4.1 => 8.6.1 Comment: This won't happen for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:09:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:09:24 -0000 Subject: [GHC] #11958: Improved testing of cross-compiler In-Reply-To: <044.199977cda1889326e5e53eb484e40895@haskell.org> References: <044.199977cda1889326e5e53eb484e40895@haskell.org> Message-ID: <059.e3e61649a97070eacf136c7f298cf235@haskell.org> #11958: Improved testing of cross-compiler -------------------------------------+------------------------------------- Reporter: erikd | Owner: bgamari Type: task | Status: new Priority: low | Milestone: 8.6.1 Component: Continuous | Version: 7.10.3 Integration | Resolution: | Keywords: cross-compile Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13716 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 06:10:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 06:10:59 -0000 Subject: [GHC] #14724: ghc-8.2.2 configure script fail to extract gcc version correctly In-Reply-To: <047.3c856cd290cb04641a217ca765a91456@haskell.org> References: <047.3c856cd290cb04641a217ca765a91456@haskell.org> Message-ID: <062.d92b1150bfb5c89ae7cb1c10b4916e8b@haskell.org> #14724: ghc-8.2.2 configure script fail to extract gcc version correctly -------------------------------------+------------------------------------- Reporter: hyophyop | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC | (amd64) 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 Thu Feb 1 07:45:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 07:45:56 -0000 Subject: [GHC] #14742: Unboxed sums can treat Word#s as Int#s In-Reply-To: <043.f2ad58847922732aad4c3d717b7bb370@haskell.org> References: <043.f2ad58847922732aad4c3d717b7bb370@haskell.org> Message-ID: <058.0765402b8ea0ba5b5768c17903acb92b@haskell.org> #14742: Unboxed sums can treat Word#s as Int#s -------------------------------------+------------------------------------- Reporter: duog | Owner: osa1 Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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): `RuntimeRep` is much older than unboxed sums and completely unrelated. Apparently it's used to generate "hints" for ABI calls (see `primRepForeignHint`). It may be used in C codegen (maybe to give an argument type `int32_t` instead of `uint32_t` etc.), but other than that I'm not sure if any of the platforms GHC supports have different ABIs for passing ints vs. words. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 08:21:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 08:21:42 -0000 Subject: [GHC] #14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int)) In-Reply-To: <051.f7a27f9ae9b44fe3d201fa376deb4e42@haskell.org> References: <051.f7a27f9ae9b44fe3d201fa376deb4e42@haskell.org> Message-ID: <066.2755a98d4ecc607f3d130ea6b7679f2f@haskell.org> #14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int)) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | QuantifiedConstraints wipT2893, | deriving 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: QuantifiedConstraints wipT2893 => QuantifiedConstraints wipT2893, deriving Comment: I'm not sure. When doing {{{ data T a = MkT a [a] deriving( Eq ) }}} the deriving mechanism says "oh, we need `Eq` on each field, that is `Eq a, Eq [a]`". Then it simplifies that to arrive at the instance context. For your example, it'd say "I need `Data (f Bool), Data (f Int)` and then get stuck. There are two ways to get unglued. One is simply to put those in the instance context {{{ instance (Data (f Int), Data (f Bool)) => Data (Foo f) where ... }}} The other is to use quantified constraints. It's not clear which is best in general. And even figuring out the appropriate quantified-constraint generalisation of a set of ground constraints is far from trivial. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 09:08:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 09:08:16 -0000 Subject: [GHC] #14749: T13822 fails Message-ID: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> #14749: T13822 fails -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this cut-down T13822 {{{ {-# LANGUAGE GADTs, TypeOperators, DataKinds, TypeFamilies, TypeInType #-} module T13822 where import Data.Kind data KIND = STAR | KIND :> KIND data Ty :: KIND -> Type where TMaybe :: Ty (STAR :> STAR) TApp :: Ty (a :> b) -> (Ty a -> Ty b) type family IK (k :: KIND) = (res :: Type) where IK STAR = Type IK (a:>b) = IK a -> IK b type family I (t :: Ty k) = (res :: IK k) where I TMaybe = Maybe I (TApp f a) = (I f) (I a) data TyRep (k :: KIND) (t :: Ty k) where TyMaybe :: TyRep (STAR:>STAR) TMaybe TyApp :: TyRep (a:>b) f -> TyRep a x -> TyRep b (TApp f x) zero :: TyRep STAR a -> I a zero x = case x of TyApp TyMaybe _ -> Nothing }}} With a stage-1 compiler with DEBUG enabled, this program yields a Lint error in all recent versions of GHC. (NB: Lint, not an assertion failure.) With stage-2 it succeeds, and passes Lint. But an apparently unrelated patch makes it fail Lint even in stage 2. I conclude that the bug is not in the unrelated patch; it is somehow there all along. I'll mark T13822 as expect-broken; you can re-enable it when this ticket is fixed. The Lint error is pretty obscure {{{ *** Core Lint errors : in result of Desugar (before optimization) *** : warning: [in body of letrec with binders co_a10u :: (f_a10g :: Ty (a_a10f ':> 'STAR)) ~# (('TMaybe |> (Ty (Sym co_a10r ':> <'STAR>_N)_N)_N) :: Ty (a_a10f ':> 'STAR))] Kind application error in coercion ‘(Maybe (Sym (Coh Sym (Ty (Sym co_a10r))_N)>_N (D:R:IK[0]) ; Coh <(I (x_a10h |> Sym (Ty (Sym co_a10r))_N) |> D:R:IK[0])>_N (Sym (D:R:IK[0]))) ; Coh Sym (Ty (Sym co_a10r))_N)>_N (D:R:IK[0])))_N’ Function kind = * -> * Arg kinds = [(I (x_a10h |> Sym (Ty (Sym co_a10r))_N), IK 'STAR)] Fun: * (I (x_a10h |> Sym (Ty (Sym co_a10r))_N), IK 'STAR) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 09:14:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 09:14:41 -0000 Subject: [GHC] #14749: T13822 fails In-Reply-To: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> References: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> Message-ID: <061.671b910ca349385d94b3dcbdd3573ec3@haskell.org> #14749: T13822 fails -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider this cut-down T13822 > {{{ > {-# LANGUAGE GADTs, TypeOperators, DataKinds, TypeFamilies, TypeInType > #-} > > module T13822 where > > import Data.Kind > > data KIND = STAR | KIND :> KIND > > data Ty :: KIND -> Type where > TMaybe :: Ty (STAR :> STAR) > TApp :: Ty (a :> b) -> (Ty a -> Ty b) > > type family IK (k :: KIND) = (res :: Type) where > IK STAR = Type > IK (a:>b) = IK a -> IK b > > type family I (t :: Ty k) = (res :: IK k) where > I TMaybe = Maybe > I (TApp f a) = (I f) (I a) > > data TyRep (k :: KIND) (t :: Ty k) where > TyMaybe :: TyRep (STAR:>STAR) TMaybe > TyApp :: TyRep (a:>b) f -> TyRep a x -> TyRep b (TApp f x) > > zero :: TyRep STAR a -> I a > zero x = case x of > TyApp TyMaybe _ -> Nothing > }}} > With a stage-1 compiler with DEBUG enabled, this program yields a Lint > error in all recent versions of GHC. (NB: Lint, not an assertion > failure.) > > With stage-2 it succeeds, and passes Lint. But an apparently unrelated > patch makes it fail Lint even in stage 2. I conclude that the bug is not > in the unrelated patch; it is somehow there all along. > > I'll mark T13822 as expect-broken; you can re-enable it when this ticket > is fixed. > > The Lint error is pretty obscure > {{{ > *** Core Lint errors : in result of Desugar (before optimization) *** > : warning: > [in body of letrec with binders co_a10u :: (f_a10g :: Ty > (a_a10f ':> > 'STAR)) > ~# (('TMaybe |> (Ty > (Sym > co_a10r > ':> > <'STAR>_N)_N)_N) :: Ty > (a_a10f > ':> 'STAR))] > Kind application error in > coercion ‘(Maybe > (Sym (Coh Sym (Ty (Sym co_a10r))_N)>_N > (D:R:IK[0]) ; Coh <(I (x_a10h |> Sym (Ty > (Sym > co_a10r))_N) |> D:R:IK[0])>_N > (Sym (D:R:IK[0]))) ; Coh > Sym (Ty > (Sym co_a10r))_N)>_N > (D:R:IK[0])))_N’ > Function kind = * -> * > Arg kinds = [(I (x_a10h |> Sym (Ty (Sym co_a10r))_N), IK 'STAR)] > Fun: * > (I (x_a10h |> Sym (Ty (Sym co_a10r))_N), IK 'STAR) > }}} New description: Consider this cut-down T13822 {{{ {-# LANGUAGE GADTs, TypeOperators, DataKinds, TypeFamilies, TypeInType #-} module T13822 where import Data.Kind data KIND = STAR | KIND :> KIND data Ty :: KIND -> Type where TMaybe :: Ty (STAR :> STAR) TApp :: Ty (a :> b) -> (Ty a -> Ty b) type family IK (k :: KIND) = (res :: Type) where IK STAR = Type IK (a:>b) = IK a -> IK b type family I (t :: Ty k) = (res :: IK k) where I TMaybe = Maybe I (TApp f a) = (I f) (I a) data TyRep (k :: KIND) (t :: Ty k) where TyMaybe :: TyRep (STAR:>STAR) TMaybe TyApp :: TyRep (a:>b) f -> TyRep a x -> TyRep b (TApp f x) zero :: TyRep STAR a -> I a zero x = case x of TyApp TyMaybe _ -> Nothing }}} With a stage-1 compiler with DEBUG enabled, this program yields a Lint error in all recent versions of GHC. (NB: Lint, not an assertion failure.) With stage-2 it succeeds, and passes Lint. Reason: without DEBUG the output of the typechecker is not Linted until after a run of the `CoreOpt`; and that simplifies the coercions; which somehow eliminates the Lint error. I added`-ddump-ds-preopt` to made the pre-core-opt dump optional -- it is sometimes useful in a non-DEBUG compiler. But that makes Lint run on the pre-core-opt code, and that shows up the bug always. But an apparently unrelated patch makes it fail Lint even in stage 2. So it's kind of harmless; but a clear bug that we should fix. I'll mark T13822 as expect-broken; you can re-enable it when this ticket is fixed. The Lint error is pretty obscure {{{ *** Core Lint errors : in result of Desugar (before optimization) *** : warning: [in body of letrec with binders co_a10u :: (f_a10g :: Ty (a_a10f ':> 'STAR)) ~# (('TMaybe |> (Ty (Sym co_a10r ':> <'STAR>_N)_N)_N) :: Ty (a_a10f ':> 'STAR))] Kind application error in coercion ‘(Maybe (Sym (Coh Sym (Ty (Sym co_a10r))_N)>_N (D:R:IK[0]) ; Coh <(I (x_a10h |> Sym (Ty (Sym co_a10r))_N) |> D:R:IK[0])>_N (Sym (D:R:IK[0]))) ; Coh Sym (Ty (Sym co_a10r))_N)>_N (D:R:IK[0])))_N’ Function kind = * -> * Arg kinds = [(I (x_a10h |> Sym (Ty (Sym co_a10r))_N), IK 'STAR)] Fun: * (I (x_a10h |> Sym (Ty (Sym co_a10r))_N), IK 'STAR) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 09:26:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 09:26:47 -0000 Subject: [GHC] #14749: T13822 fails In-Reply-To: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> References: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> Message-ID: <061.378b9e5e777bed2fd488a7d88009d5a7@haskell.org> #14749: T13822 fails -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire * keywords: => TypeInType Comment: Richard, this is a seriously complicated coercion and I am lost. Could you look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 09:42:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 09:42:29 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.c8f1734f2b121dfb11fa1faa77ef32f8@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:60 goldfire]: > I think I see what's going on here. The "cached role" results are from commit 8ac966971ec6c30cc3681a913fb9fb1c2342f6cc. This version eagerly computes the role for an `NthCo` in `mkNthCo`. This means that every (`seq`ed) `NthCo` requires a role calculation. Perhaps sometimes, we create an `NthCo` and never ever check its role. If that's the case, then 8ac96 will be worse. > > On the other hand, what if you try my commit 8a6aa5030d34592200fbe799bf38abf3701544db? (Do not be thrown off by the same first two characters of the hash! I was.) That commit supplies the role to `mkNthCo`, as it can often be deduced by the caller of `mkNthCo` without too much trouble. No redundant role computation. This one should really be a clear win. I've done another run using just these three commits, and it shows that the last one is slightly better than the original situation for the `test_rules2` case, and about the same for the `Grammar.hs` case: {{{ --- ./cases/Grammar.hs --- 4eb140f564: 12.31 8ac966971e: 12.70 8a6aa5030d: 12.31 --- ./cases/test_rules2.hs --- 4eb140f564: 1.11 8ac966971e: 1.14 8a6aa5030d: 1.09 }}} So the `8ac...` commit makes things slightly worse, but at `8a6...` we're back at equal-or-better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 09:53:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 09:53:06 -0000 Subject: [GHC] #14443: Add a plugin phase that allows users to modify HsSyn before the desugarer In-Reply-To: <047.db01a8d384aae8d61e8f07147cee7c20@haskell.org> References: <047.db01a8d384aae8d61e8f07147cee7c20@haskell.org> Message-ID: <062.6a7bc3576600ca060de1ea3887e0941f@haskell.org> #14443: Add a plugin phase that allows users to modify HsSyn before the desugarer -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14709 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: => #14709 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 12:19:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 12:19:24 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.9ded96ed9efd459b8dd4cffc7b5ba159@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"db5a4b83b14bf4f1adb417b7664347fdaf637fd6/ghc" db5a4b83/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db5a4b83b14bf4f1adb417b7664347fdaf637fd6" Re-center improved perf for T3064 There's a 6% reduction in allocation on T3064. I think it's due to commit e4ab65bd57b2c39f4af52879654514bb6d5b42a0 Author: Tobias Dammers Date: Wed Jan 31 21:39:45 2018 -0500 Optimize coercionKind (Trac #11735) I'm not certain -- but, hey, it's good news }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 12:53:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 12:53:45 -0000 Subject: [GHC] #13032: Redundant forcing of Given dictionaries In-Reply-To: <046.811080f481e777da656f14add09b1cc8@haskell.org> References: <046.811080f481e777da656f14add09b1cc8@haskell.org> Message-ID: <061.3319c73a9b0a91f19c0430ec5c7e7d55@haskell.org> #13032: Redundant forcing of Given dictionaries -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T13032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"efce943ca20b55b18f948681e6b44fd892dbddd2/ghc" efce943c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="efce943ca20b55b18f948681e6b44fd892dbddd2" Add -ddump-ds-preopt This allows you to see the output immediately after desugaring but before any optimisation. I've wanted this for some time, but I was triggered into action by Trac #13032 comment:9. Interestingly, the change means that with -dcore-lint we will now Lint the output before the very simple optimiser; and this showed up Trac #14749. But that's not the fault of -ddump-ds-preopt! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 12:53:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 12:53:45 -0000 Subject: [GHC] #14749: T13822 fails In-Reply-To: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> References: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> Message-ID: <061.3ede98092e10fa566c12b9738873d87b@haskell.org> #14749: T13822 fails -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"efce943ca20b55b18f948681e6b44fd892dbddd2/ghc" efce943c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="efce943ca20b55b18f948681e6b44fd892dbddd2" Add -ddump-ds-preopt This allows you to see the output immediately after desugaring but before any optimisation. I've wanted this for some time, but I was triggered into action by Trac #13032 comment:9. Interestingly, the change means that with -dcore-lint we will now Lint the output before the very simple optimiser; and this showed up Trac #14749. But that's not the fault of -ddump-ds-preopt! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 13:02:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 13:02:35 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.e5d0d9e5fb5ad71e89b03b0f9e49bb95@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.1 (Linker) | Keywords: linker, Resolution: | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * failure: None/Unknown => Runtime crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 14:07:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 14:07:51 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.d13b403fb5355584beb0e0c897c574b4@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:67 Simon Peyton Jones ]: > In [changeset:"db5a4b83b14bf4f1adb417b7664347fdaf637fd6/ghc" db5a4b83/ghc]: > {{{ > #!CommitTicketReference repository="ghc" revision="db5a4b83b14bf4f1adb417b7664347fdaf637fd6" > Re-center improved perf for T3064 > > There's a 6% reduction in allocation on T3064. I think it's due to > > commit e4ab65bd57b2c39f4af52879654514bb6d5b42a0 > Author: Tobias Dammers > Date: Wed Jan 31 21:39:45 2018 -0500 > > Optimize coercionKind (Trac #11735) > > I'm not certain -- but, hey, it's good news > }}} We already knew that this change gives us insane improvements in at least one case, so I guess the fact that we see this reflected somewhere in the test suite is good, I presume. Wonder what T3064 does and whether it's related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 14:29:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 14:29:31 -0000 Subject: [GHC] #14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int)) In-Reply-To: <051.f7a27f9ae9b44fe3d201fa376deb4e42@haskell.org> References: <051.f7a27f9ae9b44fe3d201fa376deb4e42@haskell.org> Message-ID: <066.c32851e8505babb43a4eb19443b1fadc@haskell.org> #14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int)) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | QuantifiedConstraints wipT2893, | deriving Operating System: 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 too am skeptical that there is a robust, systematic way to do what you're seeking. I think the intent of https://ghc.haskell.org/trac/ghc/ticket/12245#comment:1 was to combine quantified constraints with `StandaloneDeriving`, not have the quantified constraints be inferred. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 14:38:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 14:38:52 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.1c791a0d56f5b7399b6efb16c4e5c8f7@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:59 simonpj]: > So the allocations are really close. Where does the extra time go? > > Can you show mutator and GC times? Maybe residency, and hence GC time, is higher? Perhaps just an accident of the moments at which major GC happens. What happens if you use use just one generation? I've done a run with `-s`, which gives us: {{{ --- ./cases/Grammar.hs --- 4eb140f564: 12.31 sec, max res. 257,842,544 8ac966971e: 12.70 sec, max res. 425,496,520 8a6aa5030d: 12.31 sec, max res. 254,680,256 --- ./cases/test_rules2.hs --- 4eb140f564: 1.11 sec, max res. 84,030,624 8ac966971e: 1.14 sec, max res. 81,325,072 8a6aa5030d: 1.09 sec, max res. 56,322,200 }}} So it looks like your hunch was about right: in the Grammar.hs case, max residency almost doubles in `8ac...`, but `8a6` then gets us back to normal; for the test_rules2.hs case, we see only improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 15:21:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 15:21:52 -0000 Subject: [GHC] #14329: GHC 8.2.1 segfaults while bootstrapping master In-Reply-To: <046.2503a1f6f14456a42761d49ce89e96f2@haskell.org> References: <046.2503a1f6f14456a42761d49ce89e96f2@haskell.org> Message-ID: <061.b0e31878585a6e8663249a6d4ae68050@haskell.org> #14329: GHC 8.2.1 segfaults while bootstrapping master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12960, #9065, | Differential Rev(s): Phab:D4075 #7762 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The recent spate of Harbormaster crashes seemingly began with the merge of Phab:D4341. However, I've tried reverting this patch with no apparent effect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 15:28:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 15:28:01 -0000 Subject: [GHC] #14674: Deferring more levity polymorphism checks in indefinite backpack modules In-Reply-To: <049.f63f9dc5c6b5c2a7debe049513b8ff01@haskell.org> References: <049.f63f9dc5c6b5c2a7debe049513b8ff01@haskell.org> Message-ID: <064.6f4af986e935d2c9733ec2b67d7c834c@haskell.org> #14674: Deferring more levity polymorphism checks in indefinite backpack modules -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): With this patch, I can get my example code to compile: {{{ diff --git a/compiler/types/Type.hs b/compiler/types/Type.hs index 3f893dbcb2..3a50fd2d3c 100644 --- a/compiler/types/Type.hs +++ b/compiler/types/Type.hs @@ -2348,7 +2348,7 @@ isTypeLevPoly = go go ty@(TyVarTy {}) = check_kind ty go ty@(AppTy {}) = check_kind ty go ty@(TyConApp tc _) | not (isTcLevPoly tc) = False - | otherwise = check_kind ty + | otherwise = False -- check_kind ty go (ForAllTy _ ty) = go ty go (FunTy {}) = False go (LitTy {}) = False }}} Of course, this is not acceptable since it disables the levity binder check for type families in both indefinite modules and in conventional modules. Just for context, here is the full function definition (before applying the above patch): {{{ -- | Returns True if a type is levity polymorphic. Should be the same -- as (isKindLevPoly . typeKind) but much faster. -- Precondition: The type has kind (TYPE blah) isTypeLevPoly :: Type -> Bool isTypeLevPoly = go where go ty@(TyVarTy {}) = check_kind ty go ty@(AppTy {}) = check_kind ty go ty@(TyConApp tc _) | not (isTcLevPoly tc) = False | otherwise = False -- check_kind ty go (ForAllTy _ ty) = go ty go (FunTy {}) = False go (LitTy {}) = False go ty@(CastTy {}) = check_kind ty go ty@(CoercionTy {}) = pprPanic "isTypeLevPoly co" (ppr ty) check_kind = isKindLevPoly . typeKind }}} One way to solve this is to make `isTypeLevPoly` take an additional argument that tells it what type of module we are in. But there might be an easier solution. I don't what `TyCon` indefinite data types (is that what they are called?) like `MyLiftedness` are represented in GHC. I'm guessing that it's `AlgTyCon`. There may be something inside `AlgTyCon` that can be used to figure out where of not it's an indefinite data type (for example, if it has a kind other than `Type` and it isn't a builtin type). If that's the case, then in the `TyConApp` check above, we could check to see if we're looking at a type family. If so, if any on the arguments are indefinite data types, then we could say that it's alright, since this could only happen in an indefinite module. I need feedback on this since though I'm not familiar with these things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 15:32:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 15:32:28 -0000 Subject: [GHC] #14674: Deferring more levity polymorphism checks in indefinite backpack modules In-Reply-To: <049.f63f9dc5c6b5c2a7debe049513b8ff01@haskell.org> References: <049.f63f9dc5c6b5c2a7debe049513b8ff01@haskell.org> Message-ID: <064.3f312facc11e78f0ad84d32ce8d0c42f@haskell.org> #14674: Deferring more levity polymorphism checks in indefinite backpack modules -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): We need Edward! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 15:54:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 15:54:08 -0000 Subject: [GHC] #14750: Plugins should be loaded once for each module rather than multiple times Message-ID: <049.cd2d2a6d948eae1dc998bdaf54aa51ad@haskell.org> #14750: Plugins should be loaded once for each module rather than multiple times -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: plugins | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Plugins are currently loaded immediately before they are used in the simplifier and constraint solver. It would be better to load them once, at the start of the pipeline rather than at each of these different places. lazer already has a patch which achieves this. I'm making it a separate ticket as it need not be blocked on the progress of #14709 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 15:54:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 15:54:31 -0000 Subject: [GHC] #14750: Plugins should be loaded once for each module rather than multiple times In-Reply-To: <049.cd2d2a6d948eae1dc998bdaf54aa51ad@haskell.org> References: <049.cd2d2a6d948eae1dc998bdaf54aa51ad@haskell.org> Message-ID: <064.5f7209f1e974b36fd41415f38914e12f@haskell.org> #14750: Plugins should be loaded once for each module rather than multiple times -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: lazar (removed) * cc: lazac (added) Old description: > Plugins are currently loaded immediately before they are used in the > simplifier and constraint solver. It would be better to load them once, > at the start of the pipeline rather than at each of these different > places. > > lazer already has a patch which achieves this. I'm making it a separate > ticket as it need not be blocked on the progress of #14709 New description: Plugins are currently loaded immediately before they are used in the simplifier and constraint solver. It would be better to load them once, at the start of the pipeline rather than at each of these different places. lazac already has a patch which achieves this. I'm making it a separate ticket as it need not be blocked on the progress of #14709 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 16:56:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 16:56:22 -0000 Subject: [GHC] #14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures In-Reply-To: <046.1ed8f551eed623189a3adefebbf7dccb@haskell.org> References: <046.1ed8f551eed623189a3adefebbf7dccb@haskell.org> Message-ID: <061.8b871e196363fd1c13a9e914e0cff775@haskell.org> #14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures -------------------------------------+------------------------------------- Reporter: mitchty | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 bgamari): Which linker are you using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 17:14:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 17:14:47 -0000 Subject: [GHC] #14661: Cannot derive (newtype I a b = I (F a -> F b) deriving newtype Category) for type family F In-Reply-To: <051.db51abc527e2395586903121a4d671be@haskell.org> References: <051.db51abc527e2395586903121a4d671be@haskell.org> Message-ID: <066.1b951276f4eea51227d874e3a42ef4af@haskell.org> #14661: Cannot derive (newtype I a b = I (F a -> F b) deriving newtype Category) for type family F -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: wontfix | Keywords: | DerivingStrategies, deriving, | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I had a burning curiosity, so I quickly implemented the ideas sketched out in comment:14 to see if they'd work. To my great surprise, the changes almost work perfectly! But I did use the word "almost"—there's a pretty big snag that prevents `newtype ENDO = ENDO (forall xx. Endo xx) deriving Semigroup` from working. To better explain what's going on, here is the code that `-ddump-deriv` is producing: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Coerce import Data.Kind import Data.List.NonEmpty import Data.Monoid import Data.Semigroup newtype ENDO = ENDO (forall a. Endo a) instance Semigroup ENDO where (<>) = coerce @((forall (a_a3ZJ :: Type). Endo a_a3ZJ) -> (forall (a_a3ZJ :: Type). Endo a_a3ZJ) -> forall (a_a3ZJ :: Type). Endo a_a3ZJ) @(ENDO -> ENDO -> ENDO) (<>) sconcat = coerce @(NonEmpty (forall (a_a3ZJ :: Type). Endo a_a3ZJ) -> forall (a_a3ZJ :: Type). Endo a_a3ZJ) @(NonEmpty ENDO -> ENDO) sconcat stimes = coerce @(forall (b_a2d8 :: Type). Integral b_a2d8 => b_a2d8 -> (forall (a_a3ZJ :: Type). Endo a_a3ZJ) -> forall (a_a3ZJ :: Type). Endo a_a3ZJ) @(forall (b_a2d8 :: Type). Integral b_a2d8 => b_a2d8 -> ENDO -> ENDO) stimes }}} `(<>)` and `stimes` actually typecheck without issue, to my great joy. But alas, `sconcat` does not: {{{ Bug.hs:25:9: error: • Couldn't match type ‘forall a_a3ZJ1. Endo a_a3ZJ1’ with ‘Endo a_a3ZJ’ Expected type: NonEmpty (forall a_a3ZJ1. Endo a_a3ZJ1) -> Endo a_a3ZJ Actual type: NonEmpty (Endo a_a3ZJ) -> Endo a_a3ZJ • In the third argument of ‘coerce’, namely ‘sconcat’ In the expression: coerce @(NonEmpty (forall (a_a3ZJ :: Type). Endo a_a3ZJ) -> forall (a_a3ZJ :: Type). Endo a_a3ZJ) @(NonEmpty ENDO -> ENDO) sconcat In an equation for ‘sconcat’: sconcat = coerce @(NonEmpty (forall (a_a3ZJ :: Type). Endo a_a3ZJ) -> forall (a_a3ZJ :: Type). Endo a_a3ZJ) @(NonEmpty ENDO -> ENDO) sconcat | 25 | sconcat | ^^^^^^^ }}} It seems that GHC is unwilling to instantiate `sconcat` at an impredicative type, even with `ImpredicativeTypes` enabled. What's annoying is that //this// typechecks: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} module Bug2 where import Data.Coerce import Data.Monoid import Data.List.NonEmpty import Data.Semigroup newtype ENDO = ENDO (forall a. Endo a) test :: (NonEmpty (forall a. Endo a) -> (forall a. Endo a)) -> (NonEmpty ENDO -> ENDO) test = coerce @(NonEmpty (forall a. Endo a) -> (forall a. Endo a)) @(NonEmpty ENDO -> ENDO) }}} But, as we saw in the earlier example, trying to give `sconcat` as an argument to a function with such a type signature would cause GHC to choke. It seems that we'd need more impredicative smarts to make this all work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 18:02:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 18:02:06 -0000 Subject: [GHC] #14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures In-Reply-To: <046.1ed8f551eed623189a3adefebbf7dccb@haskell.org> References: <046.1ed8f551eed623189a3adefebbf7dccb@haskell.org> Message-ID: <061.1749a3719b44746dc547b24e28ae3984@haskell.org> #14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures -------------------------------------+------------------------------------- Reporter: mitchty | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 mitchty): ld.gold, ld.bfd is affected by this: configure: error: Your linker is affected by binutils #16177, which critically breaks linkage of GHC objects. Please either upgrade binutils or supply a different linker with the LD environment variable. Even when I tried patching it with the binutils patches that configure error got tripped up. Should I retry with patched binutils and ld.bfd? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 18:47:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 18:47:42 -0000 Subject: [GHC] #14312: Head does not build on Windows with the default make config. In-Reply-To: <047.086b87bb9b3dcf2f7a921149fa31eda2@haskell.org> References: <047.086b87bb9b3dcf2f7a921149fa31eda2@haskell.org> Message-ID: <062.36fe1d60708bde4ea1aae6ab4b1546ba@haskell.org> #14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4080 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): No indeed, it doesn't need to be in 8.4. `Directory` renamed the file, but we should fix it. I can't land the patch myself since I don't have bits to haddock. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 19:56:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 19:56:30 -0000 Subject: [GHC] #14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures In-Reply-To: <046.1ed8f551eed623189a3adefebbf7dccb@haskell.org> References: <046.1ed8f551eed623189a3adefebbf7dccb@haskell.org> Message-ID: <061.bba44261bf3e7c784f27e1f9844e3de2@haskell.org> #14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures -------------------------------------+------------------------------------- Reporter: mitchty | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 mitchty): Actually just noticed there is a new patch in the ticket, applied that and rebuilt binutils and am trying to build ghc 8.2.2 with ld.bfd instead of ld.gold. First time that configure check has passed so far. So my backport of that patch before was probably wrong. I'll keep you apprised. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 20:01:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 20:01:27 -0000 Subject: [GHC] #14751: GHC wrongly warns of incomplete pattern matches when using pattern synonyms. Message-ID: <052.c392b47087ff5e140012824dd34da2ab@haskell.org> #14751: GHC wrongly warns of incomplete pattern matches when using pattern synonyms. -------------------------------------+------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.4.1-alpha1 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: -------------------------------------+------------------------------------- If one writes the following code: {{{ {-# LANGUAGE PatternSynonyms #-} module Version where newtype Version = Version [Integer] deriving (Eq) pattern V :: [Integer] -> Version pattern V is = Version is instance Ord Version where (V []) <= (V []) = True (V []) <= _ = True _ <= (Version []) = False (V (x:xs)) <= (V (y:ys)) | x == y = Version xs <= Version ys | otherwise = x <= y }}} and compiles with {{{ghc -Wall -Werror}}}, one gets the following message: {{{ [1 of 1] Compiling Version ( Bug.hs, Bug.o ) Bug.hs:12:5: error: [-Wincomplete-patterns, -Werror=incomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘<=’: Patterns not matched: _ _ _ _ _ _ _ _ | 12 | (V []) <= (V []) = True | ^^^^^^^^^^^^^^^^^^^^^^^... }}} However, the following code compiles correctly without warnings: {{{ {-# LANGUAGE PatternSynonyms #-} module Version where newtype Version = Version [Integer] deriving (Eq) instance Ord Version where (Version []) <= (Version []) = True (Version []) <= _ = True _ <= (Version []) = False (Version (x:xs)) <= (Version (y:ys)) | x == y = Version xs <= Version ys | otherwise = x <= y }}} This bug appears in GHC 8.2.2 as well as GHC-8.4.1-alpha2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 20:09:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 20:09:42 -0000 Subject: [GHC] #14751: GHC wrongly warns of incomplete pattern matches when using pattern synonyms. In-Reply-To: <052.c392b47087ff5e140012824dd34da2ab@haskell.org> References: <052.c392b47087ff5e140012824dd34da2ab@haskell.org> Message-ID: <067.3d97ac040983adfdac6222cca6b2f4e5@haskell.org> #14751: GHC wrongly warns of incomplete pattern matches when using pattern synonyms. -------------------------------------+------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: duplicate | 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 nomeata): * status: new => closed * resolution: => duplicate Comment: This is expected behaviour: Because pattern synonyms can do arbitrary computations, the compiler does not even attempt to detect when they are complete. You can specify {{{ {-# COMPLETE V #-} }}} to declare that the `V` pattern is complete. Also see #8779. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 20:35:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 20:35:07 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.f6a3b99df2b6ca569ee91a221250a024@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Phab:D4009 Wiki Page: | -------------------------------------+------------------------------------- Comment (by allbery_b): This doesn't consider platforms that use clang as their compiler. And there's been at least one person trying to use icc recently, which iirc used to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 20:35:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 20:35:53 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.59cc4c4836170ca171d6208b3827b2bd@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Phab:D4009 Wiki Page: | -------------------------------------+------------------------------------- Comment (by allbery_b): uh, I should specify that I mean the configure test doesn't. (I have no idea if icc even has these primitives, or whether they look like gcc's.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 21:49:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 21:49:37 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.1eb11fe4054e8309cfb70a3104756cca@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Phab:D4009 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > uh, I should specify that I mean the configure test doesn't. What precisely is the problem? As far as I can tell Clang has supported both `__atomic_*` and `__sync_* builtins at least as far back as LLVM 3.4. I'm fairly certain that `__sync_*` are supported by `icc` as I have read that this builtins were stolen by `gcc` from `icc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 23:05:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 23:05:16 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.ee1914cbb59187f4d2fc9da9d66c4831@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 mpickering): Thanks, good example. I can compile it now with {{{ ghc src/Main.hs -isrc }}} Perhaps someone with a profiling tree already built can quickly run it on this program to see what is causing the allocations? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 1 23:40:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Feb 2018 23:40:33 -0000 Subject: [GHC] #14752: Unboxed sums documentation looks wrong Message-ID: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> #14752: Unboxed sums documentation looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: Documentation | Version: 8.2.2 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to the documentation, > In the case of enumeration types (like `Bool`), the unboxed sum layout only has an `Int32` field (i.e. the whole thing is represented by an integer). This does not actually seem to be true. {{{#!hs right :: Bool -> (# (# #) | Bool #) right x = (# | x #) test :: (# (# #) | Bool #) -> Bool test (# (# #) | #) = False test (# | _ #) -> True }}} If the documentation were correct, I would expect `test (right undefined)` to be `undefined`, but it is `True`. Either we should fix the documentation to match reality or the reality to match the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 01:03:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 01:03:28 -0000 Subject: [GHC] #14674: Deferring more levity polymorphism checks in indefinite backpack modules In-Reply-To: <049.f63f9dc5c6b5c2a7debe049513b8ff01@haskell.org> References: <049.f63f9dc5c6b5c2a7debe049513b8ff01@haskell.org> Message-ID: <064.d6edb741d1a723cb0ed732de1275e83a@haskell.org> #14674: Deferring more levity polymorphism checks in indefinite backpack modules -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I just realized a huge problem with what I'm trying to do. It doesn't even work when there isn't any levity polymorphism involved. Behold: {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} unit the-fam where module TheFamily where import Data.Kind data Universe = Red | Green data SingUniverse (x :: Universe) where SingRed :: SingUniverse 'Red SingGreen :: SingUniverse 'Green type family Interpret (x :: Universe) :: Type where Interpret 'Red = Bool Interpret 'Green = Int unit number-indefinite where dependency the-fam signature NumberUnknown where import GHC.Types import TheFamily data MyUniverse :: Universe module NumberStuff where import NumberUnknown import TheFamily universalDefault :: SingUniverse MyUniverse -> Interpret MyUniverse universalDefault SingRed = True universalDefault SingGreen = 55 unit main where module Main where main :: IO () main = print (identityInt 5) }}} This is rejected with: {{{ backpack_type_refinement.bkp:30:32: error: • Could not deduce: Interpret MyUniverse ~ Bool from the context: MyUniverse ~ 'Red bound by a pattern with constructor: SingRed :: SingUniverse 'Red, in an equation for ‘universalDefault’ at backpack_type_refinement.bkp:30:22-28 • In the expression: True In an equation for ‘universalDefault’: universalDefault SingRed = True | 30 | universalDefault SingRed = True | ^^^^ }}} And with a similar error for the subsequent line. It is entirely reasonable for this to be rejected. I'm going to close this ticket for now and reconsider my approach to what I'm trying to accomplish. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 01:03:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 01:03:43 -0000 Subject: [GHC] #14674: Deferring more levity polymorphism checks in indefinite backpack modules In-Reply-To: <049.f63f9dc5c6b5c2a7debe049513b8ff01@haskell.org> References: <049.f63f9dc5c6b5c2a7debe049513b8ff01@haskell.org> Message-ID: <064.6fcdb17a809c0c7bab1cf46550e174af@haskell.org> #14674: Deferring more levity polymorphism checks in indefinite backpack modules -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: invalid | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by andrewthad): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 10:15:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 10:15:13 -0000 Subject: [GHC] #14381: Consider making ghc-pkg fill in abi-depends based on depends In-Reply-To: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> References: <045.a757b4d974e51bd6ab6f6869ba65de4c@haskell.org> Message-ID: <060.aa21e86a304e5a16151be44c8b2c2b36@haskell.org> #14381: Consider making ghc-pkg fill in abi-depends based on depends -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: ghc-pkg | Version: 8.2.1 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:D4159 Wiki Page: | -------------------------------------+------------------------------------- Comment (by juhpetersen): So far seems to be working great on 8.2.2, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 12:58:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 12:58:16 -0000 Subject: [GHC] #13511: ApplicativeDo return case doesn't handle lets In-Reply-To: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> References: <047.48d4a8893afaf80b1c699984acfc24f1@haskell.org> Message-ID: <062.9ada6620270f8c5c7d5806bb760384b8@haskell.org> #13511: ApplicativeDo return case doesn't handle lets -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chshersh): I experienced similar issue with `-XApplicativeDo` while using `-XRecordWildCards` and `optparse-applicative` library. What I wanted to write: {{{#!hs data Options = Options { reportTime :: Integer } optionsParser :: Parser Options optionsParser = do hours <- option auto $ long "hours" minutes <- option auto $ long "minutes" let reportTime = hours * 60 + minutes pure Options{..} }}} What helped is to write it like this: {{{#!hs data Options = Options { reportTime :: Integer } optionsParser :: Parser Options optionsParser = do hours <- option auto $ long "hours" minutes <- option auto $ long "minutes" pure Options{ reportTime = hours * 60 + minutes } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 13:56:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 13:56:43 -0000 Subject: [GHC] #14752: Unboxed sums documentation looks wrong In-Reply-To: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> References: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> Message-ID: <060.e0fe5b58882d9bdc40782230bb4f12cc@haskell.org> #14752: Unboxed sums documentation looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): If you generate STG and Cmm for this program: {{{ {-# LANGUAGE UnboxedSums, UnboxedTuples, MagicHash #-} module Lib where type UnboxedBool = (# (# #) | (# #) #) unboxBool :: Bool -> UnboxedBool unboxBool True = (# (# #) | #) unboxBool False = (# | (# #) #) boxBool :: UnboxedBool -> Bool boxBool (# (# #) | #) = True boxBool (# | (# #) #) = False }}} you'll see that `UnboxedBool` is clearly represented as single integer. In your program, I don't understand why you expect your `Bool` to be unboxed. You can put bottom values in unboxed tuples/sums so everything seems fine here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 14:21:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 14:21:50 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.ea057ab3bdcfd8725aad95461c675fbb@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1259 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 15:43:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 15:43:22 -0000 Subject: [GHC] #14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures In-Reply-To: <046.1ed8f551eed623189a3adefebbf7dccb@haskell.org> References: <046.1ed8f551eed623189a3adefebbf7dccb@haskell.org> Message-ID: <061.7e373bc3d7e41cf3ef6b0eba624f8c2f@haskell.org> #14739: Cannot compile ghc 8.2.1 or 8.2.2 on armv7l architectures -------------------------------------+------------------------------------- Reporter: mitchty | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 mitchty): Yep, same crash in the same spot with ld.bfd even with the patch in #16177. {{{ "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.13.1.0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id base-4.10.1.0 -package-id filepath-1.4.1.2 -package-id directory-1.3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.1.0 -package-id ghc-boot-8.2.2 -package-id ghc-8.2.2 -package-id bytestring-0.10.8.2 -package-id transformers-0.5.2.0 -funbox- strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user- package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad-instances -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/driver/ResponseFile.hs -o utils/haddock/dist/build/ResponseFile.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.13.1.0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id base-4.10.1.0 -package-id filepath-1.4.1.2 -package-id directory-1.3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.1.0 -package-id ghc-boot-8.2.2 -package-id ghc-8.2.2 -package-id bytestring-0.10.8.2 -package-id transformers-0.5.2.0 -funbox- strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user- package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad-instances -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-api/src/Haddock/GhcUtils.hs -o utils/haddock/dist/build/Haddock/GhcUtils.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.13.1.0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id base-4.10.1.0 -package-id filepath-1.4.1.2 -package-id directory-1.3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.1.0 -package-id ghc-boot-8.2.2 -package-id ghc-8.2.2 -package-id bytestring-0.10.8.2 -package-id transformers-0.5.2.0 -funbox- strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user- package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad-instances -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker/Types.hs -o utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/haddock-api/src -iutils/haddock/haddock- library/vendor/attoparsec-0.13.1.0 -iutils/haddock/haddock-library/src -iutils/haddock/dist/build -Iutils/haddock/dist/build -iutils/haddock/dist/build/haddock/autogen -Iutils/haddock/dist/build/haddock/autogen -optP-DIN_GHC_TREE -optP- include -optPutils/haddock/dist/build/haddock/autogen/cabal_macros.h -package-id base-4.10.1.0 -package-id filepath-1.4.1.2 -package-id directory-1.3.0.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id array-0.5.2.0 -package-id xhtml-3000.2.2 -package-id Cabal-2.0.1.0 -package-id ghc-boot-8.2.2 -package-id ghc-8.2.2 -package-id bytestring-0.10.8.2 -package-id transformers-0.5.2.0 -funbox- strict-fields -Wall -fwarn-tabs -O2 -threaded -XHaskell2010 -no-user- package-db -rtsopts -Wno-unused-imports -Wno-deprecations -Wnoncanonical-monad-instances -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs -o utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/ResponseFile.dyn_o] Segmentation fault make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/GhcUtils.dyn_o] Segmentation fault make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Segmentation fault make[1]: *** [utils/haddock/ghc.mk:21: utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Segmentation fault }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 16:03:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 16:03:05 -0000 Subject: [GHC] #14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum# In-Reply-To: <050.ae9e72a72ce45f0a50476094399e0e2c@haskell.org> References: <050.ae9e72a72ce45f0a50476094399e0e2c@haskell.org> Message-ID: <065.e8d44a26e4a3721c7070e426fca1ab08@haskell.org> #14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum# -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 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): Ryan and I talked by Skype. It seems that `dataToTag#` is truly polymorphic (works for values of any type), and GHC happily accepts {{{ get :: forall a. a -> Int# get x = getTag x }}} `dataToTag#` will never crash; it'll just fetch a tag from its argument's info table. Given that, the Right Thing is just to make sure that the optimisatio rule in `PrelRules` has enough side conditions. Currently it says {{{ caseRules _ (App (App (Var f) (Type ty)) v) -- dataToTag x | Just DataToTagOp <- isPrimOpId_maybe f = Just (v, tx_con_dtt ty , \v -> App (App (Var f) (Type ty)) (Var v)) }}} But it should also check that `ty` is a proper data type; if not, return `Nothing` (i.e. don't optimise). Easy. Ryan is on the job. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 16:14:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 16:14:32 -0000 Subject: [GHC] #14693: Computing imp_finst can take up significant amount of time In-Reply-To: <046.a9caa20b4ad6e8f61c2910051e03ba80@haskell.org> References: <046.a9caa20b4ad6e8f61c2910051e03ba80@haskell.org> Message-ID: <061.79f414cbe470f37506a6aa6d5cf8bfed@haskell.org> #14693: Computing imp_finst can take up significant amount of time -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 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): phab:D4369 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * status: new => patch * differential: => phab:D4369 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 16:27:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 16:27:23 -0000 Subject: [GHC] #14753: Assembly for stg_enter_info starts with a dead 'mov' Message-ID: <048.a722d0a688d59779566750f3524a6624@haskell.org> #14753: Assembly for stg_enter_info starts with a dead 'mov' -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.4.1-alpha1 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the course of my investigation in #14675, I happened to look at the x86_64 assembly for `stg_enter_info`, through gdb: {{{#!asm Breakpoint 2, stg_enter_info () at rts/HeapStackCheck.cmm:166 166 { (gdb) disassemble Dump of assembler code for function stg_enter_info: => 0x0000000002cf5900 <+0>: mov 0x0(%rbp),%rax 0x0000000002cf5904 <+4>: mov 0x8(%rbp),%rax 0x0000000002cf5908 <+8>: test $0x7,%al 0x0000000002cf590a <+10>: jne 0x2cf593d 0x0000000002cf590c <+12>: mov (%rax),%rbx 0x0000000002cf590f <+15>: cmpl $0x1a,-0x8(%rbx) 0x0000000002cf5913 <+19>: jb 0x2cf5947 0x0000000002cf5915 <+21>: cmpl $0x1c,-0x8(%rbx) 0x0000000002cf5919 <+25>: jb 0x2cf592d 0x0000000002cf591b <+27>: cmpl $0x1d,-0x8(%rbx) 0x0000000002cf591f <+31>: jb 0x2cf5933 0x0000000002cf5921 <+33>: mov %rbx,%rcx 0x0000000002cf5924 <+36>: mov %rax,%rbx 0x0000000002cf5927 <+39>: add $0x10,%rbp 0x0000000002cf592b <+43>: jmpq *%rcx 0x0000000002cf592d <+45>: cmpl $0x1b,-0x8(%rbx) 0x0000000002cf5931 <+49>: jb 0x2cf5921 0x0000000002cf5933 <+51>: mov 0x8(%rax),%rax 0x0000000002cf5937 <+55>: mov %rax,0x8(%rbp) 0x0000000002cf593b <+59>: jmp 0x2cf5908 0x0000000002cf593d <+61>: mov %rax,%rbx 0x0000000002cf5940 <+64>: add $0x10,%rbp 0x0000000002cf5944 <+68>: jmpq *0x0(%rbp) 0x0000000002cf5947 <+71>: cmpl $0xf,-0x8(%rbx) 0x0000000002cf594b <+75>: jb 0x2cf5969 0x0000000002cf594d <+77>: cmpl $0x19,-0x8(%rbx) 0x0000000002cf5951 <+81>: jb 0x2cf595d 0x0000000002cf5953 <+83>: mov %rax,%rbx 0x0000000002cf5956 <+86>: add $0x10,%rbp 0x0000000002cf595a <+90>: jmpq *0x0(%rbp) 0x0000000002cf595d <+93>: movslq -0x8(%rbx),%rcx 0x0000000002cf5961 <+97>: cmp $0x17,%rcx 0x0000000002cf5965 <+101>: jne 0x2cf5921 0x0000000002cf5967 <+103>: jmp 0x2cf5953 0x0000000002cf5969 <+105>: cmpl $0x8,-0x8(%rbx) 0x0000000002cf596d <+109>: jb 0x2cf5921 0x0000000002cf596f <+111>: movslq -0x8(%rbx),%rbx 0x0000000002cf5973 <+115>: add $0xfffffffffffffff8,%rbx 0x0000000002cf5977 <+119>: jmpq *0x2e36d90(,%rbx,8) }}} Notice the first two instructions: {{{#!asm mov 0x0(%rbp),%rax mov 0x8(%rbp),%rax }}} We successively write two different things to `rax`, making the first `mov` effectively useless. I'm not quite sure the impact is of any significance but it still seems worth writing this down and addressing it at some point in the future, as there's just no way that first instruction will ever be useful. I think the assembly is generated from [https://github.com/ghc/ghc/blob/master/rts/HeapStackCheck.cmm#L164 this code], which in turns call [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L301 `ENTER`], which in turns calls [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L272 `LOAD_INFO`], which appears to rcorrespond to the first few instructions in the assembly I pasted, if we ignore the extra `mov`. (Assembly generated by ghc 8.4.1 built from the same commit as the alpha1 for 8.4.1 from hvr's PPA, in a 64bits Ubuntu VM. Not sure we generate a dead `mov` with the other codegens, haven't tested.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 16:29:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 16:29:30 -0000 Subject: [GHC] #14753: Assembly for stg_enter_info starts with a dead 'mov' In-Reply-To: <048.a722d0a688d59779566750f3524a6624@haskell.org> References: <048.a722d0a688d59779566750f3524a6624@haskell.org> Message-ID: <063.92f7ae77ace3a8a3ade4b4f62664c044@haskell.org> #14753: Assembly for stg_enter_info starts with a dead 'mov' -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.4.1-alpha1 (CodeGen) | 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: | -------------------------------------+------------------------------------- Description changed by alpmestan: Old description: > In the course of my investigation in #14675, I happened to look at the > x86_64 assembly for `stg_enter_info`, through gdb: > > {{{#!asm > Breakpoint 2, stg_enter_info () at rts/HeapStackCheck.cmm:166 > 166 { > (gdb) disassemble > Dump of assembler code for function stg_enter_info: > => 0x0000000002cf5900 <+0>: mov 0x0(%rbp),%rax > 0x0000000002cf5904 <+4>: mov 0x8(%rbp),%rax > 0x0000000002cf5908 <+8>: test $0x7,%al > 0x0000000002cf590a <+10>: jne 0x2cf593d > 0x0000000002cf590c <+12>: mov (%rax),%rbx > 0x0000000002cf590f <+15>: cmpl $0x1a,-0x8(%rbx) > 0x0000000002cf5913 <+19>: jb 0x2cf5947 > 0x0000000002cf5915 <+21>: cmpl $0x1c,-0x8(%rbx) > 0x0000000002cf5919 <+25>: jb 0x2cf592d > 0x0000000002cf591b <+27>: cmpl $0x1d,-0x8(%rbx) > 0x0000000002cf591f <+31>: jb 0x2cf5933 > 0x0000000002cf5921 <+33>: mov %rbx,%rcx > 0x0000000002cf5924 <+36>: mov %rax,%rbx > 0x0000000002cf5927 <+39>: add $0x10,%rbp > 0x0000000002cf592b <+43>: jmpq *%rcx > 0x0000000002cf592d <+45>: cmpl $0x1b,-0x8(%rbx) > 0x0000000002cf5931 <+49>: jb 0x2cf5921 > 0x0000000002cf5933 <+51>: mov 0x8(%rax),%rax > 0x0000000002cf5937 <+55>: mov %rax,0x8(%rbp) > 0x0000000002cf593b <+59>: jmp 0x2cf5908 > 0x0000000002cf593d <+61>: mov %rax,%rbx > 0x0000000002cf5940 <+64>: add $0x10,%rbp > 0x0000000002cf5944 <+68>: jmpq *0x0(%rbp) > 0x0000000002cf5947 <+71>: cmpl $0xf,-0x8(%rbx) > 0x0000000002cf594b <+75>: jb 0x2cf5969 > 0x0000000002cf594d <+77>: cmpl $0x19,-0x8(%rbx) > 0x0000000002cf5951 <+81>: jb 0x2cf595d > 0x0000000002cf5953 <+83>: mov %rax,%rbx > 0x0000000002cf5956 <+86>: add $0x10,%rbp > 0x0000000002cf595a <+90>: jmpq *0x0(%rbp) > 0x0000000002cf595d <+93>: movslq -0x8(%rbx),%rcx > 0x0000000002cf5961 <+97>: cmp $0x17,%rcx > 0x0000000002cf5965 <+101>: jne 0x2cf5921 > 0x0000000002cf5967 <+103>: jmp 0x2cf5953 > 0x0000000002cf5969 <+105>: cmpl $0x8,-0x8(%rbx) > 0x0000000002cf596d <+109>: jb 0x2cf5921 > 0x0000000002cf596f <+111>: movslq -0x8(%rbx),%rbx > 0x0000000002cf5973 <+115>: add $0xfffffffffffffff8,%rbx > 0x0000000002cf5977 <+119>: jmpq *0x2e36d90(,%rbx,8) > }}} > > Notice the first two instructions: > > {{{#!asm > mov 0x0(%rbp),%rax > mov 0x8(%rbp),%rax > }}} > > We successively write two different things to `rax`, making the first > `mov` effectively useless. I'm not quite sure the impact is of any > significance but it still seems worth writing this down and addressing it > at some point in the future, as there's just no way that first > instruction will ever be useful. > > I think the assembly is generated from > [https://github.com/ghc/ghc/blob/master/rts/HeapStackCheck.cmm#L164 this > code], which in turns call > [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L301 `ENTER`], > which in turns calls > [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L272 `LOAD_INFO`], > which appears to rcorrespond to the first few instructions in the > assembly I pasted, if we ignore the extra `mov`. > > (Assembly generated by ghc 8.4.1 built from the same commit as the alpha1 > for 8.4.1 from hvr's PPA, in a 64bits Ubuntu VM. Not sure we generate a > dead `mov` with the other codegens, haven't tested.) New description: In the course of my investigation in #14675, I happened to look at the x86_64 assembly for `stg_enter_info`, through gdb: {{{#!asm Breakpoint 2, stg_enter_info () at rts/HeapStackCheck.cmm:166 166 { (gdb) disassemble Dump of assembler code for function stg_enter_info: => 0x0000000002cf5900 <+0>: mov 0x0(%rbp),%rax 0x0000000002cf5904 <+4>: mov 0x8(%rbp),%rax 0x0000000002cf5908 <+8>: test $0x7,%al 0x0000000002cf590a <+10>: jne 0x2cf593d 0x0000000002cf590c <+12>: mov (%rax),%rbx 0x0000000002cf590f <+15>: cmpl $0x1a,-0x8(%rbx) 0x0000000002cf5913 <+19>: jb 0x2cf5947 0x0000000002cf5915 <+21>: cmpl $0x1c,-0x8(%rbx) 0x0000000002cf5919 <+25>: jb 0x2cf592d 0x0000000002cf591b <+27>: cmpl $0x1d,-0x8(%rbx) 0x0000000002cf591f <+31>: jb 0x2cf5933 0x0000000002cf5921 <+33>: mov %rbx,%rcx 0x0000000002cf5924 <+36>: mov %rax,%rbx 0x0000000002cf5927 <+39>: add $0x10,%rbp 0x0000000002cf592b <+43>: jmpq *%rcx 0x0000000002cf592d <+45>: cmpl $0x1b,-0x8(%rbx) 0x0000000002cf5931 <+49>: jb 0x2cf5921 0x0000000002cf5933 <+51>: mov 0x8(%rax),%rax 0x0000000002cf5937 <+55>: mov %rax,0x8(%rbp) 0x0000000002cf593b <+59>: jmp 0x2cf5908 0x0000000002cf593d <+61>: mov %rax,%rbx 0x0000000002cf5940 <+64>: add $0x10,%rbp 0x0000000002cf5944 <+68>: jmpq *0x0(%rbp) 0x0000000002cf5947 <+71>: cmpl $0xf,-0x8(%rbx) 0x0000000002cf594b <+75>: jb 0x2cf5969 0x0000000002cf594d <+77>: cmpl $0x19,-0x8(%rbx) 0x0000000002cf5951 <+81>: jb 0x2cf595d 0x0000000002cf5953 <+83>: mov %rax,%rbx 0x0000000002cf5956 <+86>: add $0x10,%rbp 0x0000000002cf595a <+90>: jmpq *0x0(%rbp) 0x0000000002cf595d <+93>: movslq -0x8(%rbx),%rcx 0x0000000002cf5961 <+97>: cmp $0x17,%rcx 0x0000000002cf5965 <+101>: jne 0x2cf5921 0x0000000002cf5967 <+103>: jmp 0x2cf5953 0x0000000002cf5969 <+105>: cmpl $0x8,-0x8(%rbx) 0x0000000002cf596d <+109>: jb 0x2cf5921 0x0000000002cf596f <+111>: movslq -0x8(%rbx),%rbx 0x0000000002cf5973 <+115>: add $0xfffffffffffffff8,%rbx 0x0000000002cf5977 <+119>: jmpq *0x2e36d90(,%rbx,8) }}} Notice the first two instructions: {{{#!asm mov 0x0(%rbp),%rax mov 0x8(%rbp),%rax }}} We successively write two different things to `rax`, making the first `mov` effectively useless. I'm not quite sure the impact is of any significance but it still seems worth writing this down and addressing it at some point in the future, as there's just no way that first instruction will ever be useful. I think the assembly is generated from [https://github.com/ghc/ghc/blob/master/rts/HeapStackCheck.cmm#L164 this code], which in turns call [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L301 ENTER], which in turns calls [https://github.com/ghc/ghc/blob/master/includes/Cmm.h#L272 LOAD_INFO], which appears to rcorrespond to the first few instructions in the assembly I pasted, if we ignore the extra `mov`. (Assembly generated by ghc 8.4.1 built from the same commit as the alpha1 for 8.4.1 from hvr's PPA, in a 64bits Ubuntu VM. Not sure we generate a dead `mov` with the other codegens, haven't tested.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 16:36:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 16:36:21 -0000 Subject: [GHC] #14736: unknown opcode in interpretBCO doesn't cause process termination in some circumstances In-Reply-To: <048.0feddee2e38487d10728e415c10a48f5@haskell.org> References: <048.0feddee2e38487d10728e415c10a48f5@haskell.org> Message-ID: <063.641a53d82a2892c4b5426232222cb68e@haskell.org> #14736: unknown opcode in interpretBCO doesn't cause process termination in some circumstances ---------------------------------+---------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by alpmestan): * status: new => closed * resolution: => invalid Comment: I have been misled by `gdb` as it somehow decided to show me that line while executing the function's epilogue or something along those lines. Indeed, I later set a breakpoint on `barf` and never reached it. Closing, sorry for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 16:57:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 16:57:47 -0000 Subject: [GHC] #14752: Unboxed sums documentation looks wrong In-Reply-To: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> References: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> Message-ID: <060.7b9c5678941e0b8211169cdc369380e3@haskell.org> #14752: Unboxed sums documentation looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): osa1, everything is fine except the documentation I quoted. Perhaps it should refer to some `type Bool# = ...` instead of to `Bool`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 17:55:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 17:55:32 -0000 Subject: [GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances In-Reply-To: <050.313c7572181a73220f1b076de5274da4@haskell.org> References: <050.313c7572181a73220f1b076de5274da4@haskell.org> Message-ID: <065.b69f606fc8f42a4231963573339e2ef0@haskell.org> #13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: deriving 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:D4337, Wiki Page: | Phab:D4370 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D4337 => Phab:D4337, Phab:D4370 Comment: Phab:D4370 is another slight refactor that's working towards fixing this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 19:22:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 19:22:45 -0000 Subject: [GHC] #14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum# In-Reply-To: <050.ae9e72a72ce45f0a50476094399e0e2c@haskell.org> References: <050.ae9e72a72ce45f0a50476094399e0e2c@haskell.org> Message-ID: <065.8d9a2b1b8f7b46ecce963d3e6e7a9b37@haskell.org> #14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum# -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 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): Phab:D4371 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4371 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 22:37:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 22:37:44 -0000 Subject: [GHC] #14631: GHC 8.2.2 crashes when building the haskell-gi sample code In-Reply-To: <045.15a472a2467d8fc0989643d3fd91ef45@haskell.org> References: <045.15a472a2467d8fc0989643d3fd91ef45@haskell.org> Message-ID: <060.f87054e258f443d3b5631c9aeda26674@haskell.org> #14631: GHC 8.2.2 crashes when building the haskell-gi sample code -------------------------------------+------------------------------------- Reporter: muscar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): This is probably related: https://github.com/haskell-gi/haskell- gi/issues/113 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 2 23:30:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Feb 2018 23:30:29 -0000 Subject: [GHC] #14631: GHC 8.2.2 crashes when building the haskell-gi sample code In-Reply-To: <045.15a472a2467d8fc0989643d3fd91ef45@haskell.org> References: <045.15a472a2467d8fc0989643d3fd91ef45@haskell.org> Message-ID: <060.b67bb951172c36795a5c560378bc7c75@haskell.org> #14631: GHC 8.2.2 crashes when building the haskell-gi sample code -------------------------------------+------------------------------------- Reporter: muscar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: #13981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13981 Comment: Yep, this is a duplicate of #13981. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 03:00:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 03:00:07 -0000 Subject: [GHC] #11706: Increase precedence of lexps (if-then-else, case-of, do, lambda and let-in) In-Reply-To: <048.963578de7c77f87376af43ef595e0d3d@haskell.org> References: <048.963578de7c77f87376af43ef595e0d3d@haskell.org> Message-ID: <063.f6c3fea7a10407c5620cb6047dc3a9eb@haskell.org> #11706: Increase precedence of lexps (if-then-else, case-of, do, lambda and let-in) -------------------------------------+------------------------------------- Reporter: YoYoYonnY | Owner: (none) Type: feature request | Status: infoneeded Priority: lowest | Milestone: ⊥ Component: Compiler | Version: (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): I believe this has been implemented as the `BlockArguments` extension. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 05:02:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 05:02:33 -0000 Subject: [GHC] #14752: Unboxed sums documentation looks wrong In-Reply-To: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> References: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> Message-ID: <060.9c86de8a7266823e0ff9542662b66ae7@haskell.org> #14752: Unboxed sums documentation looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.2 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Ah, right. I have no objections to improving the documentation. Maybe we should say something like "Unboxed sums with no fields are represented as a single `Int32`". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 14:06:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 14:06:50 -0000 Subject: [GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. In-Reply-To: <044.8846313dfa837f257582237983583132@haskell.org> References: <044.8846313dfa837f257582237983583132@haskell.org> Message-ID: <059.75fef47506d1c70c7e8e9f279a70f638@haskell.org> #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. ---------------------------------+-------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 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): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by mgsloan): Not exactly a minimal example ;) But it looks like this is affecting people building recent stack development versions on windows - https://github.com/commercialhaskell/stack/issues/3797#issuecomment-361601073 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 15:32:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 15:32:39 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.4282ab82f6b0f14d94e17b33509cd262@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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 ocheron): Not sure if this is the best place and time but I see also 3 internal packages that need a version bump: {{{ ghc-compact integer-gmp integer-simple }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 15:56:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 15:56:35 -0000 Subject: [GHC] #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal In-Reply-To: <042.d21b92eb840644cd16549869583bccd0@haskell.org> References: <042.d21b92eb840644cd16549869583bccd0@haskell.org> Message-ID: <057.2f7571313572528c0bf75321817dfaff@haskell.org> #14270: GHC HEAD's ghc-stage1 panics on Data.Typeable.Internal -------------------------------------+------------------------------------- Reporter: hvr | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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: #14236 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: We should try to address this for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 15:57:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 15:57:32 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.c75d455486eec59496f6fdd37e8c991b@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3316 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Hopefully this will get done for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 15:58:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 15:58:16 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.ca0b07a1f9fe769931155e4e0f96970c@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Old description: > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || Needs revision || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || needs release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || ready || https://github.com/haskell/filepath/issues/65 > || > || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 > || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || needs revision || || > || `parsec` || needs release || > https://github.com/haskell/parsec/issues/86 || > || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || > || `primitive` || needs release || > https://github.com/haskell/primitive/issues/72 || > || `process` || ready || https://github.com/haskell/primitive/issues/72 > || > || `stm` || needs release || #14698 || > || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || > || `text` || needs release || https://github.com/haskell/text/issues/215 > || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || Needs revision || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || ready || https://github.com/haskell/filepath/issues/65 || || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || || `parallel` || needs revision || || || `parsec` || needs release || https://github.com/haskell/parsec/issues/86 || || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || || `primitive` || needs release || https://github.com/haskell/primitive/issues/72 || || `process` || ready || https://github.com/haskell/primitive/issues/72 || || `stm` || needs release || #14698 || || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || || `text` || needs release || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- Comment (by bgamari): Bumped `containers` to 0.5.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 16:39:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 16:39:00 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.fe2b17528540aa7932302520f5d29fd6@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Phab:D4009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 17:30:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 17:30:04 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.20e6d3a83891edc90f41ea0e14cb21ba@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Phab:D4009 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"217e4170bdce3df28a667803ce5e619553bfecdd/ghc" 217e417/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="217e4170bdce3df28a667803ce5e619553bfecdd" ghc-prim: Emulate C11 atomics when not available GCC's __sync primitives apparently "usually" imply a full barrier, meaning they can be used to emulate the more precise C11 atomics albeit with a loss of efficiency. This restores compatibility with GCC 4.4. This partially reverts commit 59de290928e6903337f31c1f8107ac8a98ea145d. Test Plan: Validate on Centos Reviewers: hvr, simonmar, trommler Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #14244 Differential Revision: https://phabricator.haskell.org/D4364 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 17:30:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 17:30:04 -0000 Subject: [GHC] #14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum# In-Reply-To: <050.ae9e72a72ce45f0a50476094399e0e2c@haskell.org> References: <050.ae9e72a72ce45f0a50476094399e0e2c@haskell.org> Message-ID: <065.3b15ba6da375b89b62494631504762d8@haskell.org> #14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum# -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 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): Phab:D4371 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d8a0e6d322deaa3743c95a11a6b7272577d1f86e/ghc" d8a0e6d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8a0e6d322deaa3743c95a11a6b7272577d1f86e" Don't apply dataToTag's caseRules for data families Commit 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 added a special caseRule for `dataToTag`, but this transformation completely broke when `dataToTag` was applied to somewith with a type headed by a data family, leading to #14680. For now at least, the simplest solution is to simply not apply this transformation when the type is headed by a data family. Test Plan: make test TEST=T14680 Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14680 Differential Revision: https://phabricator.haskell.org/D4371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 17:43:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 17:43:43 -0000 Subject: [GHC] #14754: -O1 changes result at runtime Message-ID: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found a program, which works as expected in GHC 8.4.1-alpha1 with `-O0`, but freezes with `-O1`. {{{ module Main where import Debug.Trace main :: IO () main = print (alg 3 1) alg :: Word -> Word -> Word alg a b | traceShow (a, b) False = undefined | c < b = alg b c | c > b = alg c b | otherwise = c where c = a - b }}} {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.0.20180118 $ ghc -O0 alg.hs [1 of 1] Compiling Main ( alg.hs, alg.o ) Linking alg ... $ ./alg (3,1) (2,1) 1 $ ghc -O1 alg.hs [1 of 1] Compiling Main ( alg.hs, alg.o ) [Optimisation flags changed] Linking alg ... $ ./alg 2>&1 | head (3,1) (1,2) (2,18446744073709551615) (18446744073709551615,3) ^C }}} For some reason an optimised program chooses a wrong case at the very first invocation of `alg`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 18:00:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 18:00:27 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.b2ad50bbbc889afc51584f768a2256f2@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Which operating system are you using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 18:05:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 18:05:57 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.28c97f9bb66cd009535dcd9dccfb44e6@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bodigrim): macOS High Sierra 10.13.3 I encountered the issue, because it affects build of `arithmoi` on Travis, so it should be reproducible on Ubuntu too. GHC 8.2.2 is fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 18:14:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 18:14:20 -0000 Subject: [GHC] #14324: Consider deprecating STM invariant mechanism In-Reply-To: <046.7d9457872c0d5f0243f1b38705442b7b@haskell.org> References: <046.7d9457872c0d5f0243f1b38705442b7b@haskell.org> Message-ID: <061.d821ba6726d36c0214843922af4e204e@haskell.org> #14324: Consider deprecating STM invariant mechanism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: 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 proposal has been [[https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0011-deprecate-stm- invariants.rst|accepted]]. I will add the appropriate deprecation pragmas in `base-4.11.0.0` noting that removal will happen in three releases (presumably GHC 8.10). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 18:16:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 18:16:19 -0000 Subject: [GHC] #14324: Consider deprecating STM invariant mechanism In-Reply-To: <046.7d9457872c0d5f0243f1b38705442b7b@haskell.org> References: <046.7d9457872c0d5f0243f1b38705442b7b@haskell.org> Message-ID: <061.9f55a674ade89eb59b45934e95742209@haskell.org> #14324: Consider deprecating STM invariant mechanism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 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:D4372 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4372 Comment: Deprecation performed in Phab:D4372. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 18:26:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 18:26:31 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.4bbf739c7ae279e91bd9a39d4f56e983@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest * milestone: => 8.4.1 Old description: > I found a program, which works as expected in GHC 8.4.1-alpha1 with > `-O0`, but freezes with `-O1`. > > {{{ > module Main where > > import Debug.Trace > > main :: IO () > main = print (alg 3 1) > > alg :: Word -> Word -> Word > alg a b > | traceShow (a, b) False = undefined > | c < b = alg b c > | c > b = alg c b > | otherwise = c > where > c = a - b > }}} > > {{{ > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 8.4.0.20180118 > $ ghc -O0 alg.hs > [1 of 1] Compiling Main ( alg.hs, alg.o ) > Linking alg ... > $ ./alg > (3,1) > (2,1) > 1 > $ ghc -O1 alg.hs > [1 of 1] Compiling Main ( alg.hs, alg.o ) [Optimisation flags > changed] > Linking alg ... > $ ./alg 2>&1 | head > (3,1) > (1,2) > (2,18446744073709551615) > (18446744073709551615,3) > ^C > }}} > > For some reason an optimised program chooses a wrong case at the very > first invocation of `alg`. New description: I found a program, which works as expected in GHC 8.4.1-alpha1 with `-O0`, but freezes with `-O1`. {{{#!hs module Main where import Debug.Trace main :: IO () main = print (alg 3 1) alg :: Word -> Word -> Word alg a b | traceShow (a, b) False = undefined | c < b = alg b c | c > b = alg c b | otherwise = c where c = a - b }}} {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.0.20180118 $ ghc -O0 alg.hs [1 of 1] Compiling Main ( alg.hs, alg.o ) Linking alg ... $ ./alg (3,1) (2,1) 1 $ ghc -O1 alg.hs [1 of 1] Compiling Main ( alg.hs, alg.o ) [Optimisation flags changed] Linking alg ... $ ./alg 2>&1 | head (3,1) (1,2) (2,18446744073709551615) (18446744073709551615,3) ^C }}} For some reason an optimised program chooses a wrong case at the very first invocation of `alg`. -- Comment: Yikes! Thank you for catching this. I guess this means my plans for another alpha release today are on hold. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 18:39:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 18:39:44 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.2ef9dfb4743991e9e9cc1ffc1ebed676@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): In mate with `-flate-dmd-anal` we get lots of new worker functions and the final program is quite different than the one without `-flate-dmd-anal`. I couldn't find yet what's causing the extra allocations as the changes are so big. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 19:59:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 19:59:09 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.095849288db3ef1cb6b9891870c57bf6@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This was caused by commit 7920a7d9c53083b234e060a3e72f00b601a46808 (`cmm/CBE: Collapse blocks equivalent up to alpha renaming of local registers`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 21:24:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 21:24:10 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.36d28d951440bcbdb89e4909a4389b88@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Old description: > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || Needs revision || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || on-release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || ready || https://github.com/haskell/filepath/issues/65 > || > || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 > || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || needs revision || || > || `parsec` || needs release || > https://github.com/haskell/parsec/issues/86 || > || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || > || `primitive` || needs release || > https://github.com/haskell/primitive/issues/72 || > || `process` || ready || https://github.com/haskell/primitive/issues/72 > || > || `stm` || needs release || #14698 || > || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || > || `text` || needs release || https://github.com/haskell/text/issues/215 > || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || Needs revision || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || ready || https://github.com/haskell/filepath/issues/65 || || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || || `parallel` || needs revision || || || `parsec` || needs release || https://github.com/haskell/parsec/issues/86 || || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || || `primitive` || needs release || https://github.com/haskell/primitive/issues/72 || || `process` || ready || https://github.com/haskell/primitive/issues/72 || || `stm` || ready || #14698 || || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || || `text` || needs release || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- Comment (by bgamari): Bumped `stm` to 2.4.5.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 3 21:33:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Feb 2018 21:33:22 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.ce65ce09b8ddac8f668e6f8473d91486@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Old description: > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || Needs revision || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || on-release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || ready || https://github.com/haskell/filepath/issues/65 > || > || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 > || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || needs revision || || > || `parsec` || needs release || > https://github.com/haskell/parsec/issues/86 || > || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || > || `primitive` || needs release || > https://github.com/haskell/primitive/issues/72 || > || `process` || ready || https://github.com/haskell/primitive/issues/72 > || > || `stm` || ready || #14698 || > || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || > || `text` || needs release || https://github.com/haskell/text/issues/215 > || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || Needs revision || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || ready || https://github.com/haskell/filepath/issues/65 || || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || || `parallel` || needs revision || || || `parsec` || needs release || https://github.com/haskell/parsec/issues/86 || || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || || `primitive` || needs release || https://github.com/haskell/primitive/issues/72 || || `process` || ready || https://github.com/haskell/primitive/issues/72 || || `stm` || ready || #14698 || || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || || `text` || ready || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- Comment (by bgamari): `text` 1.2.3.0 should work fine for our purposes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 00:35:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 00:35:36 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.36e18a2f92cd53555aa9980327d749a0@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed the problem here is that the CBE logic in the above patch find these two blocks to be equivalent: {{{ c4N2: // global _s4Kg::I64 = _s4Kg::I64; _s4Kf::I64 = _s4Kr::I64; goto c4M3; c4N5: // global _s4Kf::I64 = _s4Kg::I64; _s4Kg::I64 = _s4Kr::I64; goto c4M3; }}} The reason is that the implementation walks the two blocks, zipping together their nodes and building a correspondence between their local registers. In the first node we have {{{ c4N2 c4N5 ---------------- --------------- s4Kg = s4Kg s4Kf = s4Kg }}} As the RHSs of the assignments are identical, this results in the correspondence `s4Kg(c4N2) ~> s4Kf(s4N5)`. We then consider the second pair of nodes: {{{ c4N2 c4N5 ---------------- --------------- s4Kf = s4Kr s4Kg = s4Kr }}} Since the implementation binding occurrences are simply added to the register substitution instead of compared, these two nodes are considered to be equivalent. This is clearly wrong. I'll need to revisit this in the future but in the meantime I'm going to revert. implementation fails to take into account that logic registers may live beyond the -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 00:57:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 00:57:58 -0000 Subject: [GHC] #14755: Allow putting SCC annotations on class instance methods Message-ID: <046.d125d287c64125241e7d10095a8d200f@haskell.org> #14755: Allow putting SCC annotations on class instance methods -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Profiling | 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: -------------------------------------+------------------------------------- Perhaps there's a way to do this that I don't know about. Here's a file: {{{ module Test where class C a where foo :: a -> String instance C Int where -- this would be a parse error: {-# SCC foo #-} foo a = show a }}} I want to put a cost center on `foo`. Like mentioned in the comment, doing that in the obvious way is a parse error. Interestingly `-fprof-auto-top` puts a cost center on `foo`. This came up when debugging #14637. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 01:11:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 01:11:45 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.8b9a590ff672633eed413d697229b1cd@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Keywords: newcomer, Resolution: | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #14754 | Differential Rev(s): Phab:D3973, Wiki Page: | Phab:D3999 -------------------------------------+------------------------------------- Changes (by bgamari): * related: #9157 => #9157, #14754 Comment: Sadly I'll need to revert the above patches due to #14754. I'll have another look at this post-8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 01:35:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 01:35:55 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.21448feb70c81aaf3b5bb62055df96d4@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Keywords: newcomer, Resolution: | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #14754 | Differential Rev(s): Phab:D3973, Wiki Page: | Phab:D3999 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"50adbd7c5fe5894d3e6e2a58b353ed07e5f8949d/ghc" 50adbd7c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="50adbd7c5fe5894d3e6e2a58b353ed07e5f8949d" cmm: Revert more aggressive CBE due to #14226 Trac #14226 noted that the C-- CBE pass frequently fails to common up semantically identical blocks due to the differences in local register naming. These patches fixed this by making the pass consider equality up to alpha-renaming. However, the new logic failed to consider the possibility that local register naming *may* matter across multiple blocks. This lead to the regression #14754. I'll need to do a bit of thinking on a proper solution to this but in the meantime I'm reverting all four patches. This reverts commit a27056f9823f8bbe2302f1924b3ab38fd6752e37. This reverts commit 6f990c54f922beae80362fe62426beededc21290. This reverts commit 9aa73892e10e90a1799b9277da593e816a827364. This reverts commit 7920a7d9c53083b234e060a3e72f00b601a46808. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 01:35:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 01:35:55 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.239532a8168037ebcf188079557f45ff@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"606edbfba14b025ce85a02e5ed7c03e8a097d692/ghc" 606edbfb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="606edbfba14b025ce85a02e5ed7c03e8a097d692" testsuite: Add testcase for #14754 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 01:35:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 01:35:55 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.bfdd40e6ef39d10f8f4bd2ccd35ba63b@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"50adbd7c5fe5894d3e6e2a58b353ed07e5f8949d/ghc" 50adbd7c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="50adbd7c5fe5894d3e6e2a58b353ed07e5f8949d" cmm: Revert more aggressive CBE due to #14226 Trac #14226 noted that the C-- CBE pass frequently fails to common up semantically identical blocks due to the differences in local register naming. These patches fixed this by making the pass consider equality up to alpha-renaming. However, the new logic failed to consider the possibility that local register naming *may* matter across multiple blocks. This lead to the regression #14754. I'll need to do a bit of thinking on a proper solution to this but in the meantime I'm reverting all four patches. This reverts commit a27056f9823f8bbe2302f1924b3ab38fd6752e37. This reverts commit 6f990c54f922beae80362fe62426beededc21290. This reverts commit 9aa73892e10e90a1799b9277da593e816a827364. This reverts commit 7920a7d9c53083b234e060a3e72f00b601a46808. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 01:39:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 01:39:32 -0000 Subject: [GHC] #14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum# In-Reply-To: <050.ae9e72a72ce45f0a50476094399e0e2c@haskell.org> References: <050.ae9e72a72ce45f0a50476094399e0e2c@haskell.org> Message-ID: <065.d014efcb7e12d4306c49d440bdf2fcbd@haskell.org> #14680: GHC 8.4.1-alpha panics when optimizing function using getTag and tagToEnum# -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: fixed | 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): Phab:D4371 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.4` as b7f9139ccddf4a1ca5839cd50ad8dba4f5e2e1dc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 02:11:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 02:11:55 -0000 Subject: [GHC] #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers In-Reply-To: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> References: <047.186581f2b50df1c18e1d806a1ae31c18@haskell.org> Message-ID: <062.c5c40db0beea6b69381688e6ecc33e28@haskell.org> #14244: ghc-prim: hs_atomicread* and hs_atomicwrite* missing barriers -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Prelude | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #12537 | Differential Rev(s): Phab:D4009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.4` as 7a3a7ee938b05a297e4b624cae86e4f0caefb88a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 02:13:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 02:13:11 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.bf631dbe48e2dd977d9a357399a3add6@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14226 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * related: => #14226 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 02:13:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 02:13:25 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.dfdf9ed645babd1ea99cdac5a4a395e0@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14226 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.4`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 02:42:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 02:42:26 -0000 Subject: [GHC] #14717: Hidden package hints no longer display In-Reply-To: <047.c46b47b6ebca0c950882fdcc6a0147c6@haskell.org> References: <047.c46b47b6ebca0c950882fdcc6a0147c6@haskell.org> Message-ID: <062.0f6340f5f6f90d3ceec7b8f23d827119@haskell.org> #14717: Hidden package hints no longer display -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I'd like to say that I didn't intentionally break this, but in 00b530d5402aaa37e4085ecdcae0ae54454736c1 I did update the expect files to remove the message. I'll look into fixing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 12:00:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 12:00:24 -0000 Subject: [GHC] #14755: Allow putting SCC annotations on class instance methods In-Reply-To: <046.d125d287c64125241e7d10095a8d200f@haskell.org> References: <046.d125d287c64125241e7d10095a8d200f@haskell.org> Message-ID: <061.51ed82e6a431fc7111cfc1953d9cdec6@haskell.org> #14755: Allow putting SCC annotations on class instance methods -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Do you not get the same effect with `-fprof-auto-top` if you do `foo a = {-# SCC foo #-} show a`? I'm also a bit surprised that `-fprof-auto-top` adds a SCC to this `foo`. Apparently typeclass methods are considered as top level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 12:01:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 12:01:57 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.e20e85e773da8562631325392c76315f@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14226 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bodigrim): Is this test case run with `-O1` option? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 12:11:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 12:11:37 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.eb016209b3ad1219e9d0ea5b1d0666f8@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Keywords: newcomer, Resolution: | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #14754 | Differential Rev(s): Phab:D3973, Wiki Page: | Phab:D3999 -------------------------------------+------------------------------------- Comment (by michalt): :( I can currently think of two options: 1) Fix the approach using alpha renaming by actually checking liveness on entry and exit for each variable. (to only consider variables that are not live across blocks) The disadvantage is that this would be quite a bit more costly. 2) Don't improve CBE itself, but run it a second time after the sinking pass - this might get rid of some of the cases from this ticket (e.g., the one from comment:6) The advantage is that this would also fix #12915; the disadvantage: this might not be always as effective as option 1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 12:14:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 12:14:50 -0000 Subject: [GHC] #14755: Allow putting SCC annotations on class instance methods In-Reply-To: <046.d125d287c64125241e7d10095a8d200f@haskell.org> References: <046.d125d287c64125241e7d10095a8d200f@haskell.org> Message-ID: <061.fcb399b10524acd9d9d545358d49b8ec@haskell.org> #14755: Allow putting SCC annotations on class instance methods -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): > Do you not get the same effect with -fprof-auto-top if you do foo a = {-# SCC foo #-} show a? Yes, that works, but if `foo` does pattern matching on the parameters, you need to put multiple `SCCs` or refactor the code. You can also make `fooHelper` that's a top level function and just `foo = fooHelper`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 13:48:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 13:48:24 -0000 Subject: [GHC] #14756: `ghc -M` doesn't emit dependencies for header files included either via CPP or CApiFFI Message-ID: <042.955d099f400e18419c06a23bac98133d@haskell.org> #14756: `ghc -M` doesn't emit dependencies for header files included either via CPP or CApiFFI -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: capi capiffi | Operating System: Unknown/Multiple cpp | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the following simple module {{{#!hs {-# LANGUAGE CApiFFI #-} #include "Bar.hs.inc" module Foo where foreign import capi unsafe "cbits.h foo" c_foo :: Int -> IO () }}} The dependency information produced by `ghc -dep-suffix '' -M Foo.hs` is {{{ # DO NOT DELETE: Beginning of Haskell dependencies Foo.o : Foo.hs # DO NOT DELETE: End of Haskell dependencies }}} And neither mention the include header dependency `cbits.h` nor `Bar.hs.inc`. See also https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_compilation.html #makefile-dependencies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 13:48:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 13:48:54 -0000 Subject: [GHC] #14756: `ghc -M` doesn't emit dependencies for header files included either via CPP or CApiFFI In-Reply-To: <042.955d099f400e18419c06a23bac98133d@haskell.org> References: <042.955d099f400e18419c06a23bac98133d@haskell.org> Message-ID: <057.096fb326845f523365f856be7f980d85@haskell.org> #14756: `ghc -M` doesn't emit dependencies for header files included either via CPP or CApiFFI -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: capi capiffi | cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > Given the following simple module > > {{{#!hs > {-# LANGUAGE CApiFFI #-} > > #include "Bar.hs.inc" > > module Foo where > > foreign import capi unsafe "cbits.h foo" c_foo :: Int -> IO () > }}} > > The dependency information produced by `ghc -dep-suffix '' -M Foo.hs` is > > {{{ > # DO NOT DELETE: Beginning of Haskell dependencies > Foo.o : Foo.hs > # DO NOT DELETE: End of Haskell dependencies > }}} > > And neither mention the include header dependency `cbits.h` nor > `Bar.hs.inc`. > > > See also > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_compilation.html > #makefile-dependencies New description: Given the following simple module {{{#!hs {-# LANGUAGE CPP, CApiFFI #-} #include "Bar.hs.inc" module Foo where foreign import capi unsafe "cbits.h foo" c_foo :: Int -> IO () }}} The dependency information produced by `ghc -dep-suffix '' -M Foo.hs` is {{{ # DO NOT DELETE: Beginning of Haskell dependencies Foo.o : Foo.hs # DO NOT DELETE: End of Haskell dependencies }}} And neither mention the include header dependency `cbits.h` nor `Bar.hs.inc`. See also https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_compilation.html #makefile-dependencies -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 14:00:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 14:00:40 -0000 Subject: [GHC] #14757: ghc recompilation check doesn't take into account headers directly included by CApiFFI Message-ID: <042.f745e215ea00b86e81353a178b3e8f6b@haskell.org> #14757: ghc recompilation check doesn't take into account headers directly included by CApiFFI -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: capi capiffi | Operating System: Unknown/Multiple cpp | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Continuing from #14756, given the following simple module {{{#!hs {-# LANGUAGE CPP, CApiFFI #-} #include "Bar.hs.inc" module Foo where foreign import capi unsafe "cbits.h foo" c_foo :: Int -> IO () }}} After having compiled `ghc -c Foo.hs` successfully, and second invocation of `ghc -c Foo.hs` - ...will properly recompile when `Bar.hs.inc` changes (or any of its recursive `#include`s!) (good!) - ...will fail to detect when `cbits.h` changes, and thus claim `compilation IS NOT required` (BAD!) Ideally, we should always run CPP for the CApiFFI-included, in order to detect when any recursive `#include`s inside `cbits.h` change, and use a recorded checksum to detect whether recompilation of the C wrapper (and thus re-linking of the haskell module; which currently forces resynthesizing the object files) is necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 14:03:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 14:03:03 -0000 Subject: [GHC] #14756: `ghc -M` doesn't emit dependencies for header files included either via CPP or CApiFFI In-Reply-To: <042.955d099f400e18419c06a23bac98133d@haskell.org> References: <042.955d099f400e18419c06a23bac98133d@haskell.org> Message-ID: <057.a0c24b7d7aab30376994d3eb93e2cd3a@haskell.org> #14756: `ghc -M` doesn't emit dependencies for header files included either via CPP or CApiFFI -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: capi capiffi | cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14757 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * related: => #14757 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 14:50:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 14:50:32 -0000 Subject: [GHC] #14755: Allow putting SCC annotations on class instance methods In-Reply-To: <046.d125d287c64125241e7d10095a8d200f@haskell.org> References: <046.d125d287c64125241e7d10095a8d200f@haskell.org> Message-ID: <061.23c9eb7d72c4afd993f3671c6cdfa522@haskell.org> #14755: Allow putting SCC annotations on class instance methods -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Right.. I made some progress on supporting `SCC`s in more places some time ago: https://github.com/ghc/ghc/commit/98b2c508 it shouldn't be too hard to make it possible to use in this context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 15:44:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 15:44:52 -0000 Subject: [GHC] #14396: Hs-boot woes during family instance consistency checks In-Reply-To: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> References: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> Message-ID: <061.9b2ebd971db3a05406d4dff76202d602@haskell.org> #14396: Hs-boot woes during family instance consistency checks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4154 Wiki Page: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Anyone backported this patch to ghc-8.0.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 16:39:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 16:39:21 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.ac49089fe749a646d5b84f3bc39c4a79@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Keywords: newcomer, Resolution: | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #14754 | Differential Rev(s): Phab:D3973, Wiki Page: | Phab:D3999 -------------------------------------+------------------------------------- Comment (by bgamari): > 1) Fix the approach using alpha renaming by actually checking liveness on entry and exit for each variable. (to only consider variables that are not live across blocks) The disadvantage is that this would be quite a bit more costly. Right, I briefly considered implementing this. I don't expect it will be absurdly expensive: all we need to know is which variables are mentioned in only one block. However, I do wonder how much this will actually improve code. Presumably there are cases where this will be *too* conservative. > 2) Don't improve CBE itself, but run it a second time after the sinking pass - this might get rid of some of the cases from this ticket (e.g., the one from comment:6) The advantage is that this would also fix #12915; the disadvantage: this might not be always as effective as option 1). Mmm, interesting idea. This would certainly be worth a try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 16:43:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 16:43:15 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.19ce2487a0e033f7c965fa60bfd1f8cf@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Phyx- Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: cabal01 Blocked By: | Blocking: 6107 Related Tickets: #7134 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Bumping to 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 16:44:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 16:44:13 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.d2a1da38e2483e06671ed5cd2bfa3efe@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3619 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Bumping to 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 18:58:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 18:58:35 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.31a1158d05e7243ebb1cbff329433496@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Keywords: newcomer, Resolution: | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #14754 | Differential Rev(s): Phab:D3973, Wiki Page: | Phab:D3999 -------------------------------------+------------------------------------- Comment (by michalt): Replying to [comment:29 bgamari]: > > 1) Fix the approach using alpha renaming by actually checking liveness on entry and exit for each variable. (to only consider variables that are not live across blocks) The disadvantage is that this would be quite a bit more costly. > > Right, I briefly considered implementing this. I don't expect it will be absurdly expensive: all we need to know is which variables are mentioned in only one block. However, I do wonder how much this will actually improve code. Presumably there are cases where this will be *too* conservative. > > > 2) Don't improve CBE itself, but run it a second time after the sinking pass - this might get rid of some of the cases from this ticket (e.g., the one from comment:6) The advantage is that this would also fix #12915; the disadvantage: this might not be always as effective as option 1). > > Mmm, interesting idea. This would certainly be worth a try. I did a small experiment with this: https://ghc.haskell.org/trac/ghc/ticket/12915#comment:5 (I'm wondering if we could improve the CBE to be a bit cheaper, e.g., by improving hashing) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 19:55:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 19:55:02 -0000 Subject: [GHC] #14282: tagToEnum# . dataToTag# not optimized away In-Reply-To: <045.5438ce0b3dc299cc3f08e924d6abe37c@haskell.org> References: <045.5438ce0b3dc299cc3f08e924d6abe37c@haskell.org> Message-ID: <060.85c52d8a7745d287a69253a951a91a3f@haskell.org> #14282: tagToEnum# . dataToTag# not optimized away -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4375 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4375 Comment: I've put up a differential adding the necessary explanation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 19:56:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 19:56:47 -0000 Subject: [GHC] #14706: T11489 fails if run as root In-Reply-To: <046.a14b90f533f833e4ef6e5c85c8add140@haskell.org> References: <046.a14b90f533f833e4ef6e5c85c8add140@haskell.org> Message-ID: <061.6e0c33549b58e5432eab5b2728a2aff5@haskell.org> #14706: T11489 fails if run as root -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.5 Integration | 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:D4360 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: dfeuer => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 20:26:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 20:26:46 -0000 Subject: [GHC] #14722: Error message points to wrong location In-Reply-To: <051.c333e5a6f35eca7f4991a44f21fca447@haskell.org> References: <051.c333e5a6f35eca7f4991a44f21fca447@haskell.org> Message-ID: <066.9f6a1ddac32909d396dc5e5e029ce4d6@haskell.org> #14722: Error message points to wrong location -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | TypeApplications 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): Yes, I think that's the right approach, in order to get this error to interact better with others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 21:20:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 21:20:56 -0000 Subject: [GHC] #14717: Hidden package hints no longer display In-Reply-To: <047.c46b47b6ebca0c950882fdcc6a0147c6@haskell.org> References: <047.c46b47b6ebca0c950882fdcc6a0147c6@haskell.org> Message-ID: <062.ca6628e6fee411eeda4e1ad39c74e0d9@haskell.org> #14717: Hidden package hints no longer display -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): I know what the problem is. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 21:33:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 21:33:38 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.bcfdf63b84a90e695a8fd1b021fea718@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: 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 don't see any madness in this direction, given that instance lookup fails eagerly if there is ambiguity. For example: {{{#!hs class Eq a => Wurble a class D a class E a f :: ((forall a. D a => Ord a), (forall a. E a => Wurble a)) => a -> Bool f x = x == x }}} Under the ambiguity rule above, this would fail. Really, it's the same problem we have with {{{#!hs g :: ((forall a. D a => Eq a), (forall a. E a => Eq a)) => a -> Bool g x = x == x }}} Both examples should have the same behavior (failing). This second one feels easier because it looks abjectly sillier, but it's not unreasonable to imagine a user writing something like that, hoping that GHC will non- deterministically pick the right thing to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 23:04:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 23:04:35 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack Message-ID: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not entirely sure what conditions trigger this, but I am observing a reliable segmentation fault with a program with large heap compiled with 8.4.1-alpha3 and run with retainer profiling enabled. Judging by the fact that the crashing instruction is a `mov _, ($rsp)`, I'm reasonable certain that the issue is a C stack overflow. The top of the stack looks like, {{{ #0 0x000000000249212c in retainClosure (c0=0x42af3459b8, cp0=cp0 at entry=0x42af347000, r0=r0 at entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1488 #1 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af347000, bitmap=, size=, p=0x42af347260) at rts/RetainerProfile.c:1209 #2 retainStack (c=c at entry=0x42af347000, c_child_r=c_child_r at entry=0x42bc4fd1a0, stackStart=, stackEnd=0x42af347370) at rts/RetainerProfile.c:1350 #3 0x0000000002492870 in retainClosure (c0=, cp0=cp0 at entry=0x42af345b28, r0=r0 at entry=0x2a5ac20 ) at rts/RetainerProfile.c:1686 #4 0x0000000002492887 in retainClosure (c0=, cp0=cp0 at entry=0x42af3473e0, r0=r0 at entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #5 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3473e0, bitmap=, size=, p=0x42af347690) at rts/RetainerProfile.c:1209 #6 retainStack (c=c at entry=0x42af3473e0, c_child_r=c_child_r at entry=0x42bc4fd1a0, stackStart=, stackEnd=0x42af347750) at rts/RetainerProfile.c:1350 #7 0x0000000002492870 in retainClosure (c0=, cp0=cp0 at entry=0x42af345d88, r0=r0 at entry=0x2a5ac20 ) at rts/RetainerProfile.c:1686 #8 0x0000000002492887 in retainClosure (c0=, cp0=cp0 at entry=0x42af3477c0, r0=r0 at entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #9 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3477c0, bitmap=, size=, p=0x42af347a70) at rts/RetainerProfile.c:1209 #10 retainStack (c=c at entry=0x42af3477c0, c_child_r=c_child_r at entry=0x42bc4fd1a0, stackStart=, stackEnd=0x42af347b30) at rts/RetainerProfile.c:1350 #11 0x0000000002492870 in retainClosure (c0=, cp0=cp0 at entry=0x42af3481a8, r0=r0 at entry=0x2a5ac20 ) at rts/RetainerProfile.c:1686 #12 0x0000000002492887 in retainClosure (c0=, cp0=cp0 at entry=0x42af347ba0, r0=r0 at entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #13 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af347ba0, bitmap=, size=, p=0x42af347e50) at rts/RetainerProfile.c:1209 #14 retainStack (c=c at entry=0x42af347ba0, c_child_r=c_child_r at entry=0x42bc4fd1a0, stackStart=, stackEnd=0x42af347f10) at rts/RetainerProfile.c:1350 #15 0x0000000002492870 in retainClosure (c0=, cp0=cp0 at entry=0x42af348408, r0=r0 at entry=0x2a5ac20 ) at rts/RetainerProfile.c:1686 #16 0x0000000002492887 in retainClosure (c0=, cp0=cp0 at entry=0x42af349000, r0=r0 at entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #17 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af349000, bitmap=, size=, p=0x42af3492b0) at rts/RetainerProfile.c:1209 #18 retainStack (c=c at entry=0x42af349000, c_child_r=c_child_r at entry=0x42bc4fd1a0, stackStart=, stackEnd=0x42af349370) at rts/RetainerProfile.c:1350 #19 0x0000000002492870 in retainClosure (c0=, cp0=cp0 at entry=0x42af348668, r0=r0 at entry=0x2a5ac20 ) at rts/RetainerProfile.c:1686 #20 0x0000000002492887 in retainClosure (c0=, cp0=cp0 at entry=0x42af3493e0, r0=r0 at entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #21 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3493e0, bitmap=, size=, p=0x42af349690) at rts/RetainerProfile.c:1209 #22 retainStack (c=c at entry=0x42af3493e0, c_child_r=c_child_r at entry=0x42bc4fd1a0, stackStart=, stackEnd=0x42af349750) at rts/RetainerProfile.c:1350 #23 0x0000000002492870 in retainClosure (c0=, cp0=cp0 at entry=0x42af3488c8, r0=r0 at entry=0x2a5ac20 ) at rts/RetainerProfile.c:1686 #24 0x0000000002492887 in retainClosure (c0=, cp0=cp0 at entry=0x42af3497c0, r0=r0 at entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 #25 0x00000000024932b0 in retain_small_bitmap (c_child_r=0x42bc4fd1a0, c=0x42af3497c0, bitmap=, size=, p=0x42af349a70) at rts/RetainerProfile.c:1209 #26 retainStack (c=c at entry=0x42af3497c0, c_child_r=c_child_r at entry=0x42bc4fd1a0, stackStart=, stackEnd=0x42af349b30) at rts/RetainerProfile.c:1350 #27 0x0000000002492870 in retainClosure (c0=, cp0=cp0 at entry=0x42af348b28, r0=r0 at entry=0x2a5ac20 ) at rts/RetainerProfile.c:1686 #28 0x0000000002492887 in retainClosure (c0=, cp0=cp0 at entry=0x42af349ba0, r0=r0 at entry=0x42bc4fd1a0) at rts/RetainerProfile.c:1695 ... }}} and this goes on for at least 30000 frames. It looks very much like this is a bug in the retainer profiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 23:46:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 23:46:04 -0000 Subject: [GHC] #14717: Hidden package hints no longer display In-Reply-To: <047.c46b47b6ebca0c950882fdcc6a0147c6@haskell.org> References: <047.c46b47b6ebca0c950882fdcc6a0147c6@haskell.org> Message-ID: <062.735564475fdbf6e360e98bfd804cf68d@haskell.org> #14717: Hidden package hints no longer display -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4376 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D4376 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 4 23:52:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Feb 2018 23:52:58 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.b10b6d2941b991a924dffa24e38d7309@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Passing {{{-fno-it}}} causes {{{()}}} to be printed to stdout vastly more often. Did this also break that bit? Looking at the section on GHCi Plans I note that the no-it branch is missing the {{{it::()}}} check in step A. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 00:30:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 00:30:39 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail Message-ID: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example log: ``` +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Haddock, + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, + Distribution.Simple.Program.Types, Distribution.Simple.Setup, + Distribution.System, Distribution.Types.AbiDependency, + Distribution.Types.AbiHash, Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] + [] +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [Control.Applicative, Data.Functor.Const, Data.Functor.Identity, + Data.Monoid, Data.Semigroup.Internal, GHC.Generics, + GHC.IO.Exception] + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Haddock, + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, + Distribution.Simple.Program.Types, Distribution.Simple.Setup, + Distribution.System, Distribution.Types.AbiDependency, + Distribution.Types.AbiHash, Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [] + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Haddock, + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, + Distribution.Simple.Program.Types, Distribution.Simple.Setup, + Distribution.System, Distribution.Types.AbiDependency, + Distribution.Types.AbiHash, Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Haddock, + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, + Distribution.Simple.Program.Types, Distribution.Simple.Setup, + Distribution.System, Distribution.Types.AbiDependency, + Distribution.Types.AbiHash, Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] + [] *** unexpected failure for cabal09(normal) ``` This is probably orph calculation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 00:31:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 00:31:00 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.49912464877d052096826a2220c305a9@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Example log: > > ``` > +WARNING: file compiler/utils/ListSetOps.hs, line 58 > + [Distribution.Backpack, Distribution.Backpack.FullUnitId, > + Distribution.Backpack.ModuleShape, > + Distribution.Backpack.PreModuleShape, > + Distribution.Backpack.ReadyComponent, > + Distribution.CabalSpecVersion, Distribution.Compat.Graph, > + Distribution.Compat.Semigroup, Distribution.Compiler, > + Distribution.License, Distribution.ModuleName, > + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, > + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, > + Distribution.SPDX.LicenseReference, > + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, > + Distribution.Simple.Doctest, Distribution.Simple.Haddock, > + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, > + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, > + Distribution.Simple.Program.Types, Distribution.Simple.Setup, > + Distribution.System, Distribution.Types.AbiDependency, > + Distribution.Types.AbiHash, Distribution.Types.Benchmark, > + Distribution.Types.BenchmarkInterface, > + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, > + Distribution.Types.BuildType, Distribution.Types.ComponentId, > + Distribution.Types.ComponentLocalBuildInfo, > + Distribution.Types.ComponentName, > + Distribution.Types.ComponentRequestedSpec, > + Distribution.Types.CondTree, Distribution.Types.Condition, > + Distribution.Types.Dependency, Distribution.Types.ExeDependency, > + Distribution.Types.Executable, Distribution.Types.ExecutableScope, > + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, > + Distribution.Types.ForeignLibOption, > + Distribution.Types.ForeignLibType, > + Distribution.Types.GenericPackageDescription, > + Distribution.Types.IncludeRenaming, > + Distribution.Types.InstalledPackageInfo, > + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, > + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, > + Distribution.Types.Module, Distribution.Types.ModuleReexport, > + Distribution.Types.ModuleRenaming, > + Distribution.Types.MungedPackageId, > + Distribution.Types.MungedPackageName, > + Distribution.Types.PackageDescription, > + Distribution.Types.PackageId, Distribution.Types.PackageName, > + Distribution.Types.PkgconfigDependency, > + Distribution.Types.PkgconfigName, > + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, > + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, > + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, > + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, > + Distribution.Types.Version, Distribution.Types.VersionRange, > + Distribution.Utils.ShortText, Distribution.Verbosity, > + Language.Haskell.Extension, Control.Applicative, Data.Complex, > + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, > + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, > + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, > + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, > + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, > + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, > + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, > + Data.Text, Data.Text.Lazy] > + [] > +WARNING: file compiler/utils/ListSetOps.hs, line 58 > + [Control.Applicative, Data.Functor.Const, Data.Functor.Identity, > + Data.Monoid, Data.Semigroup.Internal, GHC.Generics, > + GHC.IO.Exception] > + [Distribution.Backpack, Distribution.Backpack.FullUnitId, > + Distribution.Backpack.ModuleShape, > + Distribution.Backpack.PreModuleShape, > + Distribution.Backpack.ReadyComponent, > + Distribution.CabalSpecVersion, Distribution.Compat.Graph, > + Distribution.Compat.Semigroup, Distribution.Compiler, > + Distribution.License, Distribution.ModuleName, > + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, > + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, > + Distribution.SPDX.LicenseReference, > + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, > + Distribution.Simple.Doctest, Distribution.Simple.Haddock, > + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, > + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, > + Distribution.Simple.Program.Types, Distribution.Simple.Setup, > + Distribution.System, Distribution.Types.AbiDependency, > + Distribution.Types.AbiHash, Distribution.Types.Benchmark, > + Distribution.Types.BenchmarkInterface, > + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, > + Distribution.Types.BuildType, Distribution.Types.ComponentId, > + Distribution.Types.ComponentLocalBuildInfo, > + Distribution.Types.ComponentName, > + Distribution.Types.ComponentRequestedSpec, > + Distribution.Types.CondTree, Distribution.Types.Condition, > + Distribution.Types.Dependency, Distribution.Types.ExeDependency, > + Distribution.Types.Executable, Distribution.Types.ExecutableScope, > + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, > + Distribution.Types.ForeignLibOption, > + Distribution.Types.ForeignLibType, > + Distribution.Types.GenericPackageDescription, > + Distribution.Types.IncludeRenaming, > + Distribution.Types.InstalledPackageInfo, > + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, > + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, > + Distribution.Types.Module, Distribution.Types.ModuleReexport, > + Distribution.Types.ModuleRenaming, > + Distribution.Types.MungedPackageId, > + Distribution.Types.MungedPackageName, > + Distribution.Types.PackageDescription, > + Distribution.Types.PackageId, Distribution.Types.PackageName, > + Distribution.Types.PkgconfigDependency, > + Distribution.Types.PkgconfigName, > + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, > + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, > + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, > + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, > + Distribution.Types.Version, Distribution.Types.VersionRange, > + Distribution.Utils.ShortText, Distribution.Verbosity, > + Language.Haskell.Extension, Control.Applicative, Data.Complex, > + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, > + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, > + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, > + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, > + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, > + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, > + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, > + Data.Text, Data.Text.Lazy] > +WARNING: file compiler/utils/ListSetOps.hs, line 58 > + [] > + [Distribution.Backpack, Distribution.Backpack.FullUnitId, > + Distribution.Backpack.ModuleShape, > + Distribution.Backpack.PreModuleShape, > + Distribution.Backpack.ReadyComponent, > + Distribution.CabalSpecVersion, Distribution.Compat.Graph, > + Distribution.Compat.Semigroup, Distribution.Compiler, > + Distribution.License, Distribution.ModuleName, > + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, > + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, > + Distribution.SPDX.LicenseReference, > + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, > + Distribution.Simple.Doctest, Distribution.Simple.Haddock, > + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, > + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, > + Distribution.Simple.Program.Types, Distribution.Simple.Setup, > + Distribution.System, Distribution.Types.AbiDependency, > + Distribution.Types.AbiHash, Distribution.Types.Benchmark, > + Distribution.Types.BenchmarkInterface, > + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, > + Distribution.Types.BuildType, Distribution.Types.ComponentId, > + Distribution.Types.ComponentLocalBuildInfo, > + Distribution.Types.ComponentName, > + Distribution.Types.ComponentRequestedSpec, > + Distribution.Types.CondTree, Distribution.Types.Condition, > + Distribution.Types.Dependency, Distribution.Types.ExeDependency, > + Distribution.Types.Executable, Distribution.Types.ExecutableScope, > + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, > + Distribution.Types.ForeignLibOption, > + Distribution.Types.ForeignLibType, > + Distribution.Types.GenericPackageDescription, > + Distribution.Types.IncludeRenaming, > + Distribution.Types.InstalledPackageInfo, > + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, > + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, > + Distribution.Types.Module, Distribution.Types.ModuleReexport, > + Distribution.Types.ModuleRenaming, > + Distribution.Types.MungedPackageId, > + Distribution.Types.MungedPackageName, > + Distribution.Types.PackageDescription, > + Distribution.Types.PackageId, Distribution.Types.PackageName, > + Distribution.Types.PkgconfigDependency, > + Distribution.Types.PkgconfigName, > + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, > + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, > + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, > + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, > + Distribution.Types.Version, Distribution.Types.VersionRange, > + Distribution.Utils.ShortText, Distribution.Verbosity, > + Language.Haskell.Extension, Control.Applicative, Data.Complex, > + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, > + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, > + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, > + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, > + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, > + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, > + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, > + Data.Text, Data.Text.Lazy] > +WARNING: file compiler/utils/ListSetOps.hs, line 58 > + [Distribution.Backpack, Distribution.Backpack.FullUnitId, > + Distribution.Backpack.ModuleShape, > + Distribution.Backpack.PreModuleShape, > + Distribution.Backpack.ReadyComponent, > + Distribution.CabalSpecVersion, Distribution.Compat.Graph, > + Distribution.Compat.Semigroup, Distribution.Compiler, > + Distribution.License, Distribution.ModuleName, > + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, > + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, > + Distribution.SPDX.LicenseReference, > + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, > + Distribution.Simple.Doctest, Distribution.Simple.Haddock, > + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, > + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, > + Distribution.Simple.Program.Types, Distribution.Simple.Setup, > + Distribution.System, Distribution.Types.AbiDependency, > + Distribution.Types.AbiHash, Distribution.Types.Benchmark, > + Distribution.Types.BenchmarkInterface, > + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, > + Distribution.Types.BuildType, Distribution.Types.ComponentId, > + Distribution.Types.ComponentLocalBuildInfo, > + Distribution.Types.ComponentName, > + Distribution.Types.ComponentRequestedSpec, > + Distribution.Types.CondTree, Distribution.Types.Condition, > + Distribution.Types.Dependency, Distribution.Types.ExeDependency, > + Distribution.Types.Executable, Distribution.Types.ExecutableScope, > + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, > + Distribution.Types.ForeignLibOption, > + Distribution.Types.ForeignLibType, > + Distribution.Types.GenericPackageDescription, > + Distribution.Types.IncludeRenaming, > + Distribution.Types.InstalledPackageInfo, > + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, > + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, > + Distribution.Types.Module, Distribution.Types.ModuleReexport, > + Distribution.Types.ModuleRenaming, > + Distribution.Types.MungedPackageId, > + Distribution.Types.MungedPackageName, > + Distribution.Types.PackageDescription, > + Distribution.Types.PackageId, Distribution.Types.PackageName, > + Distribution.Types.PkgconfigDependency, > + Distribution.Types.PkgconfigName, > + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, > + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, > + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, > + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, > + Distribution.Types.Version, Distribution.Types.VersionRange, > + Distribution.Utils.ShortText, Distribution.Verbosity, > + Language.Haskell.Extension, Control.Applicative, Data.Complex, > + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, > + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, > + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, > + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, > + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, > + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, > + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, > + Data.Text, Data.Text.Lazy] > + [] > *** unexpected failure for cabal09(normal) > ``` > > This is probably orph calculation. New description: Example log: {{{ +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Haddock, + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, + Distribution.Simple.Program.Types, Distribution.Simple.Setup, + Distribution.System, Distribution.Types.AbiDependency, + Distribution.Types.AbiHash, Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] + [] +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [Control.Applicative, Data.Functor.Const, Data.Functor.Identity, + Data.Monoid, Data.Semigroup.Internal, GHC.Generics, + GHC.IO.Exception] + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Haddock, + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, + Distribution.Simple.Program.Types, Distribution.Simple.Setup, + Distribution.System, Distribution.Types.AbiDependency, + Distribution.Types.AbiHash, Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [] + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Haddock, + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, + Distribution.Simple.Program.Types, Distribution.Simple.Setup, + Distribution.System, Distribution.Types.AbiDependency, + Distribution.Types.AbiHash, Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.SPDX.License, Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Haddock, + Distribution.Simple.InstallDirs, Distribution.Simple.PackageIndex, + Distribution.Simple.Program.Find, Distribution.Simple.Program.GHC, + Distribution.Simple.Program.Types, Distribution.Simple.Setup, + Distribution.System, Distribution.Types.AbiDependency, + Distribution.Types.AbiHash, Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] + [] *** unexpected failure for cabal09(normal) }}} This is probably orph calculation. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 03:47:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 03:47:22 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.60fd4ab08854d09d6d652351e217749b@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14226 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In the `optasm` testsuite way, yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 04:30:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 04:30:19 -0000 Subject: [GHC] #14749: T13822 fails In-Reply-To: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> References: <046.93c73d475ecf1191c51a59ec09ee2393@haskell.org> Message-ID: <061.3803efd2f9c886b72dc931c7af71bde5@haskell.org> #14749: T13822 fails -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Confirmed that this is fixed by my fix to #12919. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 05:53:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 05:53:46 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.1e027eb9fd570fc2b5ae2fe9f725ba76@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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 bgamari): * priority: high => highest * milestone: 8.4.1 => 8.6.1 Comment: Indeed this is still reproducible on `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 07:54:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 07:54:22 -0000 Subject: [GHC] #14752: Unboxed sums documentation looks wrong In-Reply-To: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> References: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> Message-ID: <060.43e8e6f0d910c6b35a8c927f1200616c@haskell.org> #14752: Unboxed sums documentation looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4379 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4379 Comment: osa1, could you please review my patch and make sure I didn't get anything terribly wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 11:04:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 11:04:54 -0000 Subject: [GHC] #14760: Error reporting on obsolete file Message-ID: <045.736e568ccc7aecd75c287108170d52f2@haskell.org> #14760: Error reporting on obsolete file -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have just had this warning: {{{ Whatever.hs:41:1: warning: [-Wunused-imports] The import of ‘Data.Map’ is redundant except perhaps to import instances from ‘Data.Map’ To import instances alone, use: import Data.Map() | 41 | import Data.Foldable | ^^^^^^^^^^^^^^^^^^^^^ }}} This happens because the source file has been modified during the compilation: GHC shows an excerpt of the new file to report an error in the old file. Could we cache the old file somehow during the compilation to avoid this discrepancy? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 11:30:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 11:30:24 -0000 Subject: [GHC] #14738: Investigate performance of CoreTidy In-Reply-To: <047.ebb0353d7bf2252edbe2d77e554f7e84@haskell.org> References: <047.ebb0353d7bf2252edbe2d77e554f7e84@haskell.org> Message-ID: <062.f9f3bde832350691066a0fc6b71355be@haskell.org> #14738: Investigate performance of CoreTidy -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11735 #14683 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): The problem seems to mysteriously go away on newer commits. Adding more cost centres to GHC HEAD, I've found that `CoreTidy` hardly shows up in the profile at all, and practically all the remaining slowdown comes from code in `Simplify.hs`, which I believe #14737 is about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 11:36:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 11:36:55 -0000 Subject: [GHC] #14754: -O1 changes result at runtime In-Reply-To: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> References: <047.3c755adb5c61f1c679520a9bb2f9a010@haskell.org> Message-ID: <062.302c252ee0f76356b17782430d3370fc@haskell.org> #14754: -O1 changes result at runtime -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14226 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Wow, fast diagnosis Ryan! Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 11:50:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 11:50:52 -0000 Subject: [GHC] #14738: Investigate performance of CoreTidy In-Reply-To: <047.ebb0353d7bf2252edbe2d77e554f7e84@haskell.org> References: <047.ebb0353d7bf2252edbe2d77e554f7e84@haskell.org> Message-ID: <062.98d8c06e4667bf5c488c57776000e96c@haskell.org> #14738: Investigate performance of CoreTidy -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11735 #14683 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Profile, based on GHC HEAD + some changes from #11735 + added SCCs, compiling `Grammar.hs`: {{{ Mon Feb 5 12:47 2018 Time and Allocation Profiling Report (Final) ghc-stage2 +RTS -p -RTS -B/home/tobias/well- typed/devel/ghc/inplace/lib Grammar.hs -fforce-recomp total time = 12.73 secs (12733 ticks @ 1000 us, 1 processor) total alloc = 14,413,041,648 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc addCoerce-pushCoTyArg Simplify compiler/simplCore/Simplify.hs:1234:70-90 46.7 45.7 tc_rn_src_decls TcRnDriver compiler/typecheck/TcRnDriver.hs:(494,4)-(556,7) 12.2 14.0 subst_ty TyCoRep compiler/types/TyCoRep.hs:2265:28-32 7.0 10.4 tidyTopBinds TidyPgm compiler/main/TidyPgm.hs:370:21-82 3.3 3.5 writeIface HscMain compiler/main/HscMain.hs:1279:9-45 3.2 0.2 coercionKind Coercion compiler/types/Coercion.hs:1735:3-7 3.0 6.0 zonkTopDecls TcRnDriver compiler/typecheck/TcRnDriver.hs:(445,16)-(446,43) 2.1 2.2 simplExprF1-Lam Simplify compiler/simplCore/Simplify.hs:896:5-39 1.7 2.2 simplCast-simplCoercion Simplify compiler/simplCore/Simplify.hs:1224:57-77 1.6 1.5 deSugar HscMain compiler/main/HscMain.hs:511:7-44 1.5 1.3 findExternalRules TidyPgm compiler/main/TidyPgm.hs:366:23-77 1.1 0.2 Parser HscMain compiler/main/HscMain.hs:(316,5)-(384,20) 1.1 1.6 simplIdF Simplify compiler/simplCore/Simplify.hs:868:61-79 1.0 0.5 simplCast-addCoerce Simplify compiler/simplCore/Simplify.hs:1225:53-71 1.0 1.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 13:10:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 13:10:39 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.1b576be2bcb7679b2fba84378132dc1b@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Status: - Thing 1: Getting rid of non-linearity in coercionKind for the ForallCo case. Done. - Thing 2: Attacking non-linearity in coercionKindRole on NthCo's. I think this part is also more or less done, but I haven't seen anything on phab yet. - Thing 3: Fixing performance issues with `simplCast` / `SimplCore`. Moved to #14737, I believe @goldfire is still working on this. - Thing 4: Investigating `CoreTidy`. Moved to #14738, however it seems that the problem no longer manifests on GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 14:11:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 14:11:07 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness Message-ID: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #7210 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data A = A { a :: {-# UNPACK #-} Maybe Int} }}} {{{ [1 of 1] Compiling Main ( Temp.hs, Temp.o ) Temp.hs:1:19: error: • Unexpected strictness annotation: {-# UNPACK #-}Maybe • In the type ‘{-# UNPACK #-}Maybe Int’ In the definition of data constructor ‘A’ In the data declaration for ‘A’ | 1 | data A = A { a :: {-# UNPACK #-} Maybe Int} | }}} The diagnostic is incorrect because it complains about an "unexpected strictness annotation" although the error is the opposite. A quick glance at the relevant GHC code suggests that it's running into the wrong diagnostic from #7210. Verified on nightly-2018-01-29. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 14:19:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 14:19:24 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.83c686d8b6333b75d3eb9e96dbb51d63@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: #7210 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dminuoso): The problem only seems to trigger when there's a type constructor. {{{#!hs data A = A { a :: {-# UNPACK #-} Maybe Int} -- Wrong diagnostic data A = A { a :: {-# UNPACK #-} (,) Int Int } -- Wrong diagnostic }}} But not with the special type syntax or unary types {{{#!hs data A = A { a :: {-# UNPACK #-} (Int, Int) } -- Works data A = A { a :: {-# UNPACK #-} Int } -- Works }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 14:46:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 14:46:13 -0000 Subject: [GHC] #14752: Unboxed sums documentation looks wrong In-Reply-To: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> References: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> Message-ID: <060.a317bdfc84083c63954387fda29b6933@haskell.org> #14752: Unboxed sums documentation looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.4.2 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4379 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"d987f71aa3200ce0c94bc57c43b4fcc92eaccf76/ghc" d987f71/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d987f71aa3200ce0c94bc57c43b4fcc92eaccf76" Improve unboxed sum documentation * Clarify the representation of sums without fields. * Try to improve language, clarity, and examples. Fixes #14752 Reviewers: osa1, bgamari Reviewed By: osa1 Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14752 Differential Revision: https://phabricator.haskell.org/D4379 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 14:46:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 14:46:52 -0000 Subject: [GHC] #14752: Unboxed sums documentation looks wrong In-Reply-To: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> References: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> Message-ID: <060.e7aaf41c0ce8b1091d647b25d149e1fa@haskell.org> #14752: Unboxed sums documentation looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.4.2 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4379 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 15:00:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 15:00:58 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.faf8dcb87fd6370aa7c49a0decf57107@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm not still working on this. I pushed the changes I had in mind to the tdammers branch. If the performance is OK there, could you please Phab and then commit? As for `simplCast`, the changes I had in mind are all on your branch, including removing the inefficient one-variable substitution. If my changes aren't an improvement, try undoing the change I made to the ordering of cases in `simplCast`: I moved the `isReflexiveCo` case to the top, but perhaps that check is too expensive and is better at the bottom. Regardless, the changes I made in CoreOpt should be enough to improve performance. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 15:50:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 15:50:37 -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.567f1e2f489b99375106c14d0df96ab8@haskell.org> #7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: refold Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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: #8684 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * related: => #8684 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 15:51:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 15:51:07 -0000 Subject: [GHC] #8684: hWaitForInput cannot be interrupted by async exceptions on unix In-Reply-To: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> References: <042.bed34cc32ec4222496f7d8b921c80c8a@haskell.org> Message-ID: <057.6d70c704be1bbc4ac6935ed0cd06eb7f@haskell.org> #8684: hWaitForInput cannot be interrupted by async exceptions on unix -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13497, 13525 | Blocking: Related Tickets: #12912, #13525, | Differential Rev(s): Phab:D42 #7353 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * related: #12912, #13525 => #12912, #13525, #7353 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 15:52:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 15:52:29 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.a66df4c3a29eb5cb9500cb216d7c40bd@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): We agreed that Omer would invest a small amount of effort to see if any of the other benchmarks that have increased are easier to understand -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 15:56:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 15:56:54 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.04ae670aa0c5fc69376dc6c6fd7cef6c@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | Milestone: 8.6.1 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:D3723 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Edward Kmett seems to think this should wait indefinitely as `bitSize` is part of Haskell 2010. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 16:00:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 16:00:52 -0000 Subject: [GHC] #481: Recompilation check fails for TH In-Reply-To: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> References: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> Message-ID: <061.1453838f69090f5b53cf66fe43b5c799@haskell.org> #481: Recompilation check fails for TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: TH_recompile Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 16:00:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 16:00:46 -0000 Subject: [GHC] #14637: Simplifier Ticks Exhausted when compiling with profiling In-Reply-To: <048.f4904dcbe44c7548ff4503ec6ec99eff@haskell.org> References: <048.f4904dcbe44c7548ff4503ec6ec99eff@haskell.org> Message-ID: <063.cea92a974961f0535ba3377717a7c879@haskell.org> #14637: Simplifier Ticks Exhausted when compiling with profiling -------------------------------------+------------------------------------- Reporter: cfhammill | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Check the fix for #13253 in case that fixes this ticket tool -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 16:08:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 16:08:43 -0000 Subject: [GHC] #14396: Hs-boot woes during family instance consistency checks In-Reply-To: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> References: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> Message-ID: <061.948f192de5659f5dd3489009394d4fed@haskell.org> #14396: Hs-boot woes during family instance consistency checks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4154 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm afraid not and I believe it might be a rather tricky patch to backport. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 16:46:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 16:46:03 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.c28c8d949096c2738bb46b3a00fc742d@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: #7210 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This happens because both strictness annotations (`!`) and `UNPACK` annotations can decorate //any// type, and moreover, they bind more tightly than application. Therefore, this: {{{#!hs {-# UNPACK #-} Maybe Int }}} is shorthand for this: {{{#!hs ({-# UNPACK #-} Maybe) Int }}} You'll notice that you'll get a similar error if you had written `a :: ! Maybe Int`. So the error isn't incorrect—you are in fact putting `{-# UNPACK #-}` in the wrong place, and should have written it as `{-# UNPACK #-} (Maybe Int)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 18:12:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 18:12:39 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.facd1a828b058ff9cca290b6e98cce8d@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: #7210 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dminuoso): Thank you for the explanation. Is it correct to consider {-# UNPACK #-} itself a strictness annotation? As an end user I would expect it to be referred to as a pragma. Furthermore I still have to specify the strictness annotation ! for the field. If this is working as intended, then I think it's a somewhat poor message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 18:36:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 18:36:27 -0000 Subject: [GHC] #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations Message-ID: <042.4fd9cca9b74b01eb7ff1b72244aeca47@haskell.org> #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 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: -------------------------------------+------------------------------------- `Foreign.Marshal.Pool` uses `Data.List.delete` and `Data.List.elem` to determine whether a pointer is already in the pool and to delete them, as a result of `newtype Pool = Pool (IORef [Ptr ()])`. Thus repeated operations on pools with many entries can become very slow. If possible, we might consider using `Ord` on the `Ptr` and an O(log n) data structure instead of a `[Ptr]` list. Alternatively, we should warn in the docs that this is the case, but it seems better to just fix the implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 19:07:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 19:07:01 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.ede23c53dd57130ff4afa1308cd5b495@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: #7210 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK. Would you be satisfied if the error message said `Unexpected UNPACK pragma` instead of `Unexpected strictness annotation`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 19:56:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 19:56:53 -0000 Subject: [GHC] #14763: GHC 8.4.1-alpha regression with FunctionalDependencies Message-ID: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> #14763: GHC 8.4.1-alpha regression with FunctionalDependencies -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 (Type checker) | Keywords: FunDeps | 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: -------------------------------------+------------------------------------- This regression prevents `esqeueleto-2.5.3` from building with GHC 8.4.1. Here is a minimized example of the problem: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where data Value a = Value a data SomeValue expr where SomeValue :: Esqueleto query expr backend => expr (Value a) -> SomeValue expr class Esqueleto (query :: * -> *) (expr :: * -> *) backend | query -> expr backend, expr -> query backend data SqlQuery a data SqlBackend data SqlExpr a where ECompositeKey :: SqlExpr (Value a) instance Esqueleto SqlQuery SqlExpr SqlBackend match' :: SomeValue SqlExpr -> a match' (SomeValue ECompositeKey) = undefined }}} On GHC 8.2.2, this typechecks without issue. On GHC 8.4.1-alpha (version 8.4.0.20180204), this fails with: {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20180204: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:25:19: error: • Could not deduce: query ~ SqlQuery arising from a functional dependency between: constraint ‘Esqueleto query SqlExpr backend’ arising from a pattern with constructor: SomeValue :: forall (query :: * -> *) (expr :: * -> *) backend a. Esqueleto query expr backend => expr (Value a) -> SomeValue expr, in an equation for ‘match'’ instance ‘Esqueleto SqlQuery SqlExpr SqlBackend’ at Bug.hs:22:10-46 from the context: Value a1 ~ Value a2 bound by a pattern with constructor: ECompositeKey :: forall a. SqlExpr (Value a), in an equation for ‘match'’ at Bug.hs:25:19-31 ‘query’ is a rigid type variable bound by a pattern with constructor: SomeValue :: forall (query :: * -> *) (expr :: * -> *) backend a. Esqueleto query expr backend => expr (Value a) -> SomeValue expr, in an equation for ‘match'’ at Bug.hs:25:9-31 Inaccessible code in a pattern with constructor: ECompositeKey :: forall a. SqlExpr (Value a), in an equation for ‘match'’ • In the pattern: ECompositeKey In the pattern: SomeValue ECompositeKey In an equation for ‘match'’: match' (SomeValue ECompositeKey) = undefined | 25 | match' (SomeValue ECompositeKey) = undefined | ^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 19:57:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 19:57:20 -0000 Subject: [GHC] #14763: GHC 8.4.1-alpha regression with FunctionalDependencies In-Reply-To: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> References: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> Message-ID: <065.8a82e1217b791ff8d9a724668ef771b3@haskell.org> #14763: GHC 8.4.1-alpha regression with FunctionalDependencies -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha3 checker) | Resolution: | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > This regression prevents `esqeueleto-2.5.3` from building with GHC 8.4.1. > Here is a minimized example of the problem: > > {{{#!hs > {-# LANGUAGE FunctionalDependencies #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE MultiParamTypeClasses #-} > module Bug where > > data Value a = Value a > > data SomeValue expr where > SomeValue :: Esqueleto query expr backend => expr (Value a) -> > SomeValue expr > > class Esqueleto (query :: * -> *) (expr :: * -> *) backend > | query -> expr backend, expr -> query backend > > data SqlQuery a > > data SqlBackend > > data SqlExpr a where > ECompositeKey :: SqlExpr (Value a) > > instance Esqueleto SqlQuery SqlExpr SqlBackend > > match' :: SomeValue SqlExpr -> a > match' (SomeValue ECompositeKey) = undefined > }}} > > On GHC 8.2.2, this typechecks without issue. On GHC 8.4.1-alpha (version > 8.4.0.20180204), this fails with: > > {{{ > $ /opt/ghc/8.4.1/bin/ghci Bug.hs > GHCi, version 8.4.0.20180204: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/rgscott/.ghci > [1 of 1] Compiling Bug ( Bug.hs, interpreted ) > > Bug.hs:25:19: error: > • Could not deduce: query ~ SqlQuery > arising from a functional dependency between: > constraint ‘Esqueleto query SqlExpr backend’ > arising from a pattern with constructor: > SomeValue :: forall (query :: * -> *) (expr :: > * -> *) backend a. > Esqueleto query expr backend => > expr (Value a) -> SomeValue expr, > in an equation for ‘match'’ > instance ‘Esqueleto SqlQuery SqlExpr SqlBackend’ at > Bug.hs:22:10-46 > from the context: Value a1 ~ Value a2 > bound by a pattern with constructor: > ECompositeKey :: forall a. SqlExpr (Value a), > in an equation for ‘match'’ > at Bug.hs:25:19-31 > ‘query’ is a rigid type variable bound by > a pattern with constructor: > SomeValue :: forall (query :: * -> *) (expr :: * -> *) backend > a. > Esqueleto query expr backend => > expr (Value a) -> SomeValue expr, > in an equation for ‘match'’ > at Bug.hs:25:9-31 > Inaccessible code in > a pattern with constructor: > ECompositeKey :: forall a. SqlExpr (Value a), > in an equation for ‘match'’ > • In the pattern: ECompositeKey > In the pattern: SomeValue ECompositeKey > In an equation for ‘match'’: > match' (SomeValue ECompositeKey) = undefined > | > 25 | match' (SomeValue ECompositeKey) = undefined > | ^^^^^^^^^^^^^ > }}} New description: This regression prevents `esqueleto-2.5.3` from building with GHC 8.4.1. Here is a minimized example of the problem: {{{#!hs {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} module Bug where data Value a = Value a data SomeValue expr where SomeValue :: Esqueleto query expr backend => expr (Value a) -> SomeValue expr class Esqueleto (query :: * -> *) (expr :: * -> *) backend | query -> expr backend, expr -> query backend data SqlQuery a data SqlBackend data SqlExpr a where ECompositeKey :: SqlExpr (Value a) instance Esqueleto SqlQuery SqlExpr SqlBackend match' :: SomeValue SqlExpr -> a match' (SomeValue ECompositeKey) = undefined }}} On GHC 8.2.2, this typechecks without issue. On GHC 8.4.1-alpha (version 8.4.0.20180204), this fails with: {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20180204: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:25:19: error: • Could not deduce: query ~ SqlQuery arising from a functional dependency between: constraint ‘Esqueleto query SqlExpr backend’ arising from a pattern with constructor: SomeValue :: forall (query :: * -> *) (expr :: * -> *) backend a. Esqueleto query expr backend => expr (Value a) -> SomeValue expr, in an equation for ‘match'’ instance ‘Esqueleto SqlQuery SqlExpr SqlBackend’ at Bug.hs:22:10-46 from the context: Value a1 ~ Value a2 bound by a pattern with constructor: ECompositeKey :: forall a. SqlExpr (Value a), in an equation for ‘match'’ at Bug.hs:25:19-31 ‘query’ is a rigid type variable bound by a pattern with constructor: SomeValue :: forall (query :: * -> *) (expr :: * -> *) backend a. Esqueleto query expr backend => expr (Value a) -> SomeValue expr, in an equation for ‘match'’ at Bug.hs:25:9-31 Inaccessible code in a pattern with constructor: ECompositeKey :: forall a. SqlExpr (Value a), in an equation for ‘match'’ • In the pattern: ECompositeKey In the pattern: SomeValue ECompositeKey In an equation for ‘match'’: match' (SomeValue ECompositeKey) = undefined | 25 | match' (SomeValue ECompositeKey) = undefined | ^^^^^^^^^^^^^ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 20:32:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 20:32:56 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.b8f3d2a592ba38b8f0ebb6c92596fc9e@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Rev(s): Phab:D343 Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): What is the status of this ticket? I've tried the patch suggested in comment:34, but my results of nofib were quite different, with some clear regressions (below I've removed anything where the difference was <2%) {{{ NoFib Results -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- CSD -0.4% 0.0% +7.4% +7.4% 0.0% S -0.5% 0.0% +3.2% +3.3% 0.0% VS -0.5% 0.0% -4.4% -4.4% 0.0% VSM -0.5% 0.0% +8.7% +8.7% 0.0% bspt -0.5% 0.0% 0.003 0.003 +50.0% constraints -0.4% 0.0% +2.5% +2.6% 0.0% cryptarithm1 -0.4% 0.0% +6.0% +6.0% 0.0% exact-reals -1.2% 0.0% -2.7% -2.7% 0.0% fannkuch-redux -0.4% 0.0% -2.5% -2.5% 0.0% fasta -0.4% 0.0% +7.7% +7.6% 0.0% k-nucleotide -0.8% +0.0% +17.9% +18.0% 0.0% lambda -0.4% 0.0% -2.2% -2.1% 0.0% linear -1.2% 0.0% -5.9% -5.9% 0.0% mate -0.4% 0.0% -2.2% -2.2% 0.0% n-body -0.9% 0.0% +3.2% +3.2% 0.0% -------------------------------------------------------------------------------- Min -1.4% -0.2% -5.9% -5.9% 0.0% Max -0.2% +0.0% +17.9% +18.0% +50.0% Geometric Mean -0.7% -0.0% +1.7% +1.6% +0.4% }}} I've tried to have a look into `k-nucleotide`, which slowed down the most. My current understanding is that there's a tight loop within a single function that goes like this: - A: some computation, eventually goes to B - B: case on `andI# variable 127#` (one alternative is the slow path that allocates, the other is fast that doesn't) - C: alternative that does a bit of computation (but no allocation) and jumps back A Now with the change we get a heap check in front of the case, which will now be executed on every iteration and slow everything down. NOTE: I don't have much experience with investigations like this, so the whole analysis might be quite wrong. ;) Please let me know if something seems off. I'll attach the dump of STG/cmm/asm from both versions of `k-nucleotide` (with and without the patch). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 20:38:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 20:38:35 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.beb96d91926e4f3db6b0e9eb318cdfb4@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Rev(s): Phab:D343 Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * Attachment "knucleotide-master-and-patch-dumps.tar.bz2" added. STG/cmm/asm dumps of k-nucleotide from the current master and the patched GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 20:56:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 20:56:10 -0000 Subject: [GHC] #14764: Make $! representation-polymorphic Message-ID: <045.53df127e2c7b6a62fee488d1dc8b9a13@haskell.org> #14764: Make $! representation-polymorphic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D4382 | Wiki Page: -------------------------------------+------------------------------------- Currently, {{{#!hs ($) :: forall r a (b :: TYPE r). (a -> b) -> a -> b }}} but {{{#!hs ($!) :: (a -> b) -> a -> b }}} It seems fairly obvious that we should generalize `($!)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 20:56:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 20:56:27 -0000 Subject: [GHC] #14764: Make $! representation-polymorphic In-Reply-To: <045.53df127e2c7b6a62fee488d1dc8b9a13@haskell.org> References: <045.53df127e2c7b6a62fee488d1dc8b9a13@haskell.org> Message-ID: <060.73e79dc56490d12d3ce27645d10190fd@haskell.org> #14764: Make $! representation-polymorphic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4382 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 21:08:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 21:08:39 -0000 Subject: [GHC] #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations In-Reply-To: <042.4fd9cca9b74b01eb7ff1b72244aeca47@haskell.org> References: <042.4fd9cca9b74b01eb7ff1b72244aeca47@haskell.org> Message-ID: <057.28e5e3c0526de7bbec41430a8863ba70@haskell.org> #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sounds reasonable to me. Patches welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 21:12:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 21:12:40 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.d86c2d6dd2dea0aa06d1ad20b4909ecc@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | 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:D3723 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => ⊥ Comment: Alright; un-milestoning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 21:21:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 21:21:24 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.4826e7f1c3d884f7c41d558658d494fa@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: michalt Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Keywords: newcomer, Resolution: | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #14754 | Differential Rev(s): Phab:D3973, Wiki Page: | Phab:D3999 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => michalt Comment: Happily, michalt may be looking into this later this week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 21:24:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 21:24:06 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.e3b4a0eedbc35d41d11bb5782e76dc5c@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 bgamari): It sounds like we should probably just move this to a proper set operation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 22:16:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 22:16:18 -0000 Subject: [GHC] #14765: Levity polymorphism panic Message-ID: <045.04b286131d704736c3efb57c6bc8d169@haskell.org> #14765: Levity polymorphism panic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- I imagine I have made a mistake, but GHC shouldn't panic! {{{#!hs {-# language TypeInType, ScopedTypeVariables, MagicHash #-} import GHC.Exts (TYPE, Proxy#, proxy#) fold :: forall rep a (r :: TYPE rep). (r -> a -> Proxy# r -> r) -> (Proxy# r -> r) -> [a] -> r fold f k [] = k proxy# fold f k (x : xs) = fold f (f (k proxy#) x) xs }}} This gives me {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20171211 for x86_64-unknown-linux): splitFunTy () Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:921:30 in ghc:Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 22:18:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 22:18:11 -0000 Subject: [GHC] #14765: Levity polymorphism panic In-Reply-To: <045.04b286131d704736c3efb57c6bc8d169@haskell.org> References: <045.04b286131d704736c3efb57c6bc8d169@haskell.org> Message-ID: <060.824d148cf7864a8bbffef94a240df991@haskell.org> #14765: Levity polymorphism panic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 22:30:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 22:30:28 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.ce652ec9d8c7023981d2e31c0ddf355a@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: #7210 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dminuoso): That sounds much better and less confusing given the context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 22:59:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 22:59:08 -0000 Subject: [GHC] #14763: GHC 8.4.1-alpha regression with FunctionalDependencies In-Reply-To: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> References: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> Message-ID: <065.eab38ecb6f893d892b91687904901f9d@haskell.org> #14763: GHC 8.4.1-alpha regression with FunctionalDependencies -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha3 checker) | Resolution: | Keywords: FunDeps 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: simonpj (added) Comment: This regression was introduced in f20cf982f126aea968ed6a482551550ffb6650cf (`Remove wc_insol from WantedConstraints`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 23:03:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 23:03:40 -0000 Subject: [GHC] #14720: GHC 8.4.1-alpha regression with TypeInType In-Reply-To: <050.3979775ac8fffda86c79c2a678f92178@haskell.org> References: <050.3979775ac8fffda86c79c2a678f92178@haskell.org> Message-ID: <065.c4e62c0bba01d4d542c62b3d781e3903@haskell.org> #14720: GHC 8.4.1-alpha regression with TypeInType -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): For the record, here's a smaller test case: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module SGenerics where import Data.Kind (Type) type family R :: Type data family Sing (z :: R) type family PFrom (x :: Type) :: R u :: forall (a :: R). Sing a u = u v :: forall (a :: Type). Sing (PFrom a) v = u }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 5 23:36:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Feb 2018 23:36:20 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.5ae7e81256b4033c3f3ebe267af90d0b@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | 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:D3723 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I wouldn't say indefinitely. There is a Haskell Prime Committee that when I last checked was aiming for a 2020 report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 01:25:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 01:25:13 -0000 Subject: [GHC] #14763: GHC 8.4.1-alpha regression with FunctionalDependencies In-Reply-To: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> References: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> Message-ID: <065.55617a031a0b3c770356f39d57c2061c@haskell.org> #14763: GHC 8.4.1-alpha regression with FunctionalDependencies -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha3 checker) | Resolution: | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thank you RyanGlScott! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 02:33:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 02:33:15 -0000 Subject: [GHC] #14637: Simplifier Ticks Exhausted when compiling with profiling In-Reply-To: <048.f4904dcbe44c7548ff4503ec6ec99eff@haskell.org> References: <048.f4904dcbe44c7548ff4503ec6ec99eff@haskell.org> Message-ID: <063.171427be07a29de4b743986dc1c74c39@haskell.org> #14637: Simplifier Ticks Exhausted when compiling with profiling -------------------------------------+------------------------------------- Reporter: cfhammill | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): simonpj, that fix seems to help ''some'' (increasing the size needed to exhaust simplifier ticks), but it does not fix the problem. I haven't yet gotten a sense of where the time is going. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 03:14:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 03:14:36 -0000 Subject: [GHC] #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration In-Reply-To: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> References: <050.05d716a2c5be2cade611e1ab44e0e3c6@haskell.org> Message-ID: <065.101b091231749297b843681eda2a891c@haskell.org> #13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10607 | Differential Rev(s): Phab:D4383 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4383 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 04:00:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 04:00:06 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.8062d2b380f6f6756cc2e6076dd5f9b9@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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 dfeuer): bgamari, what stage 0 compiler are you using? What version of LLVM? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 04:08:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 04:08:19 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.9a5ba9f6074fc6ab724301aca5742819@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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 dfeuer): Also, are you passing `-fPIC` specifically somewhere? I'm only asking these picky questions because if this is LLVM-only, it seems awfully likely to be something horrible going wrong generating code for the stage 1 compiler. I don't think we really do anything LLVM specific in the specializer or the simplifier, although I could be missing something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 04:29:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 04:29:15 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.d319c90f17795a7be5ebc8051d11676f@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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 dfeuer): Another question: what exactly am I supposed to do about the fact that the stage 0 compiler and the stage 1 compiler each want ''only'' their preferred LLVM versions, and those are different? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 04:31:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 04:31:09 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.4893599b2a2d52104f5fff1fc2e0dad1@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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 dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 06:21:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 06:21:20 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.48457e4388822eb9698e9b161d2efabf@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: #7210 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I also agree that referring to `{-# UNPACK #-}` as "pragma" and `!` as "annotation" would be much better here. I'm also a bit surprised that `{-# UNPACK #-}` has such high precedence. This is not the case with some other annotations, e.g. `{-# SCC ... #-}` has quite low precedence so when I have `f = {-# SCC my_application #-} g a b c` it covers `g a b c` not just `g`. Because we can't unpack just some part of a field in a data con I think it'd make sense for `UNPACK` to have very low precedence. I think lowering the precedence would be backwards compatible too. Any thought on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 06:39:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 06:39:44 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.6d3fef894e8c48083d4a06c7cc7de865@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: (none) => sighingnow * failure: None/Unknown => Compile-time performance bug * differential: => Phab:D4384 Comment: After profiling, I found that the `pprASCII` function consumed the most part of memory. {{{ codeOutput HscMain compiler\main\HscMain.hs:(1349,19)-(1350,67) 1863 2 0.1 0.0 84.6 94.3 OutputAsm CodeOutput compiler\main\CodeOutput.hs:(169,37)-(171,78) 1873 2 0.2 0.0 84.6 94.3 NativeCodeGen CodeOutput compiler\main\CodeOutput.hs:171:18-78 1874 2 0.0 0.0 84.3 94.3 cmmNativeGenStream AsmCodeGen compiler\nativeGen\AsmCodeGen.hs:(342,56)-(343,50) 1875 2 0.0 0.0 84.3 94.3 cmmNativeGens AsmCodeGen compiler\nativeGen\AsmCodeGen.hs:(432,53)-(433,66) 1886 21 0.0 0.0 80.3 87.8 pprNativeCode AsmCodeGen compiler\nativeGen\AsmCodeGen.hs:(530,37)-(531,65) 1891 109 43.9 22.3 51.5 30.3 x86_pprNatCmmDecl_CmmData X86.Ppr compiler\nativeGen\X86\Ppr.hs:78:43-82 1901 0 0.1 0.0 7.5 8.0 pprDataItem' X86.Ppr compiler\nativeGen\X86\Ppr.hs:477:76-98 1910 124 0.0 0.0 0.0 0.0 pprDataItem'_vcat X86.Ppr compiler\nativeGen\X86\Ppr.hs:481:37-95 1911 124 0.0 0.0 0.0 0.0 pprData_CmmString X86.Ppr compiler\nativeGen\X86\Ppr.hs:152:36-90 1903 0 0.0 0.0 7.5 8.0 pprASCII X86.Ppr compiler\nativeGen\X86\Ppr.hs:199:28-62 1905 0 7.5 8.0 7.5 8.0 x86_pprNatCmmDecl_CmmProc X86.Ppr compiler\nativeGen\X86\Ppr.hs:(81,43)-(113,26) 1965 0 0.0 0.0 0.1 0.0 pprDataItem' X86.Ppr compiler\nativeGen\X86\Ppr.hs:477:76-98 1968 122 0.0 0.0 0.0 0.0 pprDataItem'_vcat X86.Ppr compiler\nativeGen\X86\Ppr.hs:481:37-95 1969 122 0.0 0.0 0.0 0.0 seqString AsmCodeGen compiler\nativeGen\AsmCodeGen.hs:505:33-95 1908 109 0.0 0.0 0.0 0.0 x86_pprNatCmmDecl_CmmData X86.Ppr compiler\nativeGen\X86\Ppr.hs:78:43-82 1900 85 0.0 0.0 28.6 57.3 pprData_CmmString X86.Ppr compiler\nativeGen\X86\Ppr.hs:152:36-90 1902 66 0.0 0.0 28.6 57.3 pprASCII X86.Ppr compiler\nativeGen\X86\Ppr.hs:199:28-62 1904 66 28.6 57.3 28.6 57.3 }}} The embed bytestring generates a large literal bytestring in assembly code, represented by `(CmmString [Word8])`. The `pprASCII` function will generated a list of Lit SDoc then use `hcat` to combine them. I have made some optimization to `pprASCII` in Phab:D4384, after this patch this `pprASCII` still consume the most part of memory allocation, but it can decrease the total memory allocation efficiently. Before: {{{ total time = 2.43 secs (2429 ticks @ 1000 us, 1 processor) total alloc = 4,741,422,496 bytes (excludes profiling overheads) }}} After: {{{ total time = 0.85 secs (851 ticks @ 1000 us, 1 processor) total alloc = 1,343,531,416 bytes (excludes profiling overheads) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 06:46:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 06:46:29 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.cd6bf883b91c1a302189e79c87f55cb6@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): After the optimization of `pprASCII`, I found the other two cost center: {{{ COST CENTRE MODULE SRC %time %alloc pprASCII X86.Ppr compiler\nativeGen\X86\Ppr.hs:181:28-92 47.8 56.2 tc_rn_src_decls TcRnDriver compiler\typecheck\TcRnDriver.hs:(494,4)-(556,7) 6.7 10.4 mapM_cgTopBinding StgCmm compiler\codeGen\StgCmm.hs:90:43-84 5.4 22.6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 06:53:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 06:53:45 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.c32b8ed25118dd969449f6a8690bdf5f@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Further optimization for `pprASCII` needs change `CmmString [Word8]` to `CmmString ByteString`. I have test the performance of unpacking `ByteString` to [Word8]: {{{ embedFile :: FilePath -> IO [Word8] embedFile fp = do print fp B.unpack <$> B.readFile fp main :: IO () main = do x' <- {-# SCC "forceRead" #-} (force <$> embedFile "3mb") print (length x') }}} It generates the following prof result: {{{ foldr-test.exe +RTS -p -RTS total time = 0.07 secs (74 ticks @ 1000 us, 1 processor) total alloc = 130,807,344 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc forceRead Main foldr-test.hs:44:35-61 67.6 100.0 MAIN MAIN 32.4 0.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 07:02:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 07:02:11 -0000 Subject: [GHC] #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations In-Reply-To: <042.4fd9cca9b74b01eb7ff1b72244aeca47@haskell.org> References: <042.4fd9cca9b74b01eb7ff1b72244aeca47@haskell.org> Message-ID: <057.e98d16a9e3431fff72420b24925d8497@haskell.org> #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations -------------------------------------+------------------------------------- Reporter: nh2 | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: (none) => sighingnow -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 07:46:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 07:46:19 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.4862027cb020202951427d0eac79241a@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | 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:D3723 Wiki Page: | -------------------------------------+------------------------------------- Comment (by txnull): Then maybe back to my initial idea and add a default implementation for bitSize in the mean time? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 08:43:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 08:43:49 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.2bf6475599d8b1665f2746e6b3b69811@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: #7210 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Both `{-# UNPACK #-}` and `!` only make sense at the outer level of a type in a data constructor field. But in GADT-style declarations, they can appear to be "inside" a type {{{ data T where K :: !(Maybe Int) -> {-# UNPACK #-} !Int -> T }}} Somehow `!` looks as if it should bind tightly. e.g. `!Maybe Int -> T` looks wrong. But I agree that `{-# UNPACK #-}` would be better with a lower precedence. Since these annotations/pragmas can't occur nested (except as above), I don't think it would be a breaking change to reduce the precedence of `{-# UNPACK #-}` if someone wants to make a proposal. Meanwhile, yes, the error message should be better. Something about saying `{-# UNPACK #-}` cannot appear nested inside a type might help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 08:49:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 08:49:16 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.0b7809a769acac9922f87a586a9aec8e@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Rev(s): Phab:D343 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What Michael says in comment:42 seems to be exactly what item (3) in the Description is all about. If the hot path does not allocate, then adding an allocation check into the hot path will cost time, eve if it reduces binary size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 09:13:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 09:13:39 -0000 Subject: [GHC] #12685: getNumProcessors semantics dont match documentation In-Reply-To: <043.7166490946f73da79c709fdf98d75140@haskell.org> References: <043.7166490946f73da79c709fdf98d75140@haskell.org> Message-ID: <058.1d88145dc901e6b4e1011030de5471f2@haskell.org> #12685: getNumProcessors semantics dont match documentation -------------------------------------+------------------------------------- Reporter: Llgn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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 sighingnow): The function `getNumberOfProcessors` also used in rts to decide the number of capabilities.Should we update the documentation as "Returns the number of CPUs that **the runtime can use**" ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 09:19:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 09:19:37 -0000 Subject: [GHC] #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations In-Reply-To: <042.4fd9cca9b74b01eb7ff1b72244aeca47@haskell.org> References: <042.4fd9cca9b74b01eb7ff1b72244aeca47@haskell.org> Message-ID: <057.68534e8e1e301bdfc335b15eecf6ed4b@haskell.org> #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations -------------------------------------+------------------------------------- Reporter: nh2 | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Replying to [comment:1 bgamari]: > Sounds reasonable to me. Patches welcome! I'm willing to do the job. There's no tree data structure defined in base, could I add a minimal heap implementation in `Foreign/Marshal/Pool.hs` to support this patch ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 09:39:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 09:39:34 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.9087124ce22d1409f12f73fe9b1bedcb@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): https://phabricator.haskell.org/D4385 should have all the relevant changes for subtasks 2 and 3, and the SCC's I added to (unsuccessfully) hunt down subtask 4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 09:43:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 09:43:03 -0000 Subject: [GHC] #14683: Slow compile times for Happy-generated source In-Reply-To: <050.c267d901f7aabb72ea60ae5332333f63@haskell.org> References: <050.c267d901f7aabb72ea60ae5332333f63@haskell.org> Message-ID: <065.a4a22086a1a4b99aeced0d10cd014bc4@haskell.org> #14683: Slow compile times for Happy-generated source -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): #1 has been addressed fairly thoroughly in #11735, bringing execution time down from ~250 s to ~12 s. Closing this for now, especially considering how #11598 doesn't seem very promising and how we have implemented some role caching in more specific spots as part of #11735. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 09:43:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 09:43:49 -0000 Subject: [GHC] #14683: Slow compile times for Happy-generated source In-Reply-To: <050.c267d901f7aabb72ea60ae5332333f63@haskell.org> References: <050.c267d901f7aabb72ea60ae5332333f63@haskell.org> Message-ID: <065.cc1d30c931a5d788c6dfdd6fbcadaa3d@haskell.org> #14683: Slow compile times for Happy-generated source -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * status: new => closed * resolution: => fixed Comment: Fixed / will be fixed via #11735. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 09:48:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 09:48:43 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.776e06b31f83fd60a9a0ee935dd245a0@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11735 #14683 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Implemented in: https://phabricator.haskell.org/D4385 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 09:54:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 09:54:58 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.1b77d973a69bf858516df95ab0c06217@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11735 #14683 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * status: new => closed * resolution: => fixed Comment: Fixing via #11735. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 14:37:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 14:37:31 -0000 Subject: [GHC] #14637: Simplifier Ticks Exhausted when compiling with profiling In-Reply-To: <048.f4904dcbe44c7548ff4503ec6ec99eff@haskell.org> References: <048.f4904dcbe44c7548ff4503ec6ec99eff@haskell.org> Message-ID: <063.2f3dd2dac56f1e23d17fbe77da91eed7@haskell.org> #14637: Simplifier Ticks Exhausted when compiling with profiling -------------------------------------+------------------------------------- Reporter: cfhammill | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Compile with `inplace/bin/ghc-stage2 --make bug2.hs -prof -fprof-auto-top -fforce-recomp -O -fno-s trictness -fno-specialise -fno-do-lambda-eta-expansion` then the error disappears. From trace the most of `tick` calls come from `simplLam` in simplCore/Simplify.hs, {{{ simplLam env (bndr:bndrs) body (ApplyToTy { sc_arg_ty = arg_ty, sc_cont = cont }) = do { tick (BetaReduction bndr) ; simplLam (extendTvSubst env bndr arg_ty) bndrs body cont } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 14:40:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 14:40:39 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.dc1ed4aab2b7c058bce2b31df89c9999@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11735 #14683 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 14:41:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 14:41:12 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.8b5712aaa8824ec1170e81a1116d4bcd@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => patch * differential: => Phab:D4385 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 15:19:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 15:19:38 -0000 Subject: [GHC] #14740: Unboxed tuple allowed in context: ((##)) => () In-Reply-To: <051.8b8e98ba0843035c110393441bb1b895@haskell.org> References: <051.8b8e98ba0843035c110393441bb1b895@haskell.org> Message-ID: <066.84b563d95791d0841c41c9098cf681be@haskell.org> #14740: Unboxed tuple allowed in context: ((##)) => () -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: sighingnow Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Parser) | Resolution: | Keywords: UnboxedTuples Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14740 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4359 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 16:05:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 16:05:41 -0000 Subject: [GHC] #14766: Hole-y partial type signatures greatly slow down compile times Message-ID: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> #14766: Hole-y partial type signatures greatly slow down compile times -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- This time, I actually mean it. :) Originally reported [https://github.com/simonmar/happy/issues/109 here], I distilled the example from [https://github.com/simonmar/happy/issues/109#issuecomment-362957245 this comment] into a one file test case. `Sigs.hs` is exactly like `NoSigs.hs`, except for the fact that it has a bunch of extra type signatures that have a lot of holes. On my machine, this is what compilation times are (I gave up timing after 15 minutes): || GHC version || 8.0.2 || 8.2.1 || 8.4.1 (445554b6d9a2263f969e25bb9f532dd0c3a9dc8c) || || `NoSigs.hs` || 24.13s || 22.93s || 34.05s || || `Sigs.hs` || >15m || >15m || >15m || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 16:13:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 16:13:28 -0000 Subject: [GHC] #14766: Hole-y partial type signatures greatly slow down compile times In-Reply-To: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> References: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> Message-ID: <065.5ad5082a2b75297ba30e1bb5966f8dd1@haskell.org> #14766: Hole-y partial type signatures greatly slow down compile times -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Fantastic. Where can I find `Sigs.hs` and `NoSigs.hs`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 16:14:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 16:14:56 -0000 Subject: [GHC] #14766: Hole-y partial type signatures greatly slow down compile times In-Reply-To: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> References: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> Message-ID: <065.c62f79b8f0a0f8d68922f5ae2e15723b@haskell.org> #14766: Hole-y partial type signatures greatly slow down compile times -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * Attachment "NoSigs.y" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 16:15:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 16:15:12 -0000 Subject: [GHC] #14766: Hole-y partial type signatures greatly slow down compile times In-Reply-To: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> References: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> Message-ID: <065.7cb04580517c422c9e9a844513557c93@haskell.org> #14766: Hole-y partial type signatures greatly slow down compile times -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * Attachment "Sigs.y" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 16:17:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 16:17:25 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.abac3e9d9a4d1ce9a5cca965eb1568f4@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:4 dfeuer]: > bgamari, what stage 0 compiler are you using? What version of LLVM? GHC 8.2.1; LLVM 5.0.0. > Also, are you passing -fPIC specifically somewhere? Nope; I made only the changes described in the summary. > Another question: what exactly am I supposed to do about the fact that the stage 0 compiler and the stage 1 compiler each want only their preferred LLVM versions, and those are different? Both should use version-suffixed LLVM executable names. `configure` uses such executables preferentially when searching for LLVM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 16:18:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 16:18:08 -0000 Subject: [GHC] #14766: Hole-y partial type signatures greatly slow down compile times In-Reply-To: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> References: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> Message-ID: <065.af4ebe8cdbee31554f97ed404831a5dc@haskell.org> #14766: Hole-y partial type signatures greatly slow down compile times -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Unfortunately, `Sigs.hs` and `NoSigs.hs` are too big to upload. Here they are on [https://gist.github.com/harpocrates/93af4a98fb7bab62cf3fb1517279a48c GitHub gists]. Alternately, you can generate them (or rather generate very similar files, modulo some CPP) via: {{{ $ happy-1.19.8 -agc Sigs.y -o Sigs.hs $ happy-1.19.8 -agc NoSigs.y -o NoSigs.hs }}} Note that you _must_ use `happy` version 1.19.8 or later. Sorry for any confusion! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 16:20:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 16:20:49 -0000 Subject: [GHC] #14766: Hole-y partial type signatures greatly slow down compile times In-Reply-To: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> References: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> Message-ID: <065.a4d80f820f6d03d500e5f605d4b9482b@haskell.org> #14766: Hole-y partial type signatures greatly slow down compile times -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by harpocrates: Old description: > This time, I actually mean it. :) > > Originally reported [https://github.com/simonmar/happy/issues/109 here], > I distilled the example from > [https://github.com/simonmar/happy/issues/109#issuecomment-362957245 this > comment] into a one file test case. `Sigs.hs` is exactly like > `NoSigs.hs`, except for the fact that it has a bunch of extra type > signatures that have a lot of holes. On my machine, this is what > compilation times are (I gave up timing after 15 minutes): > > || GHC version || 8.0.2 || 8.2.1 || 8.4.1 > (445554b6d9a2263f969e25bb9f532dd0c3a9dc8c) || > || `NoSigs.hs` || 24.13s || 22.93s || 34.05s || > || `Sigs.hs` || >15m || >15m || >15m || New description: This time, I actually mean it. :) Originally reported [https://github.com/simonmar/happy/issues/109 here], I distilled the example from [https://github.com/simonmar/happy/issues/109#issuecomment-362957245 this comment] into a one file test case. `Sigs.hs` is exactly like `NoSigs.hs`, except for the fact that it has a bunch of extra type signatures that have a lot of holes. On my machine, this is what compilation times are (I gave up timing after 15 minutes): || GHC version || 8.0.2 || 8.2.1 || 8.4.1 (445554b6d9a2263f969e25bb9f532dd0c3a9dc8c) || || `NoSigs.hs` || 24.13s || 22.93s || 34.05s || || `Sigs.hs` || >15m || ~13m || >15m || -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 16:24:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 16:24:50 -0000 Subject: [GHC] #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations In-Reply-To: <042.4fd9cca9b74b01eb7ff1b72244aeca47@haskell.org> References: <042.4fd9cca9b74b01eb7ff1b72244aeca47@haskell.org> Message-ID: <057.aa458a13fd46e6f7900c87bc30d2c5ea@haskell.org> #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations -------------------------------------+------------------------------------- Reporter: nh2 | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sounds reasonable to me. Let's just make sure there are adequate tests to demonstrate correctness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 16:25:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 16:25:11 -0000 Subject: [GHC] #12685: getNumProcessors semantics dont match documentation In-Reply-To: <043.7166490946f73da79c709fdf98d75140@haskell.org> References: <043.7166490946f73da79c709fdf98d75140@haskell.org> Message-ID: <058.b3a5c458988ef7284a427a10c92c3a34@haskell.org> #12685: getNumProcessors semantics dont match documentation -------------------------------------+------------------------------------- Reporter: Llgn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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): Yes we should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 16:54:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 16:54:34 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.9e5968af49d73d7a872458c86fedfc46@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7210 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer Comment: Changing the error message at the very least should be straightforward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 17:58:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 17:58:42 -0000 Subject: [GHC] #14693: Computing imp_finst can take up significant amount of time In-Reply-To: <046.a9caa20b4ad6e8f61c2910051e03ba80@haskell.org> References: <046.a9caa20b4ad6e8f61c2910051e03ba80@haskell.org> Message-ID: <061.e644ec1021978d9f6a40f5b922f4c233@haskell.org> #14693: Computing imp_finst can take up significant amount of time -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 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): phab:D4369 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"d2511e3b61563ed3fc2c9aec2c90a4156373a24c/ghc" d2511e3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d2511e3b61563ed3fc2c9aec2c90a4156373a24c" Compute the union of imp_finsts on the side I've explained most of the rationale in a new Note. I'd happily add a test for this, but the difference is only visible in run time, allocations remain more or less the same. FWIW running `generateModules` from #14693 with DEPTH=16, WIDTH=30 finishes in `23s` before, and `11s` after. Test Plan: ./validate Reviewers: simonpj, simonmar, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14693 Differential Revision: https://phabricator.haskell.org/D4369 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 18:01:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 18:01:08 -0000 Subject: [GHC] #14693: Computing imp_finst can take up significant amount of time In-Reply-To: <046.a9caa20b4ad6e8f61c2910051e03ba80@haskell.org> References: <046.a9caa20b4ad6e8f61c2910051e03ba80@haskell.org> Message-ID: <061.42618122a740c295b4e90084b364af51@haskell.org> #14693: Computing imp_finst can take up significant amount of time -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D4369 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 19:21:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 19:21:07 -0000 Subject: [GHC] #14717: Hidden package hints no longer display In-Reply-To: <047.c46b47b6ebca0c950882fdcc6a0147c6@haskell.org> References: <047.c46b47b6ebca0c950882fdcc6a0147c6@haskell.org> Message-ID: <062.2ec1cd193485700155f96f787206b077@haskell.org> #14717: Hidden package hints no longer display -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4376 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 19:21:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 19:21:55 -0000 Subject: [GHC] #14717: Hidden package hints no longer display In-Reply-To: <047.c46b47b6ebca0c950882fdcc6a0147c6@haskell.org> References: <047.c46b47b6ebca0c950882fdcc6a0147c6@haskell.org> Message-ID: <062.4789e60f3b4715cb0687d683071134e6@haskell.org> #14717: Hidden package hints no longer display -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4376 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4c364402ad9edade698863a3684f395e737b9de2/ghc" 4c36440/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4c364402ad9edade698863a3684f395e737b9de2" Restore 'It is a member of hidden package' message. See comment in Packages for more details. Fixes #14717. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: snoyberg, taylorfausak, bgamari Reviewed By: snoyberg, taylorfausak, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14717 Differential Revision: https://phabricator.haskell.org/D4376 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 19:21:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 19:21:55 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.309c0fcbe9a447ddea91a23f40927fbf@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2987b041a3811b25bcee402ce6fdab80827dc90e/ghc" 2987b04/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2987b041a3811b25bcee402ce6fdab80827dc90e" Improve X86CodeGen's pprASCII. The original implementation generates a list of SDoc then concatenates them using `hcat`. For memory optimization, we can transform the given literal string into escaped string the construct SDoc directly. This optimization will decreate the memory allocation when there's big literal strings in haskell code, see Trac #14741. Signed-off-by: HE, Tao Reviewers: bgamari, mpickering, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14741 Differential Revision: https://phabricator.haskell.org/D4384 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 19:30:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 19:30:59 -0000 Subject: [GHC] #14767: Move Data.Functor.Contravariant into base Message-ID: <049.b50afcae0d7c6cf3237575f5b3450e51@haskell.org> #14767: Move Data.Functor.Contravariant into base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: base | 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 propose that `Data.Functor.Contravariant` be moved to `base`. This has been discussed on the mailing list in 2016 and 2017: - https://mail.haskell.org/pipermail/libraries/2016-December/027480.html - https://mail.haskell.org/pipermail/libraries/2017-September/028190.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 19:33:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 19:33:51 -0000 Subject: [GHC] #14767: Move Data.Functor.Contravariant into base In-Reply-To: <049.b50afcae0d7c6cf3237575f5b3450e51@haskell.org> References: <049.b50afcae0d7c6cf3237575f5b3450e51@haskell.org> Message-ID: <064.50add9e8625fde439ef7fbaf3148b1b2@haskell.org> #14767: Move Data.Functor.Contravariant into base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: base 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 andrewthad): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 19:55:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 19:55:53 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.c8d73ba7737c4737319d8506213e8404@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by donatello): Thank you for the fix, it looks promising - but I am not sure if the problem is completely solved. The profiling output says that total allocations were reduced from 4.7GB to 1.3GB, which is 3.5X improvement. However, the goal in my initial program was to embed ~100MB of static data in my program - whereas the bug demonstrates the problem with a 3MB embedded string. Is there any way I could get a built version of the ghc master for 64-bit x86 Linux (from a CI server perhaps), so I could try it out myself? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 19:59:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 19:59:47 -0000 Subject: [GHC] #13362: GHC first generation of GC to be as large as largest cache size by default In-Reply-To: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> References: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> Message-ID: <060.bcef9ff4c24c1a441a1c45c78d2fc319@haskell.org> #13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: numa cache gc | newcomers 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 varosi): For nursery may be there is no such deal, but see a benchmark made on a small raytracer (https://bitbucket.org/varosi/cgraytrace/overview) that do a lot of allocations on two different machines: https://docs.google.com/spreadsheets/d/1dnhQTrm_EgKab3IJQAC4Rw1IJOfOcryJ56W0z9aeo0k/edit?usp=sharing There is a clear difference for different GC sizes. As sizes grow beyond times of needed memory GC is almost not used and then the benefit of larger GC is brought back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 20:00:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 20:00:46 -0000 Subject: [GHC] #12685: getNumProcessors semantics dont match documentation In-Reply-To: <043.7166490946f73da79c709fdf98d75140@haskell.org> References: <043.7166490946f73da79c709fdf98d75140@haskell.org> Message-ID: <058.14d19c1676d9028a82883a23c63eceee@haskell.org> #12685: getNumProcessors semantics dont match documentation -------------------------------------+------------------------------------- Reporter: Llgn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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 duog): I think this function returns the number of logical cores, including hyper-threading. It would be good to specify this in the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 20:45:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 20:45:51 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case Message-ID: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a program, which works as expected in GHC 8.4.1-alpha3 with `-O0`, but changes it behaviour with `-O1`. {{{#!hs {-# LANGUAGE MagicHash #-} import qualified Data.Vector.Unboxed as U import GHC.Exts vec :: U.Vector Moebius vec = U.singleton Moebius0 main :: IO () main = print $ U.head vec == U.head vec data Moebius = Moebius0 | Moebius1 | Moebius2 deriving (Eq) fromMoebius :: Moebius -> Int fromMoebius Moebius0 = 0 fromMoebius Moebius1 = 1 fromMoebius Moebius2 = 2 toMoebius :: Int -> Moebius toMoebius (I# i#) = tagToEnum# i# {- ...unboxed vector instances, see file attached... -} }}} It is expected that this program will print `True`. However, when compiled with `-O1` it prints `False`. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.0.20180204 $ ghc -O0 Sieve.hs && ./Sieve [1 of 1] Compiling Main ( Sieve.hs, Sieve.o ) [Optimisation flags changed] Linking Sieve ... True $ ghc -O1 Sieve.hs && ./Sieve [1 of 1] Compiling Main ( Sieve.hs, Sieve.o ) [Optimisation flags changed] Linking Sieve ... False }}} It reproduces on OS X and Ubuntu, but worked fine in GHC 8.2. I looked into generated Core and found a suspicious function, having two `__DEFAULT` cases with different bodies. {{{#!hs main2 :: String main2 = case vec `cast` of { Vector ipv_sb7L ipv1_sb7M ipv2_sb7N -> case <# 0# ipv1_sb7M of { __DEFAULT -> case main3 ipv1_sb7M of wild_00 { }; 1# -> case indexIntArray# ipv2_sb7N ipv_sb7L of { __DEFAULT -> $fShowBool4; __DEFAULT -> $fShowBool2; 1# -> $fShowBool2; 2# -> $fShowBool2 } } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 20:46:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 20:46:15 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case In-Reply-To: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> References: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> Message-ID: <062.c1878717b4bc8fc5d7f69ebaba70bb0a@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Bodigrim): * Attachment "Sieve.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 21:17:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 21:17:26 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.85e0d33990feaba85447befa86ae81cd@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I'm not sure embedding a 100mb file into a program is really supported. What are you doing after you embed this file? Can't you just read the file when the program runs? Maybe the easiest way would be to install HEAD from hvr's ppa - https://launchpad.net/~hvr/+archive/ubuntu/ghc. It is also easy with nixos if you are using that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 21:53:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 21:53:50 -0000 Subject: [GHC] #14767: Move Data.Functor.Contravariant into base In-Reply-To: <049.b50afcae0d7c6cf3237575f5b3450e51@haskell.org> References: <049.b50afcae0d7c6cf3237575f5b3450e51@haskell.org> Message-ID: <064.b89c4b37c396a8c9ab71665fd7ed6eff@haskell.org> #14767: Move Data.Functor.Contravariant into base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: base Operating System: 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): Sounds good to me—the idea seemed popular on the libraries mailing list. Care to offer a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 21:58:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 21:58:24 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe Message-ID: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #481 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `ghc --make` aims to make compilation behave correctly and produce up-to- date, no matter whether it completes or is interrupted (e.g. with Ctrl+C) and later resumed At no point should interrupting a build and running it again produce "less correct" outputs than running it to the end; specifically interrupting shouldn't result in necessary build steps to be "forgotten". However, this seems to be the case with the `[TH]` check introduced in #481. Minimal test case with 3 files: https://github.com/nh2/th-recomp-test Good behaviour when running without interrupting: {{{ % touch A.hs && ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [TH] [3 of 3] Compiling Main ( Main.hs, Main.o ) [TH] Linking Main ... }}} Bad behaviour when interrupting and running again: {{{ % touch A.hs; timeout 0.1 ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs; ~/.stack/programs/x86_64-linux/ghc-8.0.1/bin/ghc --make Main.hs [1 of 3] Compiling A ( A.hs, A.o ) [2 of 3] Compiling B ( B.hs, B.o ) [TH] Linking Main ... }}} As you can see, when interrupting, the step `Compiling Main ( Main.hs, Main.o ) [TH]` went missing. This suggests to me that either: * the `[TH]`s are unnecessary in the first place (unlikely and I buy into the reason explained by #481 that changed values may be picked up by TH in higher-level modules) * the resumed `ghc --make` invocation may potentially produce wrong / not- up-to-date outputs (most likely) * re-running somehow retrieves the information that in fact recompiling `Main` is not necessary for a correct build (if this is the case, then I'd really like to know how that works and we should document it, likely also try to use that way to avoid recompiling `Main` in the uninterrupted run) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 21:59:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 21:59:31 -0000 Subject: [GHC] #481: Recompilation check fails for TH In-Reply-To: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> References: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> Message-ID: <061.f4278eca299f0af5e784d9c3349153dc@haskell.org> #481: Recompilation check fails for TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: TH_recompile Blocked By: | Blocking: Related Tickets: #14769 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * related: => #14769 Comment: I believe I have found a bug with the current implementation of the `[TH]`/`RecompBecause "TH"` check: It doesn't work when the build is interrupted. See #14769 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 22:11:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 22:11:06 -0000 Subject: [GHC] #14767: Move Data.Functor.Contravariant into base In-Reply-To: <049.b50afcae0d7c6cf3237575f5b3450e51@haskell.org> References: <049.b50afcae0d7c6cf3237575f5b3450e51@haskell.org> Message-ID: <064.b9ef4aae23e61709cc88a9a09e6377e5@haskell.org> #14767: Move Data.Functor.Contravariant into base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: base Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I'll get a patch up soon. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 22:29:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 22:29:44 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case In-Reply-To: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> References: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> Message-ID: <062.6e13522313eac19b427ca292d8665d1a@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest Comment: Thank you for reporting this. Indeed this is an interesting case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 23:06:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 23:06:56 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case In-Reply-To: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> References: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> Message-ID: <062.7ce5e16da363c8cff57eca1e45fec4c4@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"da4681303892804ea08b60bfd47cbb82ca8e6589/ghc" da468130/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="da4681303892804ea08b60bfd47cbb82ca8e6589" testsuite: Add test for #14768 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 6 23:14:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Feb 2018 23:14:27 -0000 Subject: [GHC] #14770: Allow static pointer expressions to have static pointer free variables Message-ID: <048.bed690b6ed6632ceb9361aef80b57ffb@haskell.org> #14770: Allow static pointer expressions to have static pointer free variables -------------------------------------+------------------------------------- Reporter: TheKing01 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Static pointer expressions can not have free variables. For example: {{{#!hs addPointers :: StaticPtr Int -> StaticPtr Int -> StaticPtr Int addPointers x y = static (deRefStaticPtr x + deRefStaticPtr y) }}} would be invalid, since `x` and `y` are free variables. My proposal would be to make this code sample valid. In particular, my proposal is to allow free variables in `static` expressions if the free variables of the type `StaticPtr a` for some type `a`. Let's say that `m` `n` are Static pointers to integers. The serialized form would of `addPointers m n` would be: A pointer to the code `deRefStaticPtr x + deRefStaticPtr y` The serialized form of `m`, associated with `x`. The serialized form of `n`, associated with `y`. When this is sent over the wire and dereferenced, the other machine would Find `m` and `n`'s pointers Find the code `deRefStaticPtr x + deRefStaticPtr y` Evaluate `deRefStaticPtr x + deRefStaticPtr y`, substituting `m`'s value for `x`, and `n`'s value for y. The reason this feature would be useful is would let the user modify and combine static pointers. You might ask "why not let the user create a GADT to do that (like in https://hackage.haskell.org/package/distributed-static-0.3.8/docs/Control- Distributed-Static.html#t:Static)?" The reason is that then it won't fuse (with recreating every fusion rule for that GADT). For example, if `m` is `static 7` and `n` is `static 3`, then `addPointers m n` can fuse to `static 11`. This is more important then it seems. For example, say you have `composePointers :: StaticPtr (a -> b) -> StaticPtr (b -> c) -> StaticPtr (a -> c)`, and you compose a bunch of pointers. With the GADTS, every `composePointers` would be its own node, but with GHC support, it would probably fuse. In general, dealing with a GADT requires a lot of "glue code" that can be eliminated with GHC support. I'm not sure if this proposal makes a performance difference (it probably makes it more efficient), but it would make code more elegant, cutting out all the glue code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 00:14:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 00:14:44 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case In-Reply-To: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> References: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> Message-ID: <062.71267798aa5078ba145b2276958c6588@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could not resist looking at this. I know what is happening. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 00:27:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 00:27:09 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case In-Reply-To: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> References: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> Message-ID: <062.8843f6dc7dfff667b24a2a5c14126a33@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Bug.hs" added. Version without dependencies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 00:28:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 00:28:27 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case In-Reply-To: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> References: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> Message-ID: <062.0e5b367d18f0439a796ef9d0015d3417@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): In case it's useful, I've attached a variation of `Sieve.hs` without a `vector` dependency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 00:47:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 00:47:30 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.aed78e40fb2fd2274ee87c5bdea3477e@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by donatello): I want to embed some static assets used by my program (which is also built as a static binary), into the binary itself to enable easy distribution/deployment - simply download and execute a single (binary) file. It is quite common in some other languages (e.g. https://github.com/elazarl/go-bindata-assetfs#readme). Due to this issue, I am currently reading the static assets in at start, but I would prefer to build all the assets into the binary itself. The PPA does not seem to have the most recent commits, so I will for it to be updated before I try this out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 01:27:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 01:27:04 -0000 Subject: [GHC] #14771: TypeError reported too eagerly Message-ID: <045.a919a2a0174bec27cc26967509347872@haskell.org> #14771: TypeError reported too eagerly -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (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: -------------------------------------+------------------------------------- Consider the following example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} import GHC.TypeLits import Data.Proxy data DUMMY type family If c t e where If True t e = t If False t e = e type family F (n :: Nat) where --F n = If (n <=? 8) Int (TypeError (Text "ERROR")) F n = If (n <=? 8) Int DUMMY test :: (F n ~ Word) => Proxy n -> Int test _ = 2 test2 :: Proxy (n :: Nat) -> Int test2 p = test p main :: IO () main = do print (test2 (Proxy :: Proxy 5)) }}} The type error is useful: {{{ Bug.hs:26:11: error: • Couldn't match type ‘If (n <=? 8) Int DUMMY’ with ‘Word’ arising from a use of ‘test’ • In the expression: test p In an equation for ‘test2’: test2 p = test p • Relevant bindings include p :: Proxy n (bound at Bug.hs:26:7) test2 :: Proxy n -> Int (bound at Bug.hs:26:1) | 26 | test2 p = test p | ^^^^^^ }}} Now if we use the commented implementation of `F` (using `TypeError`), with GHC 8.2.2 and 8.0.2 we get: {{{ Bug.hs:26:11: error: • ERROR • In the expression: test p In an equation for ‘test2’: test2 p = test p | 26 | test2 p = test p | ^^^^^^ }}} While with GHC 8.0.1 we get: {{{ /home/hsyl20/tmp/Bug.hs:29:11: error: • Couldn't match type ‘If (n <=? 8) Int (TypeError ...)’ with ‘Word’ arising from a use of ‘test’ • In the expression: test p In an equation for ‘test2’: test2 p = test p }}} 1) Could we restore the behavior of GHC 8.0.1? 2) In my real code, when I use DUMMY I get: {{{ • Couldn't match type ‘If (n <=? 8) Int8 DUMMY’ with ‘Word’ Expected type: Word Actual type: F n }}} If we could get the same report (mentioning the "Actual type") when we use `TypeError` that would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 01:36:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 01:36:45 -0000 Subject: [GHC] #14772: Keep Role Annotations in the renamed syntax tree Message-ID: <044.7e453a1d1bceeb2c76d9b76df727bedc@haskell.org> #14772: Keep Role Annotations in the renamed syntax tree -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (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: -------------------------------------+------------------------------------- Currently role annotations are present in the parsed representation, but missing from the renamed version of the syntax tree. GHC should keep them instead. I found no evidence that this would be intended, we even have `rnRoleAnnots` that should return the renamed annotations. Keeping role annotations would help tooling to be consistent. For example, renaming the datatype should also rename its occurrence in the role annotation. Minimal example: A.hs {{{#!hs module A where import B data A x = A B }}} B.hs {{{#!hs module B where import {-# SOURCE #-} A data B = B (A ()) }}} A.hs-boot {{{#!hs {-# LANGUAGE RoleAnnotations #-} module A where type role A phantom -- the role annotation is needed here data A x }}} When inspecting the representation using the GHC API, the role is present in the parsed representation: {{{ module A where -- Parsed module type role A phantom data A x }}} But missing from the renamed one: {{{ (data A x, [import (implicit) Prelude], Nothing, Nothing) -- RenamedSource }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 02:07:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 02:07:48 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.5757dbe6e45a0d24d8deaff502d4a9ba@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * Attachment "objdump-headers-1.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 02:08:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 02:08:01 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.119f43c0d3670ca6d02315c19b8ced9b@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * Attachment "objdump-headers-1.2.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 02:08:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 02:08:30 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.81b7c9eb0c63a6fdae1d23525affbc9b@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * Attachment "objdump-headers-2.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 02:14:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 02:14:04 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.3c48f3cad5cdc3476ab7d8fc06e72d47@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I have attached some files, `objdump-headers-1.txt` and `objdump- headers-1.txt` which are the outputs of `objdump --all-headers Example.o` as produced by `ghc --make -j1` of a project of mine. Have a look at them in a diff viewer. At the top you will find probably what was talked about before: Uniques making it into symbol names, like `cZoQ_info` vs `cQJU_info`. But further down you see {{{ 0000000000002f10 R_X86_64_PC32 .data.rel.ro+0x00000000000000e8 }}} vs {{{ 0000000000002f10 R_X86_64_PC32 .data.rel.ro+0x00000000000000f0 }}} which is the result of some values in the `RELOCATION RECORDS FOR [.data.rel.ro]` having their positions swapped: {{{ 0000000000000100 R_X86_64_64 monozmtraversablezm1zi0zi2zi1zm4aNtRX1lKHJF1rNRp4LmtV_DataziMonoTraversable_zdfMonoFoldableZMZN_closure 0000000000000108 R_X86_64_64 monozmtraversablezm1zi0zi2zi1zm4aNtRX1lKHJF1rNRp4LmtV_DataziMonoTraversableziUnprefixed_any_closure }}} vs {{{ 0000000000000100 R_X86_64_64 monozmtraversablezm1zi0zi2zi1zm4aNtRX1lKHJF1rNRp4LmtV_DataziMonoTraversableziUnprefixed_any_closure 0000000000000108 R_X86_64_64 monozmtraversablezm1zi0zi2zi1zm4aNtRX1lKHJF1rNRp4LmtV_DataziMonoTraversable_zdfMonoFoldableZMZN_closure }}} These are the same things, they have exactly the same symbol names, just their order swapped. How might this happen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 02:14:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 02:14:15 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.f783238cc89094ab699a0e6ef13ee0bb@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 02:20:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 02:20:14 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.85a1e40b6b3453a95790429e84697727@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): > It's not an entirely trivial task. We use uniques quite often to name symbols in code produced by the native codegen. Fixing this without compromising compiler performance is rather tricky. @bgamari Question: Why cannot the uniques be predetermined by a seed that's dependent on the module name? My understanding so far is this: We need an infinite stream of unused strings to generate symbols. Parallel compilation with `-j` and "partial" compilation of the projects (resumes, incremental compilation), means some number or pseudorandom generator has a different initial state when we come by the file next time. So couldn't we initialise the seed of that pseudorandom generator as `hash(module name)`, so that each time a module is compiled, it always generates the same uniques in the same order (as within a module there is no parallel compilation)? And when a module name changes, we have to recompile anyway and it's probably OK if the object code changes when that happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 02:20:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 02:20:38 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.9526904d6bac40e908f4fd82476c9907@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: niteria (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 02:36:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 02:36:25 -0000 Subject: [GHC] #12262: Binary output is not deterministic In-Reply-To: <046.27bc9dd81d23b6e2bff2e834a716a9f5@haskell.org> References: <046.27bc9dd81d23b6e2bff2e834a716a9f5@haskell.org> Message-ID: <061.c17bcd32a321039188693460b731a80b@haskell.org> #12262: Binary output is not deterministic -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 4012 | Blocking: Related Tickets: #4012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I think we should close this as a duplicate in favour of #12935. This ticket is older, but the other one already has more discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 02:37:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 02:37:42 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.6e01082bea31f33a30232509550d3423@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 4012 | Blocking: Related Tickets: #12262 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * blockedby: => 4012 * related: => #12262 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 02:38:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 02:38:03 -0000 Subject: [GHC] #12262: Binary output is not deterministic In-Reply-To: <046.27bc9dd81d23b6e2bff2e834a716a9f5@haskell.org> References: <046.27bc9dd81d23b6e2bff2e834a716a9f5@haskell.org> Message-ID: <061.17407f7a7f81c64a7e8658e8f9ce8464@haskell.org> #12262: Binary output is not deterministic -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 4012 | Blocking: Related Tickets: #4012, #12935 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) * related: #4012 => #4012, #12935 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 02:55:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 02:55:48 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.86acb2f35348a5cc42d08b3ffe979c37@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #12262 => * blockedby: 4012 => Comment: > So couldn't we initialise the seed of that pseudorandom generator as hash(module name), so that each time a module is compiled, it always generates the same uniques in the same order Yes, I believe we could. The real issue is that (I suspect) this will be a rather major surgery of the backend. We produce symbol names and labels in many places and often we only have access to a unique supply. Threading the necessary state around will likely be a non-trivial exercise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 03:16:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 03:16:07 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.f72bcf5a43309cac54cdfdc77c2f8b57@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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 dfeuer): I can also reproduce this using ghc-8.3 as the stage 0 compiler. Oh well. I'll keep digging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 04:26:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 04:26:44 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.82b6796d0d5caeee2e9864e0d1dd0814@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Embedding ~100MB static data in haskell code may consume around 40GB memory. Currently in TH the `StringPrimL` is built with `[Word8]` rather than ByteString. Unpacking ~100MB bytestring to `[Word8]` and escaping it already consume GBs of memory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 05:05:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 05:05:28 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.d77097fd2a254f6de0f7f9b536df7318@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | 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:D3723 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I have no objection to filling in a default definition until it gets removed. That would make it possible for folks to eventually remove the definitions from their code and stay 3-release friendly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 05:09:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 05:09:27 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.3500609d9231d1a1e04b13702b93f0f8@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: dfeuer Type: feature request | Status: patch Priority: high | Milestone: 8.6.1 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:D3723 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: ⊥ => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 07:47:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 07:47:28 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall Message-ID: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following partial function will pass {{{-Wall}}} {{{#!haskell -- program 1 {-# LANGUAGE MultiWayIf #-} foo :: Bool -> Int foo b = if | b -> 23 }}} While the following two alternatives will not: {{{#!haskell -- program 2 foo :: Bool -> Int foo b | b = 23 }}} {{{#!haskell -- program 3 foo :: Bool -> Int foo b = case () of () | b -> 23 }}} Note that the GHC User's Guide states that "program 1" and "program 3" are equivalent. 1. Is this a bug or by design? 2. I guess at the very least we would want to update the User's Guide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 08:32:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 08:32:17 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.b14b9d7075ee5ed562724f64cab9cb82@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): All the existing machinery for literals is oriented for relatively short, human-readable literal strings. It's unsurprising that it chokes on 100Mb. But it seems like an absolutely legitimate request to me. Happy needs this too, in the form of its parsing tables; albeit they aren't so big. There's even a wiki page about it: [wiki:StaticData] spun out of #5218. This must be do-able, but it would need someone to lead on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 08:57:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 08:57:58 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case In-Reply-To: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> References: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> Message-ID: <062.874d1096133735512a53cf78b2eef926@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In the test case there is no need to run it. Core Lint picks up the error immediately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 09:00:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 09:00:06 -0000 Subject: [GHC] #13994: STG lint failure on master In-Reply-To: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> References: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> Message-ID: <061.9f20f292ec50365da2bba234b2b286a8@haskell.org> #13994: STG lint failure on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint Operating System: 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): I get a different error when I use your `build.mk` with latest master branch: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.5 -hide-all- packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI -optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.11.0.0 -package-id binary-0.8.5.1 -package-id bytestring-0.10.8.2 -package-id containers-0.5.11.0 -package- id deepseq-1.4.3.0 -package-id directory-1.3.1.5 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.5 -package-id ghc-boot-th-8.5 -package-id ghci-8.5 -package-id hpc-0.6.0.3 -package-id process-1.6.2.0 -package-id template-haskell-2.13.0.0 -package-id terminfo-0.4.1.1 -package-id time-1.8.0.2 -package-id transformers-0.5.5.0 -package-id unix-2.7.2.2 -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -this- unit-id ghc -XHaskell2010 -XNoImplicitPrelude -optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing -O0 -DDEBUG -g3 -ddump- to-file -ddump-stg -dcore-lint -dstg-lint -dcmm-lint -Wcpp-undef -no-user- package-db -rtsopts -Wnoncanonical-monad-instances -odir compiler/stage2/build -hidir compiler/stage2/build -stubdir compiler/stage2/build -dynamic-too -c compiler/utils/FastString.hs -o compiler/stage2/build/FastString.o -dyno compiler/stage2/build/FastString.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.5.20180206 for x86_64-unknown-linux): kindPrimRep RuntimeRep typePrimRep ('IntRep :: RuntimeRep) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:346:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Interestingly if I remove `-dstg-lint` parameter it compiles fine. So it seems like there still is a problem with `StgLint`, but maybe a different one than the original error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 09:06:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 09:06:10 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.c4c37028ce405954bcdd6b0484b9f107@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 think it's a bug, or at least an inconsistency. Would someone like to fix it? I doubt it's difficult. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 09:50:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 09:50:30 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.7c5a131bd31055c3552638fc21f5f408@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good progress * Let's split the commits for Thing 2 and Thing 3; they are quite different. * We agreed in comment:62 not to do the subtle `SubCo` stuff for `NthCo`; that means some changes (simplifications). * I have not properly reviewed the `simplCast` changes, but they don't appear to follow the plan I suggest in comment:10. Richard can you comment on that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 09:51:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 09:51:12 -0000 Subject: [GHC] #14737: Improve performance of Simplify.simplCast In-Reply-To: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> References: <047.69092b5e7fccc6314d7cb05c5e8b2174@haskell.org> Message-ID: <062.c43b7e6d7bcee2b93340b82fc1940635@haskell.org> #14737: Improve performance of Simplify.simplCast -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11735 #14683 | Differential Rev(s): Phab:D4385 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Implemented in: ​https://phabricator.haskell.org/D4385 I'd much prefer a separate patch. (Not hard.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 09:56:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 09:56:00 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case In-Reply-To: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> References: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> Message-ID: <062.d2402159c845a494efa2b6544185a93c@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4aa98f4a3cb0c965c4df19af2f1ccc2c5483c3a5/ghc" 4aa98f4a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4aa98f4a3cb0c965c4df19af2f1ccc2c5483c3a5" Fix utterly bogus TagToEnum rule in caseRules In prelRules we had: tx_con_tte :: DynFlags -> AltCon -> AltCon tx_con_tte _ DEFAULT = DEFAULT tx_con_tte dflags (DataAlt dc) | tag == 0 = DEFAULT -- See Note [caseRules for tagToEnum] | otherwise = LitAlt (mkMachInt dflags (toInteger tag)) The tag==0 case is totally wrong, and led directly to Trac #14768. See "Beware" in Note [caseRules for tagToEnum] (in the patch). Easily fixed, though! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 09:57:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 09:57:29 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case In-Reply-To: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> References: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> Message-ID: <062.293426e25b3866d1d98041593dc57d03@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_run/T14768 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => simplCore/should_run/T14768 * status: new => merge Comment: I guess we should merge this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 09:58:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 09:58:01 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case In-Reply-To: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> References: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> Message-ID: <062.fd6038530c64b5e2ee47dbda9cd02927@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_run/T14768 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Many thanks to Bodigrim for finding this, with such a tractable test case! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 11:08:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 11:08:16 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.f4bfcc59cd503c0a3106dc3fc23b6761@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4384 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Replying to [comment:14 simonpj]: > There's even a wiki page about it: [wiki:StaticData] spun out of #5218. I have updated this/my proposal. Comments welcome! We should get Phab:D4217 merged to get started if we follow this plan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 11:28:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 11:28:52 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.a36e13fc5146bbe40120f131bfcff4bc@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: alpmestan Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): When work resumes after going back to the scheduler, we load the stack and jump to its top (`stg_enter_info`). This then leads us to execute a whoooooooole bunch of code. I saw many kinds of closure types along the way, among which a `Data.Data` related one (expected: we embed a `Data` dictionary in `AnnotationWrapper`), a ghci `BreakArray` related one, partial applications, `FUN_STATIC`, etc. The somewhat uninformative context in which the crash finally happens can be seen [https://gist.github.com/alpmestan/a029e46c9cb7beb6839c6ac6058a95f9#file- foo-asm-L1017 here], interleaved with my attempts to find out a bit of information about the addresses/closures/etc randomly in `rbx`, `rax`, printing the top of the stack, etc. I was honestly hoping that the context would be a little more informative. However, all hope is not lost. I'm going to use `rr` as suggested by Ben to record the run, and then I'll be able to go to the crash, look at the address we're trying to jump to, and use `reverse-cont` to see who wrote that address there. This however requires me to set up something else than VirtualBox as `rr` needs hardware performance counters that VirtualBox does not support. I got started with this today. In parallel, I might keep doing a few experiments in `gdb` in my existing (VirtualBox) VM. For instance, when looking at the `TcSplice` code yesterday, I saw a few `do` blocks with some important code (as far as annotation handling is concerned) that I haven't looked closely at yet. In particular, I'm not sure whether the code that produces `zonked_wrapped_expr'` could be the problem. I have a reason or two to believe that it's an interesting place to look at, like the fact that I did see some `Data.Data` related symbol _after_ `interpretBCO`, and these few lines of code are where we produce the `Data.Data` dictionary apparently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 11:40:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 11:40:38 -0000 Subject: [GHC] #14774: Recusive superclass epansion is over-keen Message-ID: <046.c42c4b3845e9d883ae47911eedc3134d@haskell.org> #14774: Recusive superclass epansion is over-keen -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this, with `RecursiveSuperClasses`: {{{ class C a => D a where cop :: a -> a class D a => C a where dop :: a -> a g :: C a => a -> Bool g x = g x f :: C a => a -> Bool f x = g x }}} When we compile this we get {{{ f = \ (@ a_aXf) ($dC_aXh :: C a_aXf) (eta_B1 :: a_aXf) -> g @ a_aXf (Foo.$p1D @ a_aXf (Foo.$p1C @ a_aXf $dC_aXh)) eta_B1 }}} Notice the ridiculous double superclass selection from `$dC_aXh`. It's not wrong, just stupid! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 12:16:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 12:16:28 -0000 Subject: [GHC] #14774: Recusive superclass epansion is over-keen In-Reply-To: <046.c42c4b3845e9d883ae47911eedc3134d@haskell.org> References: <046.c42c4b3845e9d883ae47911eedc3134d@haskell.org> Message-ID: <061.1aa59edec8dbe8f1663456132bce4f97@haskell.org> #14774: Recusive superclass epansion is over-keen -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"65069806ea3637882d584e785dcb9e650271e4b6/ghc" 65069806/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="65069806ea3637882d584e785dcb9e650271e4b6" Fix solveOneFromTheOther for RecursiveSuperclasses This patch fixes the redundant superclass expansion in Trac #14774. The main change is to fix TcInterac.solveOneFromTheOther, so that it does not prefer a work-item with a binding if that binding transitively depends on the inert item we are comparing it with. Explained in Note [Replacement vs keeping] in TcInert, esp item (c) of the "Constraints coming from the same level" part. To make this work I refactored out a new function TcEvidence.findNeededEvVars, which was previously buried inside TcSimplify.neededEvVars. I added quite a few more comments and signposts about superclass expansion. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 12:18:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 12:18:02 -0000 Subject: [GHC] #14774: Recusive superclass epansion is over-keen In-Reply-To: <046.c42c4b3845e9d883ae47911eedc3134d@haskell.org> References: <046.c42c4b3845e9d883ae47911eedc3134d@haskell.org> Message-ID: <061.bbbfd20f22d945f2a5ce8d532ac21608@haskell.org> #14774: Recusive superclass epansion is over-keen -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14774 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T14774 * resolution: => fixed Comment: No need to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 12:20:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 12:20:50 -0000 Subject: [GHC] #14771: TypeError reported too eagerly In-Reply-To: <045.a919a2a0174bec27cc26967509347872@haskell.org> References: <045.a919a2a0174bec27cc26967509347872@haskell.org> Message-ID: <060.d793ac518bb602a336bdc9f270c4763f@haskell.org> #14771: TypeError reported too eagerly -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 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: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: diatchki (added) Comment: Iavor, ideas? `TypeError` is your baby -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 12:21:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 12:21:22 -0000 Subject: [GHC] #14771: TypeError reported too eagerly In-Reply-To: <045.a919a2a0174bec27cc26967509347872@haskell.org> References: <045.a919a2a0174bec27cc26967509347872@haskell.org> Message-ID: <060.93276d2cacf63c1a78601f07972d83ff@haskell.org> #14771: TypeError reported too eagerly -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | CustomTypeErrors 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: => CustomTypeErrors -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 12:24:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 12:24:30 -0000 Subject: [GHC] #13994: STG lint failure on master In-Reply-To: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> References: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> Message-ID: <061.ff7ced0fb637ab62184a312c9662ca1e@haskell.org> #13994: STG lint failure on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4396 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: => Phab:D4396 Comment: StgLint is still broken in other ways but I fixed the problem mentioned in comment:3 in Phab:D4396. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 12:28:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 12:28:08 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.a4247ccd7f0a6b0a72b5305d960ee12e@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): @nh: What about collisions? Uniques are 64 bits on 64 bit systems. 8 bits are taken for the tag, that leaves us with 56 bits. You can expect collisions after `2^26` uniques are allocated. That's `67108864`. It's a pretty small number. We've definitely seen cases of running out of 24 bits for larger projects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 12:29:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 12:29:10 -0000 Subject: [GHC] #12262: Binary output is not deterministic In-Reply-To: <046.27bc9dd81d23b6e2bff2e834a716a9f5@haskell.org> References: <046.27bc9dd81d23b6e2bff2e834a716a9f5@haskell.org> Message-ID: <061.00958eb8ddbb77f5abaf1e0033158840@haskell.org> #12262: Binary output is not deterministic -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 4012 | Blocking: Related Tickets: #4012, #12935 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * status: new => closed * resolution: => duplicate Comment: Fine by me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 12:40:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 12:40:18 -0000 Subject: [GHC] #14775: GHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file Message-ID: <042.c2e6771556eb83c8c227872bff540244@haskell.org> #14775: GHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm getting the following error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file: `Foo.cabal`: {{{ name: Foo version: 0.1.0.0 license: OtherLicense build-type: Custom cabal-version: >=1.10 library exposed-modules: Foo build-depends: base default-language: Haskell2010 }}} `Foo.hs`: {{{#!hs module Foo where foo :: Int -> Int foo n = n }}} `Setup.hs`: {{{#!hs import Distribution.Simple main = defaultMain }}} The error: {{{ $ cabal install Failed to install Foo-0.1.0.0 cabal: Error: some packages failed to install: Foo-0.1.0.0-33ReQaKfqaD7MoDL7J5kFM failed during the final install step. The exception was: dieVerbatim: user error (cabal: Couldn't parse the output of 'setup register --gen-pkg-config':NoParse "license" 5 ) }}} `cabal-install` version: {{{ $ cabal --version cabal-install version 2.0.0.1 compiled using version 2.0.1.0 of the Cabal library }}} If I change the `license` field ''or'' the `build` field, the error disappeared. I didn't get the above error using GHC 8.4.1-alpha2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 13:05:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 13:05:43 -0000 Subject: [GHC] #13994: STG lint failure on master In-Reply-To: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> References: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> Message-ID: <061.8c66575215d82d75167d2c72816f5c7c@haskell.org> #13994: STG lint failure on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4396 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): After Phab:D4396 it's failing in `GHC.Integer.Type`. This time the problem is we have in scrutinee position an unboxed tuple (pair) with `State#` as second argument, but binder becomes `Unit#` after unarise becuase `State#` has no representation in runtime. Error message: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.5.20180207 for x86_64-unknown-linux): ASSERT failed! dataConInstArgTys Unit# [k0_10, a_11] ['TupleRep '[], 'LiftedRep, State# s_a2Hq, a_a2Hr] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1206:5 in ghc:Outputable assertPprPanic, called at compiler/basicTypes/DataCon.hs:1255:76 in ghc:DataCon Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I look into this in more detail later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 15:34:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 15:34:38 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.8094f4a299c0b59170bdf76f5bf0204f@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I know changing `NthCo` caching is outstanding. For the `simplCast` changes: you're right -- I ignored your suggestions opting for something simpler. In HEAD, `pushTyCoArg` (along with friends) goes to some trouble to create a type-correct `Refl` coercion. But this coercion soon ends up being used in a cast, where `Refl`s are simply discarded. So all that work in building the coercion is wasted. My change is to return `Maybe Coercion`, preferring `Nothing` over `Just (Refl ...)`. This avoids the inefficient one-variable substitution that we were worrying about. It should be a clear win; we're doing strictly less work. The small complication is that there are these `Maybe`s floating about, but I think it's worth it. I'm hoping the comments on the `push` functions are clear enough, but perhaps I didn't include any information on ''why'' `Maybe Coercion` is better than `Coercion` here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 15:43:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 15:43:40 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.84ae0a2ce417b56ac1a363c97f13148b@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK: once we have a separate Phab for the `simplCast` change, I'll review it. Ping me, Tobias! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 17:16:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 17:16:13 -0000 Subject: [GHC] #14775: GHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file In-Reply-To: <042.c2e6771556eb83c8c227872bff540244@haskell.org> References: <042.c2e6771556eb83c8c227872bff540244@haskell.org> Message-ID: <057.1b47702f3ba7b2832da320cb032aab56@haskell.org> #14775: GHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): TL;DR, I don't think this a valid issue. To fix, use up-to-data `cabal- install`. We have to work on the error reporting though, as I mention below --- The failure is caused by unfortunately late (it missed by a few hours `alpha2`) change to `Cabal`, which affects how `ghc-pkg` stores licence field. It will be stored as SPDX expression in Cabal-2.2 / GHC-8.4 {{{ % ghc-pkg-8.4.1 dump | grep license | sort -u license: BSD-2-Clause license: BSD-3-Clause }}} Side note: As e.g. Agda is currently `OtherLicense`, please consider bumping to `cabal-version: 2.2` and using `MIT AND BSD-3-Clause` instead of opaque `OtherLicense`. That's one of motivation of using SPDX license expressions starting from cabal spec 2.2. --- There are two things wrong with the premise: - There aren't `custom-setup` & `setup-depends`. This causes `cabal- install` to apply implicit `Cabal < 2` bound. Then `Setup.hs` is built against `Cabal-1.24` which cannot know about GHC-8.4. We will fix that buy making old `Cabal` non-compilable against `base-4.11`. It's semantically incorrect (as they compile fine, they just don't know about GHC-8.4). - It was an oversight to allow `Cabal-1.24` to work with GHC-8.2. But that ship has sailed. - Similarly, as `cabal-install-2.0` uses `Cabal-2.0` (as version shows), that old `Cabal` lib version isn't compatible with GHC-8.4 - It's on the task list to make `Cabal` (and thus `cabal-install`) to refuse to work with GHCs it doesn't know about. We cannot predict the future. To illustrate, I try a dry build with package as reported: {{{ % /opt/cabal/2.0/bin/cabal new-build --dry Resolving dependencies... In order, the following would be built (use -v for more details): - Foo-0.1.0.0 (lib:Foo) (first run) % cabal-plan topo Foo-0.1.0.0 lib setup transformers-0.5.2.0 template-haskell-2.12.0.0 ghc-boot-th-8.2.2 old-time-1.1.0.3 old-locale-1.0.0.7 Cabal-1.24.2.0 <-- !!! process-1.4.3.0 pretty-1.1.3.3 directory-1.3.0.2 unix-2.7.2.2 time-1.8.0.2 filepath-1.4.1.2 binary-0.8.5.1 containers-0.5.10.2 bytestring-0.10.8.2 deepseq-1.4.3.0 array-0.5.2.0 base-4.10.1.0 integer-gmp-1.0.1.0 ghc-prim-0.5.1.1 rts-1.0 }}} Note: `Cabal-1.24.2.0` is built! If I actually try to build with GHC-8.4.1 alpha, I have to allow-newer {{{ % /opt/cabal/2.0/bin/cabal new-build -w ghc-8.4.1 --allow-newer='Cabal' --dry Resolving dependencies... In order, the following would be built (use -v for more details): - old-time-1.1.0.3 (lib) (requires build) - Foo-0.1.0.0 (lib:Foo) (first run) % cabal-plan topo Foo-0.1.0.0 lib setup template-haskell-2.13.0.0 ghc-boot-th-8.4.0.20180204 old-time-1.1.0.3 old-locale-1.0.0.7 Cabal-2.1.0.0 process-1.6.3.0 pretty-1.1.3.6 parsec-3.1.12 text-1.2.3.0 mtl-2.2.2 transformers-0.5.5.0 directory-1.3.1.5 unix-2.7.2.2 time-1.8.0.2 filepath-1.4.2 binary-0.8.5.1 containers-0.5.11.0 bytestring-0.10.8.2 deepseq-1.4.3.0 array-0.5.2.0 base-4.11.0.0 integer-gmp-1.0.1.0 ghc-prim-0.5.2.0 rts-1.0 }}} But still, there's old `Cabal` in `cabal-install-2.0` so build will fail, as reported. With `new-build` a bit differently: {{{ % /opt/cabal/2.0/bin/cabal new-build -w ghc-8.4.1 --allow-newer='Cabal' Resolving dependencies... In order, the following will be built (use -v for more details): - old-time-1.1.0.3 (lib) (requires build) - Foo-0.1.0.0 (lib:Foo) (first run) Configuring old-time-1.1.0.3 (lib)... Failed to build old-time-1.1.0.3. The failure occurred during the configure step. Build log ( /home/ogre/.cabal/logs/ghc-8.4.0.20180204/old- time-1.1.0.3-327228ceac90b6d4a229ac30aefee4aa0a193769fd1eeeece7e4a5f18f88fe98.log ): Configuring library for old-time-1.1.0.3.. cabal: failed to parse output of 'ghc-pkg dump' cabal: Failed to build old-time-1.1.0.3 (which is required by Foo-0.1.0.0). See the build log above for details. }}} However if we use `cabal-install-head` (which will become 2.2 soon-ish): {{{ % /opt/cabal/head/bin/cabal new-build -w ghc-8.4.1 --allow-newer='Cabal' }}} is ok. Also if we add proper `custom-setup` we won't need `--allow-newer`: {{{ % git diff diff --git a/Foo.cabal b/Foo.cabal index e4fb0c2..587ccd4 100644 --- a/Foo.cabal +++ b/Foo.cabal @@ -4,6 +4,9 @@ license: OtherLicense build-type: Custom cabal-version: >=1.10 +custom-setup + setup-depends: Cabal >= 1.10 && <2.3, base + library exposed-modules: Foo build-depends: base % /opt/cabal/head/bin/cabal new-build -w ghc-8.4.1 Build profile: -w ghc-8.4.0.20180204 -O1 In order, the following will be built (use -v for more details): - Foo-0.1.0.0 (lib:Foo) (first run) Preprocessing library for Foo-0.1.0.0.. Building library for Foo-0.1.0.0.. }}} And finally, using sandboxes and `cabal-install-head` build works too: {{{ % /opt/cabal/head/bin/cabal sandbox init Writing a default package environment file to /home/ogre/mess/issue-14475/cabal.sandbox.config Creating a new sandbox at /home/ogre/mess/issue-14475/.cabal-sandbox % /opt/cabal/head/bin/cabal install Resolving dependencies... Notice: installing into a sandbox located at /home/ogre/mess/issue-14475/.cabal-sandbox Configuring Foo-0.1.0.0... Building Foo-0.1.0.0... Installed Foo-0.1.0.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 17:21:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 17:21:12 -0000 Subject: [GHC] #14776: Add equality rule for `eqString` Message-ID: <049.437696e7d156821fd2d7478e285fedb5@haskell.org> #14776: Add equality rule for `eqString` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Locally I sometimes have to define a rule {{{ {-# RULES "eqStringEQ" forall x . eqString x x = True #-} }}} in order for "stuck" expressions to evaluate to `True` and for a case expression to be eliminated. Is there is a reason not to include this RULE directly in GHC.Base? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 17:38:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 17:38:57 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.a52d1eb6941b95477829994f457b8884@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7210 | Differential Rev(s): Phab:D4379 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * differential: => Phab:D4379 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 18:23:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 18:23:58 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.bbd0bd7e73722b86c894bbde21016c30@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7210 | Differential Rev(s): Phab:D4397 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D4379 => Phab:D4397 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 18:57:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 18:57:47 -0000 Subject: [GHC] #14771: TypeError reported too eagerly In-Reply-To: <045.a919a2a0174bec27cc26967509347872@haskell.org> References: <045.a919a2a0174bec27cc26967509347872@haskell.org> Message-ID: <060.23b133ecdc4734678343f81a902857ea@haskell.org> #14771: TypeError reported too eagerly -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | CustomTypeErrors 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 diatchki): For issue 1: the high-level question is what to do when we encounter an unevaluated type function with an error parameter (e.g., `T x (TypeError ...)`). Currently, we always report such errors, which is simple, but probably too eager in some cases. I guess a better solution, although more complex, would be too look at the available equations for `T` and see if evaluation is "stuck" due to the type error. If so, we report the custom error. Otherwise, we leave the expression as is. Note, however, that if we choose to not report the custom error we'd get a rather ugly "normal" error, as GHC would still print the description of the error (in combinator form) when it is rendering the type. For issue 2: I am not sure I understand 100% what the request is. Could you give a concrete example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 19:59:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 19:59:17 -0000 Subject: [GHC] #14766: Hole-y partial type signatures greatly slow down compile times In-Reply-To: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> References: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> Message-ID: <065.1492737cd885bf92299fe49ea1a5b42b@haskell.org> #14766: Hole-y partial type signatures greatly slow down compile times -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): How does this relate to #14683? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 20:56:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 20:56:35 -0000 Subject: [GHC] #14766: Hole-y partial type signatures greatly slow down compile times In-Reply-To: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> References: <050.a9358e22a41bd78b7f5f5546569385f5@haskell.org> Message-ID: <065.a25e61afb6a8ae79aed96bb34c61fab5@haskell.org> #14766: Hole-y partial type signatures greatly slow down compile times -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Replying to [comment:4 simonmar]: > How does this relate to #14683? The issues are AFAICT unrelated. The [https://github.com/simonmar/happy/issues/109 Happy issue] is really about this - it just so happens that while attempting to reproduce that issue, I stumbled on #14683 (and incorrectly assumed it too was partial-type- signature related). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 7 22:35:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Feb 2018 22:35:16 -0000 Subject: [GHC] #14776: Add equality rule for `eqString` In-Reply-To: <049.437696e7d156821fd2d7478e285fedb5@haskell.org> References: <049.437696e7d156821fd2d7478e285fedb5@haskell.org> Message-ID: <064.9789704120bd483d1dc4f4060a08786a@haskell.org> #14776: Add equality rule for `eqString` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 see no reason not to do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 00:11:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 00:11:23 -0000 Subject: [GHC] #14654: Nofib: Strip called without .exe extension resulting in errors. In-Reply-To: <047.c0797d46dbce4498940454ea926743bb@haskell.org> References: <047.c0797d46dbce4498940454ea926743bb@haskell.org> Message-ID: <062.b10d990217f58958691c3adf21a75fae@haskell.org> #14654: Nofib: Strip called without .exe extension resulting in errors. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: 8.2.2 suite | Keywords: nofib, Resolution: | windows Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4297 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"1364fe623f9216108a285a8804a27bdd8dfea3c4/nofib" 1364fe6/nofib]: {{{ #!CommitTicketReference repository="nofib" revision="1364fe623f9216108a285a8804a27bdd8dfea3c4" Recognize shells reporting as MINGW under windows. Summary: My msys instance at least reports MINGW instead of MSYS for uname. This commit adjusts the regex to match either one. Without this some errors occur because of missing .exe extensions in file names. This fixes #14654 Test Plan: make Reviewers: O26 nofib, Phyx, bgamari Reviewed By: Phyx, bgamari Subscribers: bgamari, Phyx GHC Trac Issues: #14654 Differential Revision: https://phabricator.haskell.org/D4297 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 01:12:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 01:12:28 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.a449e42554111ec3830b1f97de2a4a7b@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7210 | Differential Rev(s): Phab:D4397 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Replying to [comment:10 RyanGlScott]: Thanks for correcting me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 02:43:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 02:43:51 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.f1a1f66cb455ece2d36b11357aea8c49@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings 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: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 03:07:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 03:07:37 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.58a173934fcbf4e7f4b84bf263a96717@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: 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): Sigh. I don't see an easy way to fix this. The issue is that the entry- point into the pattern match coverage checker, `checkMatches`, requires a list of `LPat`s as its arguments. However, the AST for multi-way-`if` (`HsMultiIf`) has `GRHS`es, not `LPat`s. That's the same reason why this program doesn't emit any warnings under `-Wall`: {{{#!hs b :: Bool Just b | False = Nothing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 04:18:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 04:18:01 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.46b3bd6f0bf1df05d0c214bf104160c0@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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 dfeuer): I can cut down `GHCi.UI.Tags` and still get a similar core lint error. As I cut it down, the mismatched types shifted around a bit; unfortunately I didn't capture the intermediate steps, so I can't show them. This version is cut down about as far as I could cut it: {{{#!hs module GHCi.UI.Tags ( createTagsFile ) where import GHC import GHCi.UI.Monad data TagsKind data TagInfo createTagsFile :: TagsKind -> FilePath -> GHCi () createTagsFile _tagskind _tagsFile = do _graph <- GHC.getModuleGraph mapM_ (listModuleTags . GHC.ms_mod) $ [undefined] {-# NOINLINE listModuleTags #-} listModuleTags :: GHC.Module -> GHCi [TagInfo] listModuleTags m = let {-# NOINLINE names #-} names = [] localNames = filter ((m ==) . nameModule) names in mapM GHC.lookupName localNames >> return [] }}} Lots of the little bits remaining seem to be necessary: the `filter`, the `GHC.getModuleGraph`, the `mapM` in `listModuleTags` rather than `mapM_`. I'll keep digging now that I've cut it down, but I figured I should record this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 04:27:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 04:27:46 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.50cd834c9e0e4c64fc3c3e4d2081c668@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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 dfeuer): Actually, the `GHC.getModuleGraph` is ''not'' necessary. I can replace that line by {{{#!hs _graph <- return () }}} but ''not'' by {{{#!hs return () }}} That's subtle.... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 06:41:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 06:41:32 -0000 Subject: [GHC] #14777: panic Message-ID: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> #14777: panic -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The error message I got from GHC was: {{{ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): idInfo t_XG0J Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} How was it triggerred (in short): There's function definition, `f x = undefined`. If I change it to `f x = __impossible "Oops!"`, ghc crashes. The definition of `__impossible` is simply `__impossible s = error $ s ++ "some text"`. The code can be found here: https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Desugar.hs#L482 and https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Compiler.hs#L30 It seems that this bug is not limited to 8.2.2; it also happened in 8.2.1. I'm happy to provide more information, if someone can advice me what is needed. I'll also try to shrink it to a small test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 06:42:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 06:42:50 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` (was: panic) In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.20c31527cbb3be86248c7d6aa9594cda@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by zilinc: Old description: > The error message I got from GHC was: > > {{{ > : error: > ghc: panic! (the 'impossible' happened) > (GHC version 8.2.2 for x86_64-unknown-linux): > idInfo > t_XG0J > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler/utils/Outputable.hs:1133:58 in ghc:Outputable > callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in > ghc:Outputable > pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > How was it triggerred (in short): > There's function definition, `f x = undefined`. If I change it to `f x = > __impossible "Oops!"`, ghc crashes. The definition of `__impossible` > is simply `__impossible s = error $ s ++ "some text"`. > > The code can be found here: > https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Desugar.hs#L482 > and > https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Compiler.hs#L30 > > It seems that this bug is not limited to 8.2.2; it also happened in > 8.2.1. > > I'm happy to provide more information, if someone can advice me what is > needed. I'll also try to shrink it to a small test case. New description: The error message I got from GHC was: {{{ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): idInfo t_XG0J Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} How was it triggerred (in short): There's function definition, `f x = undefined`. If I change it to `f x = __impossible "Oops!"`, ghc crashes. If I change it to `f x = error "Oops!", it's OK. `The definition of `__impossible` is simply `__impossible s = error $ s ++ "some text"`. The code can be found here: https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Desugar.hs#L482 and https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Compiler.hs#L30 It seems that this bug is not limited to 8.2.2; it also happened in 8.2.1. I'm happy to provide more information, if someone can advice me what is needed. I'll also try to shrink it to a small test case. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 06:43:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 06:43:47 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.244ac988d67f484b56220c2cfaeffa4d@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by zilinc: Old description: > The error message I got from GHC was: > > {{{ > : error: > ghc: panic! (the 'impossible' happened) > (GHC version 8.2.2 for x86_64-unknown-linux): > idInfo > t_XG0J > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler/utils/Outputable.hs:1133:58 in ghc:Outputable > callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in > ghc:Outputable > pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > How was it triggerred (in short): > There's function definition, `f x = undefined`. If I change it to `f x = > __impossible "Oops!"`, ghc crashes. If I change it to `f x = error > "Oops!", it's OK. `The definition of `__impossible` > is simply `__impossible s = error $ s ++ "some text"`. > > The code can be found here: > https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Desugar.hs#L482 > and > https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Compiler.hs#L30 > > It seems that this bug is not limited to 8.2.2; it also happened in > 8.2.1. > > I'm happy to provide more information, if someone can advice me what is > needed. I'll also try to shrink it to a small test case. New description: The error message I got from GHC was: {{{ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): idInfo t_XG0J Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} How was it triggerred (in short): There's function definition, `f x = undefined`. If I change it to `f x = __impossible "Oops!"`, ghc crashes. If I change it to `f x = error "Oops!", it's OK. `The definition of `__impossible` is simply `__impossible s = error $ s ++ "some text"`. The code can be found here: https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Desugar.hs#L482 and https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Compiler.hs#L30 It seems that this bug is not limited to 8.2.2; it also happened in 8.2.1. I'm happy to provide more information, if someone can advice me what is needed. I'll also try to shrink it to a small test case. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 08:28:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 08:28:23 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.29904716c27ed36ea89687459d656105@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If you were able to provide an easily-reproducible test case, it'd make it much more likely that we can fix it. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 08:42:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 08:42:19 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.2d9e07bbbff0b87592285d7d0e314b58@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The pattern-match overlap checker can do some simple things with guards, if memory serves; but it would indeed need a new entry point. At the moment we lack anyone with the time and inclination to pay attention to the pattern-match overlap checker. There's a great paper about it, but the actual implementation needs love and care. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 08:56:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 08:56:18 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe In-Reply-To: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> References: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> Message-ID: <057.059fcf141d23c225a7f951f4664ce8d5@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The relevant bit of code is this in HscMain: {{{ -- If the module used TH splices when it was last -- compiled, then the recompilation check is not -- accurate enough (#481) and we must ignore -- it. However, if the module is stable (none of -- the modules it depends on, directly or -- indirectly, changed), then we *can* skip -- recompilation. This is why the SourceModified -- type contains SourceUnmodifiedAndStable, and -- it's pretty important: otherwise ghc --make -- would always recompile TH modules, even if -- nothing at all has changed. Stability is just -- the same check that make is doing for us in -- one-shot mode. case m_tc_result of Nothing | mi_used_th iface && not stable -> compile mb_old_hash (RecompBecause "TH") _ -> skip iface }}} I think the `&& not stable` is wrong. After interrupting the first compilation, the second compilation finds some modules to be stable and this overrides the TH check. Unfortunately if we just delete this condition, then TH will cause a *lot* of recompilation. Just re-running `ghc --make` on something you just recompiled will recompile all the TH modules and everything that depends on them. The stable check was always a bit of a hack though, to get around the fact that we don't have the information we really need, which is "did the object file change". Perhaps we just need to be more clever and store hashes of object files as dependencies when we're using TH. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 09:53:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 09:53:21 -0000 Subject: [GHC] #14778: FunDep origin not correctly attributed Message-ID: <046.5be69d6d62d87354bb69f580a4d00bfd@haskell.org> #14778: FunDep origin not correctly attributed -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: FunDeps | 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 `TcInteract.improveTopFunEqs` we do not give the derived constraints an origin of `FunDepOrigin`. As a result, `dropDerivedSimples` will discard even an insoluble constraint arising from a fundep. In contrast class instance fundeps do have `FunDepOrigin` and are kept. This is at least inconsistent. And we get less good error messages. Shows up in tests `T13651, `TR8450`, `T13506`, `T14325`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 10:36:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 10:36:18 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.818961df3722e4d4294886be7f859c30@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zilinc): I'm been trying to do that, but strangely any random changes to the code could potentially void the bug. I have no clue how to proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 11:16:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 11:16:40 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.9731a442545686fdafd57280876e57f7@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I can't reproduce this. Please can you provide exact reproduction instructions? Steps I took: {{{ git clone https://github.com/NICTA/cogent.git cd cogent/cogent git reset --hard 92c40530cbcbac77469865e096dab3228a2fb92f git clone https://gist.github.com/e6fc9e8a254d795bbd8ec476ca9fc115.git nix-scripts cp nix-scripts/* . nix-shell cabal configure cabal build }}} Then the build completes successfully. Here are the nix files. https://gist.github.com/e6fc9e8a254d795bbd8ec476ca9fc115 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 11:33:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 11:33:32 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.5ddffdc9b70fb6fcc90f5c0dd92f8f21@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I reasoned that it didn't matter at all if `ghci` was being invoked programatically. In fact, it is more consistent to print out `()` rather than omit it. This was because it wasn't very convenient to insert this check in the `no-it` version as it worked before by checking if the type of `it` was `()`. Is it breaking your program? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 11:53:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 11:53:34 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.c11f9e4a96afddc6a2718afffd9cf15a@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Yes, it breaks my program - but I can work around it - although the workaround is a bit grim. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 12:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 12:30:56 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.a0e399fe4c1ac56af2090969c0d72b04@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zilinc): Thank you providing the steps. If you could apply the following change to the code, you might be able to reproduce the panic. {{{ diff --git a/cogent/src/Cogent/Desugar.hs b/cogent/src/Cogent/Desugar.hs index bdea312..6a6f308 100644 --- a/cogent/src/Cogent/Desugar.hs +++ b/cogent/src/Cogent/Desugar.hs @@ -479,7 +479,7 @@ desugarExpr (B.TE t@(S.RT (S.TVariant ts)) (S.Con c es) l) = do desugarExpr (B.TE _ (S.Seq e1 e2) _) = do v <- freshVar E <$> (Let v <$> desugarExpr e1 <*> withBinding v (desugarExpr e2)) -desugarExpr (B.TE _ (S.Lam p mt e) _) = undefined +desugarExpr (B.TE _ (S.Lam p mt e) _) = __impossible "xx" desugarExpr (B.TE _ (S.App e1 e2) _) = E <$> (App <$> desugarExpr e1 <*> desugarExpr e2) desugarExpr (B.TE _ (S.If c [] th el) _) = E <$> (If <$> desugarExpr c <*> desugarExpr th <*> desugarExpr el) desugarExpr (B.TE _ (S.If c vs th el) _) = do }}} Replying to [comment:5 mpickering]: > I can't reproduce this. Please can you provide exact reproduction instructions? > > Steps I took: > > {{{ > git clone https://github.com/NICTA/cogent.git > cd cogent/cogent > git reset --hard 92c40530cbcbac77469865e096dab3228a2fb92f > git clone https://gist.github.com/e6fc9e8a254d795bbd8ec476ca9fc115.git nix-scripts > cp nix-scripts/* . > nix-shell > cabal configure > cabal build > }}} > > Then the build completes successfully. > > Here are the nix files. https://gist.github.com/e6fc9e8a254d795bbd8ec476ca9fc115 > > -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 12:31:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 12:31:39 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.abe8f1806fe45ccc6cc4a2494abe266c@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by zilinc: Old description: > The error message I got from GHC was: > > {{{ > : error: > ghc: panic! (the 'impossible' happened) > (GHC version 8.2.2 for x86_64-unknown-linux): > idInfo > t_XG0J > Call stack: > CallStack (from HasCallStack): > prettyCurrentCallStack, called at > compiler/utils/Outputable.hs:1133:58 in ghc:Outputable > callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in > ghc:Outputable > pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > How was it triggerred (in short): > There's function definition, `f x = undefined`. If I change it to `f x = > __impossible "Oops!"`, ghc crashes. If I change it to `f x = error > "Oops!", it's OK. `The definition of `__impossible` is simply > `__impossible s = error $ s ++ "some text"`. > > The code can be found here: > https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Desugar.hs#L482 > and > https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Compiler.hs#L30 > > It seems that this bug is not limited to 8.2.2; it also happened in > 8.2.1. > > I'm happy to provide more information, if someone can advice me what is > needed. I'll also try to shrink it to a small test case. New description: The error message I got from GHC was: {{{ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): idInfo t_XG0J Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} How was it triggerred (in short): There's function definition, `f x = undefined`. If I change it to `f x = __impossible "Oops!"`, ghc crashes. If I change it to `f x = error "Oops!"`, it's OK. The definition of `__impossible` is simply `__impossible s = error $ s ++ "some text"`. The code can be found here: https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Desugar.hs#L482 and https://github.com/NICTA/cogent/blob/92c40530cbcbac77469865e096dab3228a2fb92f/cogent/src/Cogent/Compiler.hs#L30 It seems that this bug is not limited to 8.2.2; it also happened in 8.2.1. I'm happy to provide more information, if someone can advice me what is needed. I'll also try to shrink it to a small test case. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 12:40:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 12:40:07 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.aba07c05e6b0f7e1ea63e73ea898c5b8@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Thanks, I can reproduce this now. {{{ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): idInfo t_XI02 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:526:34 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 12:46:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 12:46:34 -0000 Subject: [GHC] #14771: TypeError reported too eagerly In-Reply-To: <045.a919a2a0174bec27cc26967509347872@haskell.org> References: <045.a919a2a0174bec27cc26967509347872@haskell.org> Message-ID: <060.3e4a75fcba884f6b221473b5d4005c5b@haskell.org> #14771: TypeError reported too eagerly -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | CustomTypeErrors 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 hsyl20): > I guess a better solution, although more complex, would be too look at the available equations for T and see if evaluation is "stuck" due to the type error. If so, we report the custom error. Otherwise, we leave the expression as is. That would be good! ---- Regarding the issue 2: say GHC can't solve `F n ~ Word` as in the given example. Currently it reports: {{{ • Couldn't match type ‘If (n <=? 8) Int DUMMY’ with ‘Word’ }}} Sometime in other places in my code (I don't know how to reproduce it in the smaller example) it reports the following, which is better because it mentions `F n`: {{{ • Couldn't match type ‘If (n <=? 8) Int8 DUMMY’ with ‘Word’ Expected type: Word Actual type: F n }}} I'd like `F n` to appear more often instead of having to remember that the complex expression `If (n <=? 8) ...` refers to `F n`. Maybe we could even suggest adding `F n ~ Word` as a constraint for `test2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 13:01:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 13:01:28 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.7bb49a40833d470b98f6795642877cdb@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zilinc): More experiments: after I made the following changes: {{{ diff --git a/cogent/src/Cogent/Desugar.hs b/cogent/src/Cogent/Desugar.hs index bdea312..3b8440d 100644 --- a/cogent/src/Cogent/Desugar.hs +++ b/cogent/src/Cogent/Desugar.hs @@ -175,9 +175,11 @@ pragmaToNote (_:pragmas) fn note = pragmaToNote pragmas fn note -- ----------------------------------------------------------------------------- lamLftTlv :: S.TopLevel S.RawType B.TypedPatn B.TypedExpr - -> DS t v (S.TopLevel S.RawType B.TypedPatn B.TypedExpr) -lamLftTlv (S.FunDef fn sigma alts) = undefined + -> DS t v (S.TopLevel S.RawType B.TypedPatn B.TypedExpr) +lamLftTlv (S.FunDef fn sigma alts) = S.FunDef fn sigma <$> mapM lamLftAlt alts +lamLftAlt :: S.Alt B.TypedPatn B.TypedExpr -> DS t v (S.Alt B.TypedPatn B.TypedExpr) +lamLftAlt (S.Alt p l e) = S.Alt p l <$> lamLftExpr e lamLftExpr :: B.TypedExpr -> DS t v B.TypedExpr lamLftExpr (B.TE t (S.Lam p mt e) l) = do @@ -192,6 +194,7 @@ lamLftExpr (B.TE t (S.Lam p mt e) l) = do let fn = S.FunDef f (S.PT [] t) [S.Alt (B.TP (S.PIrrefutable p) noPos) Regular e] -- no let-generalisation lftFun %= (fn:) return $ B.TE t (S.TypeApp f [] S.NoInline) l +lamLftExpr (B.TE t e l) = B.TE t <$> traverse lamLftExpr e <*> pure l -- freeVars :: B.TypedExpr -> Vec v VarName -> [(VarName, S.RawType)] -- freeVars (B.TE t (S.Var v) _) vs = maybeToList $ case findIx v vs of Just i -> Nothing; Nothing -> Just (v,t) @@ -479,7 +482,7 @@ desugarExpr (B.TE t@(S.RT (S.TVariant ts)) (S.Con c es) l) = do desugarExpr (B.TE _ (S.Seq e1 e2) _) = do v <- freshVar E <$> (Let v <$> desugarExpr e1 <*> withBinding v (desugarExpr e2)) -desugarExpr (B.TE _ (S.Lam p mt e) _) = undefined +desugarExpr (B.TE _ (S.Lam p mt e) _) = __impossible "desugarExpr (Lam)" desugarExpr (B.TE _ (S.App e1 e2) _) = E <$> (App <$> desugarExpr e1 <*> desugarExpr e2) desugarExpr (B.TE _ (S.If c [] th el) _) = E <$> (If <$> desugarExpr c <*> desugarExpr th <*> desugarExpr el) desugarExpr (B.TE _ (S.If c vs th el) _) = do }}} It doesn't crash with the `__impossible`, but this time it crashes with the `undefined`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 13:29:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 13:29:20 -0000 Subject: [GHC] #14777: panic when using a function defined in terms of `error` In-Reply-To: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> References: <045.edfc759cf3fa890282fee96e32a2a8f2@haskell.org> Message-ID: <060.2365a9c5c98e647655a7da1c595081c2@haskell.org> #14777: panic when using a function defined in terms of `error` -------------------------------------+------------------------------------- Reporter: zilinc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zilinc): For quite a few times, after I change some code, if it crashes, I can always fix it by changing one `__impossible` to `undefined` or v.v. I'm unsure whether it's a coincidence or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 14:16:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 14:16:38 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks Message-ID: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14122, #14123, | #8472, #14406 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the attached file produces: {{{ $ inplace/bin/ghc-stage2 -O -dcore-lint -g -c Data.Fixed.hs *** Core Lint errors : in result of Simplifier *** : warning: [RHS of str_s2UI :: Addr#] The type of this binder is unlifted: str_s2UI Binder's type: Addr# *** Offending Program *** ... str_s2UI :: Addr# [LclId, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 0}] str_s2UI = src "MkFixed"# str_a2j4 :: String [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 20 0}] str_a2j4 = src unpackCString# str_s2UI ... }}} This came up when I wanted to compile GHC HEAD with `-g`. There are a couple of related tickets, but some of them didn't reproduce. This is a small, self-contained example. I'm hoping that it would be possible to solve this without fully solving #14123 which seems to have bigger scope. My HEAD is d2511e3b61563ed3fc2c9aec2c90a4156373a24c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 14:16:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 14:16:48 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.c78580e2fa4360c5e5cbeef3086065c6@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * Attachment "Data.Fixed.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 14:39:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 14:39:52 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.5fe0d9000e1b39154ec5b24a46723842@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think this is something to do with GHC's rules about top-level bindings. There's a special case for {{{ x :: Addr# x = "flbha"# }}} which is allowed. But here we have {{{ str_s2UI = src "MkFixed"# }}} One of two things should be true: * That is bad, and we should not allow it. In which case whichever code is generating it needs to be fixed. * That is ok, and Lint should accept it. I'm not sure which, because I'm not sure of the semantics of `src` ticks. (A long-standing issue.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 14:50:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 14:50:30 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.265854ecaed8d5e8f8960d7a834bcd94@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): > That is bad, and we should not allow it. In which case whichever code is generating it needs to be fixed. https://phabricator.haskell.org/D3925 suggests that this is the way we want to proceed. It refers to this note: {{{ Note [CoreSyn top-level string literals] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As an exception to the usual rule that top-level binders must be lifted, we allow binding primitive string literals (of type Addr#) of type Addr# at the top level. This allows us to share string literals earlier in the pipeline and crucially allows other optimizations in the Core2Core pipeline to fire. Consider, f n = let a::Addr# = "foo"# in \x -> blah In order to be able to inline `f`, we would like to float `a` to the top. Another option would be to inline `a`, but that would lead to duplicating string literals, which we want to avoid. See Trac #8472. The solution is simply to allow top-level unlifted binders. We can't allow arbitrary unlifted expression at the top-level though, unlifted binders cannot be thunks, so we just allow string literals. It is important to note that top-level primitive string literals cannot be wrapped in Ticks, as is otherwise done with lifted bindings. CoreToStg expects to see just a plain (Lit (MachStr ...)) expression on the RHS of primitive string bindings; anything else and things break. CoreLint checks this invariant. Also see Note [Compilation plan for top-level string literals]. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 14:57:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 14:57:50 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.fcae9b0b136b1947d03447d90e9aac6f@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): * D3925 seems to be be saying that a literal string should never be wrapped in certain sorts of ticks. Fine if that's so. * But D3925 only makes Lint reject more programs (I think). So how will it help here? * The invariant above says that top-level literal strings can't be surrounded by ticks of any kind. And indeed that's what is tripping the Lint error we are seeing in this ticket -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 14:58:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 14:58:46 -0000 Subject: [GHC] #14763: GHC 8.4.1-alpha regression with FunctionalDependencies In-Reply-To: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> References: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> Message-ID: <065.10b5c68ee59c59dbf555b91122844b6a@haskell.org> #14763: GHC 8.4.1-alpha regression with FunctionalDependencies -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha3 checker) | Resolution: | Keywords: FunDeps 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:"6edafe3be0133fe69581fb3851a812c69ab9dbf7/ghc" 6edafe3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6edafe3be0133fe69581fb3851a812c69ab9dbf7" Fix isDroppableCt (Trac #14763) When finishing up an implication constraint, it's a bit tricky to decide which Derived constraints to retain (for error reporting) and which to discard. I got this wrong in commit f20cf982f126aea968ed6a482551550ffb6650cf (Remove wc_insol from WantedConstraints) The particular problem in Trac #14763 was that we were reporting as an error a fundep-generated constraint (ex ~ T) where 'ex' is an existentially-bound variable in a pattern match. But this isn't really an error at all. This patch fixes the problem. Indeed, since I had to understand this rather tricky code, I took the opportunity to clean it up and document better. See isDroppableCt :: Ct -> Bool and Note [Dropping derived constraints] I also removed wl_deriv altogether from the WorkList data type. It was there in the hope of gaining efficiency by not even processing lots of derived constraints, but it has turned out that most derived constraints (notably equalities) must be processed anyway; see Note [Prioritise equalities] in TcSMonad. The two are coupled because to decide which constraints to put in wl_deriv I was using another variant of isDroppableCt. Now it's much simpler -- and perhaps even more efficient too. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 15:03:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 15:03:01 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.6d1be310f789fb056adc8c7eec777417@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): > But D3925 only makes Lint reject more programs (I think). So how will it help here? Right. I was only using it to understand what the invariant should be. Fortunately there's also the note, I should have referred to it directly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 15:44:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 15:44:33 -0000 Subject: [GHC] #14763: GHC 8.4.1-alpha regression with FunctionalDependencies In-Reply-To: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> References: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> Message-ID: <065.d320cc7a8577d9f9039c2f2f5c5580b1@haskell.org> #14763: GHC 8.4.1-alpha regression with FunctionalDependencies -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha3 checker) | Resolution: | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/typecheck/should_compile/T14763 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => testsuite/tests/typecheck/should_compile/T14763 Comment: Thanks for reporting this with a nice small example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 16:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 16:30:56 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.8fbad8b89f6bf9f3efec6c83f2d10539@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): {{{ diff --git a/compiler/simplCore/SimplUtils.hs b/compiler/simplCore/SimplUtils.hs index d86adbb..c06f03c 100644 --- a/compiler/simplCore/SimplUtils.hs +++ b/compiler/simplCore/SimplUtils.hs @@ -1115,6 +1115,7 @@ preInlineUnconditionally env top_lvl bndr rhs rhs_env | isCoVar bndr = Nothing -- Note [Do not inline CoVars unconditionally] | isExitJoinId bndr = Nothing | not (one_occ (idOccInfo bndr)) = Nothing + | exprIsLiteralString rhs = Nothing | not (isStableUnfolding unf) = Just (extend_subst_with rhs) -- Note [Stable unfoldings and preInlineUnconditionally] }}} Fixes it for me and seems desirable. I need to gather some more context to be able to intelligently argue for/against it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 16:37:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 16:37:04 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.5b8c6002d9a595a2eead0314b963357d@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jmct): Is this the "GADTs Meet Their Match" (great title) paper? I can try to take this on if no one else has cycles for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 16:51:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 16:51:30 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.1dfde84afc5bf4c043e1771397838502@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, that's the paper! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 16:55:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 16:55:51 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.65e938edd9c05ab19ab87351a9946841@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I wonder ''why'' that fixes it. Something must have ledt you there. (This is in `preInlineUnconditionally'. If we have {{{ let x = "fop#" in f x }}} where x appears once then I really don't want to disable inlining it. Maybe with an `isTopLevel` guard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 17:50:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 17:50:49 -0000 Subject: [GHC] #14771: TypeError reported too eagerly In-Reply-To: <045.a919a2a0174bec27cc26967509347872@haskell.org> References: <045.a919a2a0174bec27cc26967509347872@haskell.org> Message-ID: <060.739891662d697248c6f7231c2103f975@haskell.org> #14771: TypeError reported too eagerly -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | CustomTypeErrors 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 diatchki): Ok, so I think issue 2) is not related to custom type errors. I haven't looked at this part of the error reporting much, but I suspect that in some cases GHC forgets that some type expression is the result of evaluating a function. Tricky business. I'd say it'd be better to file a separate ticket for this, especially if you can find a concrete example that might point out to exactly what we may fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 18:02:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 18:02:26 -0000 Subject: [GHC] #14771: TypeError reported too eagerly In-Reply-To: <045.a919a2a0174bec27cc26967509347872@haskell.org> References: <045.a919a2a0174bec27cc26967509347872@haskell.org> Message-ID: <060.1ed70bbc0bb50452183997f0626b80bd@haskell.org> #14771: TypeError reported too eagerly -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | CustomTypeErrors 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 diatchki): As for issue 1), I am a bit weary of doing the change, as the current behavior has a fairly simple explanation; the alternative I mentioned would be more of a heuristic, as I don't think we have a specific order of evaluation, and it could make some custom errors not show up, when you'd like them to show. Generally, even though `TypeError` is implemented just as a type function, I really think of it more of a special right-hand side in type function definitions. If you use it in this way, then you don't encounter the problems you found, because the type error is only ever generated when there is no other alternative. So this is how I'd structure your example in this style: {{{ type family Assert (prop :: Bool) (val :: k) (msg :: ErrorMessage) where Assert 'True val msg = val Assert 'False val msg = TypeError msg }}} In fact, we should probably add this type function to `Data.Type.Bool`. With this combinator, you could define `F` simply as: {{{ type F n = Assert (n <=? 8) Int (Text "Input to F should be no greater than 8") }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 18:18:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 18:18:29 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.3ef83f518f52320e54a31f14913a16d3@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Agreed, this is too broad. I need `isTopLevel` as well. I didn't get here in a very principled way. I just saw that FloatOut was doing what I expected (not putting ticks), then after a Simplifier pass it was broken. I noticed that the floated out binding was touched by pre-inline-uncond and it prompted me to look at `preInlineUnconditionally`. I then vaguely recalled that we intend for these top level unboxed strings to stay floated, so it seemed like a good idea not to inline them. I forgot the top level part in my impromptu patch. Why do we end up with ticks after that? I don't know yet. But arguably, inlining a top level unboxed string literal is the first place where we went wrong. NB: With the fixed patch that does `isTopLevel` I'm able to compile GHC HEAD with `-g`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 21:22:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 21:22:10 -0000 Subject: [GHC] #14775: GHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file In-Reply-To: <042.c2e6771556eb83c8c227872bff540244@haskell.org> References: <042.c2e6771556eb83c8c227872bff540244@haskell.org> Message-ID: <057.b73413df0b0f020c9a19c764b8d75cec@haskell.org> #14775: GHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: 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 asr: Old description: > I'm getting the following error when `build-type: Custom` and `license: > OtherLicense` are in the .cabal file: > > `Foo.cabal`: > {{{ > name: Foo > version: 0.1.0.0 > license: OtherLicense > build-type: Custom > cabal-version: >=1.10 > > library > exposed-modules: Foo > build-depends: base > default-language: Haskell2010 > }}} > > `Foo.hs`: > {{{#!hs > module Foo where > > foo :: Int -> Int > foo n = n > }}} > > `Setup.hs`: > {{{#!hs > import Distribution.Simple > main = defaultMain > }}} > > The error: > {{{ > $ cabal install > Failed to install Foo-0.1.0.0 > cabal: Error: some packages failed to install: > Foo-0.1.0.0-33ReQaKfqaD7MoDL7J5kFM failed during the final install step. > The > exception was: > dieVerbatim: user error (cabal: Couldn't parse the output of 'setup > register > --gen-pkg-config':NoParse > "license" 5 > ) > }}} > > `cabal-install` version: > {{{ > $ cabal --version > cabal-install version 2.0.0.1 > compiled using version 2.0.1.0 of the Cabal library > }}} > > If I change the `license` field ''or'' the `build` field, the error > disappeared. I didn't get the above error using GHC 8.4.1-alpha2. New description: I got an error installing Agda upstream. I could reduce the error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file: `Foo.cabal`: {{{ name: Foo version: 0.1.0.0 license: OtherLicense build-type: Custom cabal-version: >=1.10 library exposed-modules: Foo build-depends: base default-language: Haskell2010 }}} `Foo.hs`: {{{#!hs module Foo where foo :: Int -> Int foo n = n }}} `Setup.hs`: {{{#!hs import Distribution.Simple main = defaultMain }}} The error: {{{ $ cabal install Failed to install Foo-0.1.0.0 cabal: Error: some packages failed to install: Foo-0.1.0.0-33ReQaKfqaD7MoDL7J5kFM failed during the final install step. The exception was: dieVerbatim: user error (cabal: Couldn't parse the output of 'setup register --gen-pkg-config':NoParse "license" 5 ) }}} `cabal-install` version: {{{ $ cabal --version cabal-install version 2.0.0.1 compiled using version 2.0.1.0 of the Cabal library }}} If I change the `license` field ''or'' the `build` field, the error disappeared. I didn't get the above error using GHC 8.4.1-alpha2. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 21:36:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 21:36:16 -0000 Subject: [GHC] #14654: Nofib: Strip called without .exe extension resulting in errors. In-Reply-To: <047.c0797d46dbce4498940454ea926743bb@haskell.org> References: <047.c0797d46dbce4498940454ea926743bb@haskell.org> Message-ID: <062.246b563d418fba7446f9dda063c83d1c@haskell.org> #14654: Nofib: Strip called without .exe extension resulting in errors. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: NoFib benchmark | Version: 8.2.2 suite | Keywords: nofib, Resolution: fixed | windows Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4297 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 8 22:14:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Feb 2018 22:14:21 -0000 Subject: [GHC] #14771: TypeError reported too eagerly In-Reply-To: <045.a919a2a0174bec27cc26967509347872@haskell.org> References: <045.a919a2a0174bec27cc26967509347872@haskell.org> Message-ID: <060.62f87577d46bd76d2e9c8ed7ddb39a84@haskell.org> #14771: TypeError reported too eagerly -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | CustomTypeErrors 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 hsyl20): Nice! `Assert` did the trick, thanks! I'll fill another ticket for issue 2 if I find a better example. I leave the ticket open to discuss if we want `Assert` to be added to `Data.Type.Bool`. Otherwise we can close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 00:11:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 00:11:37 -0000 Subject: [GHC] #14765: Levity polymorphism panic In-Reply-To: <045.04b286131d704736c3efb57c6bc8d169@haskell.org> References: <045.04b286131d704736c3efb57c6bc8d169@haskell.org> Message-ID: <060.bcb473ecc17f69c336791ef45f896ec6@haskell.org> #14765: Levity polymorphism panic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard, this is a continuation of #12709. During desugaring we have {{{ f a b }}} Turns out that there's a levity-polymophism error in `(f a)`, so (bizarrely) `dsWhneNoErrs` returns `()`. Then the desugarer tries to apply that to `b`, and that fails because `()` isn't a function type. Hhe cure (for #12709) was ugly enough; now we find that it doesn't acutally work! Replacing an expression by `()` doesn't make sense -- the types are wrong. I can see two solutions (there may be others): * Instead of returning `()` return `undefined @ty` where `ty` is the needed type. But the whole `dsWhenNoErrs` machinery is very heavy; it calls `tryM` (which in turn allcoates fresh IO refes for errors etc) on every single application node. The cure is worse than the disease. So instead * We could define desugarer-only version of `mkCoreApp`, which doesn't blow up on levity-polymorphic args. (Maybe it builds an ordinary App, say.) It's a bit of code to duplicate but not much, and it's easy to understand. (Alternatively we could make `isUnliftedType` return False for a levity- poly type. That would be even simpler.) What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 00:11:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 00:11:44 -0000 Subject: [GHC] #14767: Move Data.Functor.Contravariant into base In-Reply-To: <049.b50afcae0d7c6cf3237575f5b3450e51@haskell.org> References: <049.b50afcae0d7c6cf3237575f5b3450e51@haskell.org> Message-ID: <064.02961889d717a7009ade217f8605560e@haskell.org> #14767: Move Data.Functor.Contravariant into base -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: base Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I've put up a patch on phabricator as https://phabricator.haskell.org/D4399. There should be two commits in that differential, although I am only able to see one of them in phabricator. Changes still need to be made to `StateVar`, `transformers`, and `contravariant`. I can help with these later down the road if needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 00:13:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 00:13:39 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.70fd30e722b6e2eff8c7e1631d278646@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: 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): On second thought, I was too hasty in my earlier assessment—this might be more tractable than I thought. It turns out that when we're checking patterns from function bindings (as in `program 2` above), we don't directly call `checkMatches`, but instead go through an auxiliary function called [http://git.haskell.org/ghc.git/blob/6edafe3be0133fe69581fb3851a812c69ab9dbf7:/compiler/deSugar/Match.hs#l678 matchWrapper]. Instead of taking a list of `LPat`s an an argument, `matchWrapper` takes a `MatchGroup`, and sets up the necessary scaffolding to feed that into `checkMatches`. Now, we can't directly feel an `HsMultiIf`'s guards into `matchWrapper`, since `HsMultiIf` has an `LGRHS` instead of a `MatchGroup`. However, if we look at the definition of `MatchGroup` (and `(L)Match`): {{{#!hs data MatchGroup p body = MG { mg_alts :: Located [LMatch p body] , mg_arg_tys :: [PostTc p Type] , mg_res_ty :: PostTc p Type , mg_origin :: Origin } type LMatch id body = Located (Match id body) data Match p body = Match { m_ctxt :: HsMatchContext (NameOrRdrName (IdP p)), m_pats :: [LPat p], -- The patterns m_grhss :: (GRHSs p body) } }}} We can see that we're actually very close to having what we need, since we can slide the `GRHS` right into a `Match`, and put that into the `mg_alts` of a `MatchGroup`. The trick is to then come up with suitable things to put in the remaining fields of `MatchGroup` and `Match`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 00:24:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 00:24:20 -0000 Subject: [GHC] #14123: Figure out invariants surrounding ticks in Core In-Reply-To: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> References: <046.0308c769b363c5285c5969fe8d556b65@haskell.org> Message-ID: <061.f12e24c2235d8bfaa5fd36ad291a2422@haskell.org> #14123: Figure out invariants surrounding ticks in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13233, #14122, | Differential Rev(s): #8472, #14406, #14779 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #13233, #14122, #8472, #14406 => #13233, #14122, #8472, #14406, #14779 Comment: Niteria has made some progress on this in #14779. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 01:32:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 01:32:45 -0000 Subject: [GHC] #14780: :type-at doesn't work when :load-ing with module name instead of file path Message-ID: <042.ca20dadd5d069ac5ab988f32ba0c2cbf@haskell.org> #14780: :type-at doesn't work when :load-ing with module name instead of file path --------------------------------------+--------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------- After running {{{#!sh stack new something cd something }}} we have a file in src/Lib.hs with the contents: {{{#!hs module Lib ( someFunc ) where someFunc :: IO () someFunc = putStrLn "someFunc" }}} If we start `stack ghci`, we can have the following session showing the errors: {{{ > :set +c > :l Lib [1 of 1] Compiling Lib ( /home/jol/work- for/me/something/src/Lib.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... > :type-at Lib 6 12 6 20 : error: not an expression: ‘’ > :type-at src/Lib.hs 6 12 6 20 Couldn't guess that module name. Does it exist? }}} If we had done `:l src/Lib.hs` instead, then we can use the filepath like the following, but still not the module name: {{{ > :set +c > :l src/Lib.hs [1 of 1] Compiling Lib ( src/Lib.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... > :type-at Lib 6 12 6 20 : error: not an expression: ‘’ > :type-at src/Lib.hs 6 12 6 20 :: String -> IO () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 02:04:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 02:04:20 -0000 Subject: [GHC] #14780: :type-at doesn't work when :load-ing with module name instead of file path In-Reply-To: <042.ca20dadd5d069ac5ab988f32ba0c2cbf@haskell.org> References: <042.ca20dadd5d069ac5ab988f32ba0c2cbf@haskell.org> Message-ID: <057.bad65122445cba9e236b3faa995139f7@haskell.org> #14780: :type-at doesn't work when :load-ing with module name instead of file path ---------------------------+-------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------+-------------------------------------- Comment (by jol): I'm really not sure what the proper fix should be. Because this is meant for use by an IDE and not a user, maybe the documentation could simply be improved? I spent a while trying to figure out how to use `:type-at`, because 1. I didn't understand that the right bound for the span given should be one column to the right of the last character of the expression, and 2. I didn't know that this would only work when {{{:load}}}-ing with the filepath, and not the module name. This was unexpected because the ghc user guide entry for `:load` never seems to hint that behaviour could depend on which is chosen. 3. Also, the guide entry for `:type-at` never says that the argument needs to be a filepath. I think the error messages could also be improved. Point 1 above would've been obvious if the error message contained the text it tried to parse, after the "not an expression", in between the quotes, instead of just presenting an empty string. Also, it's difficult to understand ghci when it says that `:type-at` couldn't "guess that module name" when given src/Lib.hs in the first session, but it could in the second. Anyway, thank you for your attention and the awesome `:type-at` feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 02:11:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 02:11:59 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.4c33feffcec940a9650f02ae967000f2@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings 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 sighingnow): * owner: (none) => sighingnow Comment: I already have some tries on this. We can construct the `LMatch` manually in `ds_expr`, the use `checkMatches` directly, without feed to `matchWrapper`. We can do some like this: {{{#!hs ds_expr _ (HsMultiIf res_ty alts) | null alts = mkErrorExpr | otherwise = do { match_result <- liftM (foldr1 combineMatchResults) (mapM (dsGRHS IfAlt res_ty) alts) ; dflags <- getDynFlags ; vanillaId <- mkPmId boolTy ; let vanillaLPat = mkLHsVarPatTup [vanillaId] matches = [ L (getLoc pattern) $ Match { m_ctxt = IfAlt , m_pats = [vanillaLPat] , m_grhss = GRHSs [pattern] (noLoc emptyLocalBinds) } -- mkSimpleMatch IfAlt [vanillaLPat] m | pattern@(L _ (GRHS p m)) <- alts] ; checkMatches dflags dsMatchContext [vanillaId] matches ; error_expr <- mkErrorExpr ; extractMatchResult match_result error_expr } where mkErrorExpr = mkErrorAppDs nON_EXHAUSTIVE_GUARDS_ERROR_ID res_ty (text "multi-way if") combinedLoc = foldr1 combineSrcSpans (map getLoc alts) dsMatchContext = DsMatchContext IfAlt combinedLoc }}} Patch coming! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 03:20:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 03:20:29 -0000 Subject: [GHC] #14765: Levity polymorphism panic In-Reply-To: <045.04b286131d704736c3efb57c6bc8d169@haskell.org> References: <045.04b286131d704736c3efb57c6bc8d169@haskell.org> Message-ID: <060.dddff319a6ddf79a0bc2df0d9122339a@haskell.org> #14765: Levity polymorphism panic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): A few thoughts: * I really don't like having `isUnliftedType` return False for levity polymorphism. Panicking is the right behavior. Anything else might mask bugs. * How would the new `mkCoreApp` work? Would it check its argument for levity polymorphism and then react accordingly? This check is not necessarily cheap, and it would be redundant with other checks for LP. * We could make the new `mkCoreApp` monadic and have it do the only LP check. But then it would need to take the undesugared argument, so that error messages can be at all sensible. That would work in several cases, but sometimes it's not so easy. * You're right that returning `()` is gross. Perhaps returning `undefined` is better. * `dsWhenNoErrs` uses `askNoErrsDs` which does indeed use `tryM`. But there's no great reason `askNoErrsDs` needs to allocate fresh refs for messages, given that messages are ''always'' propagates in `askNoErrsDs`. Perhaps we could just make that more efficient by not using `tryM`. Bottom line: I don't love the current design. But the devil is in the details, and I'm not yet convinced about any new design either. We'd have to try it and see. (I am convinced enough that `undefined` is better than what we have now.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 04:38:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 04:38:40 -0000 Subject: [GHC] #14781: Incorrect CPU core counts in virtualized environments Message-ID: <048.1dba4d6ac0576664f82c4adab3b77df7@haskell.org> #14781: Incorrect CPU core counts in virtualized environments -------------------------------------+------------------------------------- Reporter: rtfeldman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To reproduce this bug: 1. Write a program that prints `numCapabilities` (the # of CPU cores the program thinks are available for parallelization) to stdout 2. Run this program in a virtualized environment such as Travis CI to see what it prints Expected output: it prints the number of CPU cores available to the process, which in the case of Travis's virtualized environment is 2. Actual output: it prints the number of *physical* cores on the machine, which in the case of Travis's servers is 32. The real-world consequences of this bug manifest for the compiler for the Elm programming language, which is written in Haskell and compiled with GHC. By default, `elm-make` runs extremely slowly on Travis and Circle CI because it's trying to parallelize across 32 cores when only 2 are actually available to it. For a proof-of-concept for how to correctly detect the number of available cores (as opposed to physical), here is the source code to a Rust library which does so correctly: https://github.com/seanmonstar/num_cpus/blob/master/src/lib.rs - the library distinguishes between "number of CPUs" and "number of physical CPUs," and on Travis it correctly reports 2 for CPUs and 32 for physical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 05:05:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 05:05:01 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.cd2034dec35cf3135e6785a04a893fe6@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: sighingnow Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): I'm confused with the following comments at Check.hs: https://ghc.haskell.org/trac/ghc/browser/ghc/compiler/deSugar/Check.hs#L1904 {{{#!hs 1904 exhaustiveWarningFlag (StmtCtxt {}) = Nothing -- Don't warn about incomplete patterns 1905 -- in list comprehensions, pattern guards 1906 -- etc. They are often *supposed* to be 1907 -- incomplete }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 05:38:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 05:38:24 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.d855939e1d8c297bc757515727e0e02b@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: sighingnow Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | T14773a,T14773b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4400 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => patch * testcase: => T14773a,T14773b * differential: => Phab:D4400 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 07:31:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 07:31:47 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.d5eca09d41fe813360e439a3daa4bf51@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I looked at `cse` and `circsim` which are smaller programs with increased allocation. Really the only difference I could find after a few hours of investigation is with `-flate-dmd-anal` we get new worker functions that return head and tail of a list in an unboxed tuple instead of returning a list. As far as I can see, the result is almost always packed back to a list at some point (somehwere in upper levels in the call stack). Overall the allocation should stay the same (because we allocate same number of cons cells, but allocate them in different places than we would without `-flate-dmd- anal`), so maybe this doesn't explain the allocation increase. Here's an example from `cse`, this is without late demand analysis: {{{ $wgo1_r6PF :: [GHC.Types.Char] -> GHC.Prim.Int# -> [GHC.Types.Char] [GblId, Arity=2, Str=m2, Unf=OtherCon []] = sat-only [] \r [w_s6Uz ww_s6UA] case w_s6Uz of { [] -> $wxs1_r6PE ww_s6UA; : y_s6UC [Occ=Once*] ys_s6UD [Occ=Once] -> case ww_s6UA of ds11_s6UE { __DEFAULT -> let { sat_s6UG [Occ=Once] :: [GHC.Types.Char] [LclId] = [ys_s6UD ds11_s6UE] \u [] case -# [ds11_s6UE 1#] of sat_s6UF { __DEFAULT -> $wgo1_r6PF ys_s6UD sat_s6UF; }; } in : [y_s6UC sat_s6UG]; 1# -> : [y_s6UC n_r6Py]; }; }; }}} We generate this version with `-flate-dmd-anal`: {{{ $w$wgo_r6Yf :: [GHC.Types.Char] -> GHC.Prim.Int# -> (# GHC.Types.Char, [GHC.Types.Char] #) [GblId, Arity=2, Str=, Unf=OtherCon []] = sat-only [] \r [w_s73c w1_s73d] case w_s73c of { [] -> $w$wxs_r6Ye w1_s73d; : y_s73f [Occ=Once*] ys_s73g [Occ=Once] -> case w1_s73d of ds11_s73h { __DEFAULT -> let { sat_s73m [Occ=Once] :: [GHC.Types.Char] [LclId] = [ys_s73g ds11_s73h] \u [] case -# [ds11_s73h 1#] of sat_s73i { __DEFAULT -> case $w$wgo_r6Yf ys_s73g sat_s73i of { (#,#) ww1_s73k [Occ=Once] ww2_s73l [Occ=Once] -> : [ww1_s73k ww2_s73l]; }; }; } in (#,#) [y_s73f sat_s73m]; 1# -> (#,#) [y_s73f n_r6Y9]; }; }; }}} Notice that in the recursive case we do the same thing in both cases, but with `-flate-dmd-anal` we pack the result in call site rather than returning packed result in the recursive call. The call sites look like this: (large code, pasting only the relevant parts) {{{ let { sat_s757 [Occ=Once, Dmd=] :: [GHC.Types.Char] [LclId] = [ww_s751] \s [] case $w$wgo_r6Yf ww_s751 4# of { (#,#) ww3_s755 [Occ=Once] ww4_s756 [Occ=Once] -> : [ww3_s755 ww4_s756]; }; } in GHC.Base.++ ds10_r6Y7 sat_s757; }}} So we directly pack it again. Same transformation happens in `circsim` too. New worker: {{{ $w$wxs_rb9n :: GHC.Prim.Int# -> (# Main.Boolean, [Main.Boolean] #) [GblId, Arity=1, Caf=NoCafRefs, Str=, Unf=OtherCon []] = sat-only \r [w_sbe6] case w_sbe6 of ds1_sbe7 { __DEFAULT -> let { sat_sbec [Occ=Once] :: [Main.Boolean] [LclId] = \u [] case -# [ds1_sbe7 1#] of sat_sbe8 { __DEFAULT -> case $w$wxs_rb9n sat_sbe8 of { (#,#) ww1_sbea [Occ=Once] ww2_sbeb [Occ=Once] -> : [ww1_sbea ww2_sbeb]; }; }; } in (#,#) [Main.T sat_sbec]; 1# -> (#,#) [Main.T GHC.Types.[]]; }; }}} exactly the same thing, recursive case directly packs the result. Call site: {{{ case $w$wxs_rb9n y1_sbA8 of { (#,#) ww1_sbAc [Occ=Once] ww2_sbAd [Occ=Once] -> : [ww1_sbAc ww2_sbAd]; }; }}} again result is directly packed. This happens in several places in both programs. I compared outputs both by mapping STG functions in outputs to each other manually and comparing the definitions, and also by using a diff tool to see if there are any extra code blocks etc. other than the ones I've already checked manually. These changes seem to be all unless I'm missing anything. I wonder what happens if I disable CPR in post-late-ww pass and only do worker-wrapper (not sure if it's currently possible but in theory it should be?). This should avoid the transformations described above, maybele still winning in the other cases? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 08:42:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 08:42:34 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.a44c6719f5bd6db07b2a985bb49fb415@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: sighingnow Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | T14773a,T14773b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4400 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Why do you need `vanillaLPat`? Why not just have an empty list of patterns? Also {{{ b :: Bool Just b | False = Nothing }}} No that is not ignored by design. The thing that is ignored is this: {{{ [ e | False <- blah, blah blah ] and do { False <- blah; ... } }}} I hope that `StmtCxt` is true of the latter two but not of the former. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 08:44:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 08:44:41 -0000 Subject: [GHC] #14782: typeclass polymorphism defeats bang patterns Message-ID: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> #14782: typeclass polymorphism defeats bang patterns -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 think the following program should crash, but it doesn't: {{{ {-# LANGUAGE BangPatterns #-} main = let n :: Num a => a; !n = undefined in return () }}} Interestingly, my attempt to translate this out of BangPatterns into standard Haskell according to the translation on the wiki page led to a compile-time error: {{{ main = let n :: Num a => a; x at n = undefined in x `seq` return () }}} Produces the error: {{{ test.hs:1:12: error: • Overloaded signature conflicts with monomorphism restriction n :: forall a. Num a => a • In the expression: let n :: Num a => a x at n = undefined in x `seq` return () In an equation for ‘main’: main = let n :: Num a => a x at n = undefined in x `seq` return () | 1 | main = let n :: Num a => a; x at n = undefined in x `seq` return () | ^^^^^^^^^^^^^^^ }}} Even giving `x` its own explicitly polymorphic type signature -- what I thought was the standard way to prevent the monomorphism restriction from being a problem -- doesn't help. I'm uncertain what to make of that, but it certainly seems related: earlier versions of the compiler both do not give that error and do produce a crashing program, as I expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 08:47:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 08:47:22 -0000 Subject: [GHC] #14782: typeclass polymorphism defeats bang patterns In-Reply-To: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> References: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> Message-ID: <059.cce85020eb66a92563180980979d0392@haskell.org> #14782: typeclass polymorphism defeats bang patterns -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dmwit): * version: 8.2.1 => 8.2.2 Comment: (dminuoso confirmed that this applies to 8.2.2 as well, so I'm updating the version) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 08:49:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 08:49:06 -0000 Subject: [GHC] #14765: Levity polymorphism panic In-Reply-To: <045.04b286131d704736c3efb57c6bc8d169@haskell.org> References: <045.04b286131d704736c3efb57c6bc8d169@haskell.org> Message-ID: <060.c25f2eb5dcf358b98f7ee81258edb3a4@haskell.org> #14765: Levity polymorphism panic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): More thoughts > Perhaps we could just make that more efficient by not using tryM. No: we need to know if there are any error messages ''from the enclosed thing''. > I really don't like having isUnliftedType return False for levity polymorphism. Actually I've decided I do! The compiler should panic if there is no other alternative. Here there is -- and Lint will catch the error shortly afterwards in a much more civilised way. It's such a simple fix. > How would the new mkCoreApp work? Just like the current one, but without panicing in `isUnliftedType`, and with the entire apparatus introduced by #12709. That is, build a term that may not pass Lint; but it doesn't matter because we are going to report LP errors anyway and stop. So a "new mkCoreApp" duplicates code, but in exchange means that all other uses of `isUnliftedType` can panic if you still feel strongly that they should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 09:10:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 09:10:43 -0000 Subject: [GHC] #14782: typeclass polymorphism defeats bang patterns In-Reply-To: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> References: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> Message-ID: <059.75a34534e760b58d2c7d305db8739503@haskell.org> #14782: typeclass polymorphism defeats bang patterns -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: It is a bit confusing. See [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#recursive-and-polymorphic-let-bindings the manual entry for semantics of let bindings] {{{ let n :: Num a => a; !n = undefined in return () means let n :: Num a => a n = undefined in n `seq` return () which, after elaboration of dictionaries etc means let n = /\a. \(d::Num a). undefined in n `seq` return () }}} So the `seq` sees a lambda and does nothing. --------- As to the "conflicts with the MR" message, consider {{{ f :: forall a. Num a => a -> a Just f = e }}} and consult [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-880004.5 the Haskell report on the monomorphism restriction]. It says that the MR applies unless "an explicit type signature is given for every variable in the group that is bound by simple pattern binding"; and "Recall that ... a simple pattern binding is a pattern binding in which the pattern consists of only a single variable". So here `f` is not bound by a simple pattern binding and hence falls under the MR, signature or no signature. It's the same for your pattern binding `x at n`. You may say "but it's still simple" but that's not what the rules currently say. Incidentally, there's a bad typo in the Haskell 98 and Haskell 2010 reports. Under [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-860004.4.3.2 pattern bindings] both say "A simple pattern binding has form p = e"; but of course ''all'' pattern bindings have that form. It should say "A simple pattern binding has form x = e, where x is a variable". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 09:14:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 09:14:08 -0000 Subject: [GHC] #14782: typeclass polymorphism defeats bang patterns In-Reply-To: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> References: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> Message-ID: <059.0fe89bb019b7b949ddf85019ef619ad5@haskell.org> #14782: typeclass polymorphism defeats bang patterns -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: | MonomorphismRestriction 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: => MonomorphismRestriction -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 09:17:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 09:17:57 -0000 Subject: [GHC] #14451: Need proper SCC analysis of type declarations, taking account of CUSKs (was: Type synonym of type family causes error, error jumps to (fairly) unrelated source location) In-Reply-To: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> References: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> Message-ID: <066.3e0d06352733018148ad8f5d6b750904@haskell.org> #14451: Need proper SCC analysis of type declarations, taking account of CUSKs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7503 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: => #7503 Comment: See also #7503 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 09:19:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 09:19:13 -0000 Subject: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs In-Reply-To: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> References: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> Message-ID: <068.f31a14171f09049df37c009960d68930@haskell.org> #7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14451 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: GADTs => GADTs, TypeInType * related: => #14451 Comment: Adding this to `TypeInType` because it's really the same as #14451 which is so labelled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 10:07:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 10:07:41 -0000 Subject: [GHC] #14783: Initializing record with similarly named field from a different record results in warning rather than error Message-ID: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> #14783: Initializing record with similarly named field from a different record results in warning rather than error -------------------------------------+------------------------------------- Reporter: | Owner: (none) ulrikrasmussen | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: records | Operating System: Unknown/Multiple DuplicateRecordFields | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When a record is initialized using a similarly named field from another record, the compiler ignores the initialization and generates a warning instead of throwing an error. I believe this is a bug introduced in GHC 8.0.1 (and probably related to `DuplicateRecordFields`), since earlier versions of GHC would refuse to compile the code. Consider the following example: {{{ -- A.hs module A where data A = A { a :: (), b :: () } -- B.hs module B where data B = B { a :: (), b :: () } -- Main.hs module Main where import A hiding (a) import B x = A { a = (), b = () } main = case x of A () () -> return () }}} On GHC 8.0.1, this compiles (with a warning), and the program throws an exception when run: {{{ $ stack ghc --compiler ghc-8.0.1 -- --make Main.hs [1 of 3] Compiling B ( B.hs, B.o ) [2 of 3] Compiling A ( A.hs, A.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Main.hs:5:7: warning: [-Wmissing-fields] • Fields of ‘A’ not initialised: a • In the expression: A {a = (), b = ()} In an equation for ‘x’: x = A {a = (), b = ()} Linking Main ... $ ./Main Main: Main.hs:5:7-26: Missing field in record construction a }}} On GHC 7.10.3, the program will not compile: {{{ $ stack ghc --compiler ghc-7.10.3 -- --make Main.hs [1 of 3] Compiling B ( B.hs, B.o ) [2 of 3] Compiling A ( A.hs, A.o ) [3 of 3] Compiling Main ( Main.hs, Main.o ) Main.hs:5:7: Constructor ‘A’ does not have field ‘a’ In the expression: A {a = (), b = ()} In an equation for ‘x’: x = A {a = (), b = ()} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 10:08:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 10:08:04 -0000 Subject: [GHC] #14783: Initializing record with similarly named field from a different record results in warning rather than error In-Reply-To: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> References: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> Message-ID: <068.30f5d3b8e176cf877bdbae199f712fd8@haskell.org> #14783: Initializing record with similarly named field from a different record results in warning rather than error -------------------------------------+------------------------------------- Reporter: ulrikrasmussen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: records | DuplicateRecordFields 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 ulrikrasmussen): * Attachment "A.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 10:08:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 10:08:13 -0000 Subject: [GHC] #14783: Initializing record with similarly named field from a different record results in warning rather than error In-Reply-To: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> References: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> Message-ID: <068.425049098cb7025f2f3796e57e60bb65@haskell.org> #14783: Initializing record with similarly named field from a different record results in warning rather than error -------------------------------------+------------------------------------- Reporter: ulrikrasmussen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: records | DuplicateRecordFields 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 ulrikrasmussen): * Attachment "B.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 10:08:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 10:08:24 -0000 Subject: [GHC] #14783: Initializing record with similarly named field from a different record results in warning rather than error In-Reply-To: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> References: <053.5b725cc1d4e4c8f45180bb4a879fba30@haskell.org> Message-ID: <068.8dd19fc027fa366cdecf470c746f3629@haskell.org> #14783: Initializing record with similarly named field from a different record results in warning rather than error -------------------------------------+------------------------------------- Reporter: ulrikrasmussen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: records | DuplicateRecordFields 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 ulrikrasmussen): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 11:42:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 11:42:31 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.e8df5e2e35091d5e25b2802b74ffbd1d@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. Some thoughts * CPR for sum types was introduced in #5075. * The initial motivation was for non-recursive types like `Maybe` and `Either`. Here it seems quite likely that the caller will case-analyse the result, so exposing the result constructor to the caller is good. * You point out that for recursive types, like lists, we typically ''don't'' case-analyse the result, so nothing is gained by the CPR. Maybe we should disable CPR for ''recursive'' sum types. * It's hard to come with a rigorous notion of what a "recursive" sum-type is, but any reasonable approximation will do. * Disabling CPR for `late-dmd-anal` seems unprincipled, and doesn't catch the cases described in #5075. * I note that comment:10 of #5075 identifies that the transformation is switched off for non-top-level definitions. See `Note [CPR for sum types]` in `DmdAnal`. But now that we have join points, the objection may no longer apply. It'd be interesting to try. * comment:12 of #5075 identifies three more tickets that claim to benefit from `late-dmd-anal`. Let's see if they do. * `cse` and `circsim` really do allocate (a little) more. But in your investigation you didn't find any allocation differences. Doesn't `-ticky` nail it for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 11:54:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 11:54:29 -0000 Subject: [GHC] #14775: GHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file In-Reply-To: <042.c2e6771556eb83c8c227872bff540244@haskell.org> References: <042.c2e6771556eb83c8c227872bff540244@haskell.org> Message-ID: <057.7b62d467d4b7f8b9c935c3828e2840f6@haskell.org> #14775: GHC 8.4.1-alpha3 regression: Build error when `build-type: Custom` and `license: OtherLicense` are in the .cabal file -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by asr): Replying to [comment:1 phadej]: > TL;DR, I don't think this a valid issue. To fix, use up-to-data `cabal- install`. @phadej, thank you for a very informative answer. The oldest `GHC` version currently supported by Agda is `7.10.*`. If I understand correctly, the proposed fixes require at least `Cabal >= 1.24`. Is there a fix which also work with the `Cabal` version (i.e. `Cabal 1.22.*`) shipped with `GHC 7.10.3`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 12:51:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 12:51:29 -0000 Subject: [GHC] #14784: RTS header files can't be used with a C++ compiler Message-ID: <046.915be18a946df960093f8bf95e37faf5@haskell.org> #14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 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 you compile `m1.cpp`: {{{ #include "Rts.h" int main(int argc, char** argv) { } }}} with: {{{ g++ -g m1.cpp -std=c++11 -I includes/ -c }}} you get: {{{ In file included from includes/Rts.h:29:0, from m1.cpp:1: includes/Stg.h:29:3: error: #error __STDC_VERSION__ does not advertise C99 or later # error __STDC_VERSION__ does not advertise C99 or later ^ }}} It's not advertised anywhere that it should work, but it used to work. https://phabricator.haskell.org/D2045 is what introduced this check. Judging by https://stackoverflow.com/questions/48045243/ghc-gcc-compiler- issue-stdc-version-w-c99-from-stg-h-fails-for-every-packa, it affects GHC 8.2 and later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 15:30:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 15:30:38 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.d4ee569c34e081cb1e16d53c822e4d20@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): This is currently imperilled by #14420. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 15:32:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 15:32:16 -0000 Subject: [GHC] #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall In-Reply-To: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> References: <050.74a33b64a09712cb22148568a57e17c8@haskell.org> Message-ID: <065.b4cce824a82b2fac14e0493fa8c47b24@haskell.org> #14773: MultiWayIf makes it easy to write partial programs that are not catched by -Wall -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: sighingnow Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | T14773a,T14773b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4400 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Replying to [comment:11 simonpj]: > Why do you need `vanillaLPat`? Why not just have an empty list of patterns? I have misunderstood the `m_pats` field of `Match` and the `vars` arguments of `checkMatches`. I'll fix it. > I hope that `StmtCxt` is true of the latter two but not of the former. Now I see that we can't use `StmtCtx` here. Could I add another context for the `False` guards in ? > {{{ > b :: Bool > Just b | False = Nothing > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 15:34:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 15:34:54 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.b687225ca1d08a4bf2669acd526a509c@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346 | Differential Rev(s): Wiki Page: | ​Phab:D4110,Phab:D4189 -------------------------------------+------------------------------------- Changes (by alexbiehl): * differential: ​Phab:D4110 => ​Phab:D4110,Phab:D4189 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 16:59:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 16:59:08 -0000 Subject: [GHC] #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? In-Reply-To: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> References: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> Message-ID: <065.c34b63700c704978129846ecb6dd518d@haskell.org> #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: deriving, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): After talking to goldfire about this, I can answer my earlier question in comment:7: Replying to [comment:7 RyanGlScott]: > Is this blocked (at least partially) on getting your branch merged and/or fixing #14729? The short answer is: no. The long answer is: what goldfire was suggesting in comment:3 was that an intrepid GHC hacker could look at the innards of his GHC fork at https://github.com/goldfirere/ghc and, conceivably, adapt the logic he uses in `TcFlatten.flatten_args` to come up with an algorithm that would fix the problem in this ticket. (I had mistakenly though he meant that `liftCoSubst` //was// this algorithm, but in fact, it's only one component of it.) That being said, the performance of `TcFlatten.flatten_args` is apparently pretty bad, so adapting it in its current state might not be the wisest course of action. In light of this, I think I'll hold off on this idea for now and proceed with option (2) in comment:2 as a stopgap solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 17:01:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 17:01:11 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.63ff286d158d2459f613a1090e0de5ef@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: alpmestan => bgamari Comment: Handing this off to Ben as I have not (yet) been able to create a virtual machine that provides the hardware performance counters needed by `rr`, which really is the only sane way to figure out how we end up jumping to an invalid address. Off to you, Ben. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 17:46:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 17:46:01 -0000 Subject: [GHC] #14765: Levity polymorphism panic In-Reply-To: <045.04b286131d704736c3efb57c6bc8d169@haskell.org> References: <045.04b286131d704736c3efb57c6bc8d169@haskell.org> Message-ID: <060.63b8b4ac8c523f1e9a895834b98f28f5@haskell.org> #14765: Levity polymorphism panic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): So are you suggesting that this new `mkCoreApp` doesn't use `isUnliftedType`, but instead re-creates it? Who reports the LP error? I suppose that could remain the same as it is right now... but then the check in `mkCoreApp` will be redundant. To be clear, I am OK with having a special `mkCoreApp` that doesn't panic on an LP argument used in the desugarer, as long as `isUnliftedType` still panics. My worry here is more about performance, but perhaps it would be an improvement over the status quo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 17:58:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 17:58:59 -0000 Subject: [GHC] #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? In-Reply-To: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> References: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> Message-ID: <065.bb5f11cfa21813a247f7514979758853@haskell.org> #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: deriving, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4402 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4402 Comment: I've implemented the "stopgap solution" (mentioned in comment:9) in Phab:D4402. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 18:59:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 18:59:00 -0000 Subject: [GHC] #14785: accumArray is too lazy Message-ID: <045.3d70ccf693988ad2d3ddc47afd2f8ad1@haskell.org> #14785: accumArray is too lazy -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- According to the documentation, {{{#!hs -- If the accumulating function is strict, then 'accumArray' is strict in -- the values, as well as the indices, in the association list. Thus, -- unlike ordinary arrays built with 'array', accumulated arrays should -- not in general be recursive. }}} I believe that strictness is desirable, because it prevents thunks from accumulating when we use the passed function. But the strictness isn't actually there! We never force the result of the function. I believe we should fix the code (and documentation) to maintain the invariant that all elements in the result of `accumArray` are in WHNF. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 9 23:07:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Feb 2018 23:07:33 -0000 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> Message-ID: <066.1662942219f7fbd9c6f3d9e7fd5b8520@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by atravers): Replying to [comment:49 simonpj]: Starting with the following local definitions of computeInOuts, in section 5.4 of the Diatchki/Jones/Hallgren paper: {{{ nextExps = computeEs . computeIs computeEs is = zipWith exports mods is computeIs es = map (`inscope` toFun es) mods }}} which can be simplified to: {{{ nextExps es = map (computeModExps es) mods computeModExps es m = exports m (inscope m (toFun es)) }}} Then: {{{ nextExps es = map (computeModExps es) mods computeModExps es m = fst (compileMod es m) }}} ...assuming this can be well-defined: {{{ compileMod es m = (modExps, modCode) where modExps = exports m (inscope m (toFun es)) modCode = ... . . . }}} Would something like this be possible in GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 10 00:53:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Feb 2018 00:53:52 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.385c06d0f07f0547baa206877ab9ae6d@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): @niteria: First, I think there's a misunderstanding here. Hashes would be used only for hashing the module name, to determine another N-bit prefix similiar as for the tag (for example, you could have 8 bits for the tag, 28 bits for the hash of the module name, and 28 bits for the actual uniques). Within this sub-namespace (per-module) uniques would continue to be allocated in a (+1) fashion, counting up from 0 to `2^26-1`. So there would never be the risk of a "uniques collision" as you describe, only the risk of a "module name hash colision". Second, to avoid module name hashes colliding: You just check them for uniqueness. This is easy, because you can do it ahead of time, before the build, where you already know all modules in the project. If they collide, you just use the next bigger integer. The point of that module name hashing (under the assumption that we have only 64 bits) is not to guarantee separate namespaces in all cases , just to make it very likely while also being stable against adding a new module to the project (you could also just enumerate the modules from 1 to N, but then if you add one in the middle, all modules get new subnamespaces assigned, and with name hashing that doesn't happen this way). If there's a collision, that's not the end of the world or a critical error, it just means you'll get different uniques next time (relatively unlikely with `2^28`). And you still have the property that given the same project with same modules and same compiler, you're guaranteed to be fully deterministic. Just not between changes that add a module. If we want to guarantee to be fully deterministic for individual modules even across additions of modules, all uniques have to be prefixed with the full module name (which might also be a good option). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 10 13:22:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Feb 2018 13:22:44 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.ac03c80a04b174f7c7a75a47e1d52e08@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 10 14:38:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Feb 2018 14:38:19 -0000 Subject: [GHC] #14786: Compile-time panic with kind-level application in type famiy decl Message-ID: <044.53b569d2f8db08ee9c992c237f016fb6@haskell.org> #14786: Compile-time panic with kind-level application in type famiy decl -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Minimal example: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} type family E e (a :: k) (orn :: e a) :: () }}} Error message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): getRuntimeRep k_anW[sk:1] :: k0_aRs[tau:1] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1967:18 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 10 15:04:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Feb 2018 15:04:01 -0000 Subject: [GHC] #14787: Remove StgLint type checks Message-ID: <043.b42d9efeb50c0ccd29b8b0185debbec2@haskell.org> #14787: Remove StgLint type checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Copying from the mailing list thread: ---- https://mail.haskell.org/pipermail/ghc-devs/2018-February/015371.html I've been looking into some StgLint-related tickets: - #13994: Found a StgLint problem and fixed, there's another problem waiting to be fixed. Both related with the fact that after unarisation we lose even more typing information and type checks needs to be relaxed. - #14116: StgLint failed to look through newtypes, and because coercions are removed at that point it failed to type check. Solution was to relax type checks. - #5345: Because `unsafeCoerce# is operationally no-op, and we don't have coercions in STG, StgLint can't type check at all. The commit message notes: > Fundamentally STG Lint is impossible, because unsafeCoerce# > can randomise all the types. > This patch does a bit of fiddle faddling in StgLint which > makes it a bit better, but it's a losing battle. - #14117: Related with StgLint not keeping up with recent changes (join points), because it's not enabled by default in tests/validate. - #14118: Related with the fact that pre- and post-unarise we have different invariants in STG. Solution was to add a "unarise" parameter and do different checks based on that. - #14120: Again type checking errors. Commit for #14116 also fixes this. The commits compares `typePrimRep`s of types instead of comparing actual types (even this is not enough, see #13994). All this of course took time to debug. In addition, the new `StgCSE` pass makes transformations that trigger case alternative checks (and probably some other checks) because scrutinee and result won't have same types after the transformation described in `Note [Case 2: CSEing case binders]`. There's also this comment in StgLint.hs WARNING: ~~~~~~~~ This module has suffered bit-rot; it is likely to yield lint errors for Stg code that is currently perfectly acceptable for code generation. Solution: don't use it! (KSW 2000-05). It seems like it hasn't been used since 2000. All this suggests that - Checks related to types are impossible in StgLint. (see e.g. commit messages in #5345, #1420, transformations done by unariser and StgCSE) - It's not enabled since 2000, which I think means that it's not needed. This makes me question whether it's worth maintaining. Maybe we should just remove it. If we still want to keep we should decide on what it's supposed to do. Only invariants I can think of are: - After unarise there should be no unboxed tuple and sum binders. unarise is a simple pass and does same thing to all binders, there are no tricky cases so I'm not sure if we need to check this. - Variables should be defined before use. I again don't know if this should be checked, could this be useful for StgCSE? So I think we should do one of these: 1. Remove StgLint. 2. Rewrite it to only check these two and nothing else, enable it in validate (and in other build flavours that enable CoreLint). What do you think? If you think we should keep StgLint, can you think of any other checks? If we could reach a consensus I'm hoping to update StgLint (or remove it). ---- Simon suggested creating a ticket and keeping StgLint. This is the tracking ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 10 15:07:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Feb 2018 15:07:45 -0000 Subject: [GHC] #14787: Remove StgLint type checks In-Reply-To: <043.b42d9efeb50c0ccd29b8b0185debbec2@haskell.org> References: <043.b42d9efeb50c0ccd29b8b0185debbec2@haskell.org> Message-ID: <058.516684a6778bbba052bd565c9067629c@haskell.org> #14787: Remove StgLint type checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4404 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 10 15:28:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Feb 2018 15:28:08 -0000 Subject: [GHC] #14786: Compile-time panic with kind-level application in type famiy decl In-Reply-To: <044.53b569d2f8db08ee9c992c237f016fb6@haskell.org> References: <044.53b569d2f8db08ee9c992c237f016fb6@haskell.org> Message-ID: <059.8e9c574bdd0039f4453dbeab5f1a3aa1@haskell.org> #14786: Compile-time panic with kind-level application in type famiy decl -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | 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: | -------------------------------------+------------------------------------- Comment (by lyxia): Seems related to https://ghc.haskell.org/trac/ghc/ticket/14175, this appears to have been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 10 15:28:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Feb 2018 15:28:35 -0000 Subject: [GHC] #14786: Compile-time panic with kind-level application in type famiy decl In-Reply-To: <044.53b569d2f8db08ee9c992c237f016fb6@haskell.org> References: <044.53b569d2f8db08ee9c992c237f016fb6@haskell.org> Message-ID: <059.cd74729190753e9276041a8d9967e5e1@haskell.org> #14786: Compile-time panic with kind-level application in type famiy decl -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by lyxia): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 10 18:12:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Feb 2018 18:12:08 -0000 Subject: [GHC] #14788: `error` in GHC internals can disappear by rerunning ghc again Message-ID: <042.990361d1cd49e5f7500314a2cb466fff@haskell.org> #14788: `error` in GHC internals can disappear by rerunning ghc again -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: #14533 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was messing around with GHC's source code and thus triggered a bug, manifesting in my case as the `pprPanic "applyTypeToArgs" panic_msg` in `applyTypeToArgs` in GHC 8.2.1. Expectedly, ghc died with `the 'impossible' happened` while compiling a package (in my case `vector`). With output like this (it's not important to read the output in detail, only to see the `.o` file involved): {{{ [17 of 21] Compiling Data.Vector.Storable.Mutable ( Data/Vector/Storable/Mutable.hs, .stack- work/dist/x86_64-linux/Cabal-2.0.0.2/build/Data/Vector/Storable/Mutable.o ) Data/Vector/Storable/Mutable.hs:77:1: warning: [-Wunused-imports] The import of ‘Foreign.Ptr’ is redundant except perhaps to import instances from ‘Foreign.Ptr’ To import instances alone, use: import Foreign.Ptr() | 77 | import Foreign.Ptr | ^^^^^^^^^^^^^^^^^^ ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): applyTypeToArgs Expression: n#_aKi p_a3X ds5_XM4 ds7_aKj x#_aKa eta_X1H Type: Int# Args: [p_a3X, ds5_XM4, ds7_aKj, x#_aKa, eta_X1H] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreUtils.hs:226:14 in ghc:CoreUtils }}} What I did not expect was that by rerunning my `ghc --make` invocation again, the error would disappear! This is because after the error, the `.o` file is corrupt, just cut off in the middle. The reason is probably that GHC writes the `.o` file contents from an expression that can contain `error` thunks deep in, so the error only surfaces in the middle of the writing. As a result, the `.o` file is touched and `ghc --make` build pipeline, when resumnig the build next time, thinks that the `.o` file was completed all fine. I think `ghc --make` should not write the `.o` file when there's an obvious error. I suggest that ghc either `deepseq` the string to be written to the `.o` file before calling `writeFile` or equivalent, or write the file to an `.o.tmp` file and rename the temp file upon completion. The latter approach would also help against corrupted files due to power loss, see #14533. Fixing this would make developing GHC easier, as right now you can accidentally continue from a completely broken state (corrupt `.o` file) and only notice the error much later and then have to backtrack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 10 18:12:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Feb 2018 18:12:22 -0000 Subject: [GHC] #14533: Make GHC more robust against PC crashes by using atomic writes In-Reply-To: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> References: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> Message-ID: <057.069b64c268e04c50c9648a1bb0b584e7@haskell.org> #14533: Make GHC more robust against PC crashes by using atomic writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.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: #14788 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * related: => #14788 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 10 20:17:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Feb 2018 20:17:53 -0000 Subject: [GHC] #14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt Message-ID: <045.8cebee0eb74d2ceeb0d4f66066496471@haskell.org> #14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This was recently reported on Stack Overflow (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and- then-calculating-len-causes-ghc-to-consume-lots). With GHC 8.2.2, assigning the length of a large list as a top-level declaration at the GHCi prompt and evaluating it: {{{ Prelude> l = length [1..10^8] Prelude> l 10000000 Prelude> }}} allocates about 7 gigs of memory before displaying a result, and then memory continues to grow over the next few seconds (at the idle GHCi prompt) until 10 gigs of memory has been allocated. None of it is freed until the interpreter session ends. In contrast, directly evaluating the expression or assigning it with a let-statement does **not** exhibit this behavior: {{{ Prelude> length [1..10^8] 10000000 Prelude> let l = length [1..10^8] Prelude> l 10000000 Prelude> }}} Also, loading the top-level declaration from a file and then evaluating it at the prompt does **not** exhibit the problem. I took a look at Ticket [ticket: 14336] and applied the `-fno-it` patch referenced there. This slightly changed the pattern of memory usage: it grew to about 4 gigs before displaying the result, but then continued to grow for several seconds at the GHCi prompt before landing at about 10 gigs. I verified that the bug still exists on the current "master" branch (though I didn't check the "ghc-8.4" branch). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 07:02:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 07:02:04 -0000 Subject: [GHC] #13994: STG lint failure on master In-Reply-To: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> References: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> Message-ID: <061.61754842d7195dc86340d63b65909a63@haskell.org> #13994: STG lint failure on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14787 | Differential Rev(s): Phab:D4404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D4396 => Phab:D4404 * related: => #14787 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 09:45:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 09:45:15 -0000 Subject: [GHC] #14785: accumArray is too lazy In-Reply-To: <045.3d70ccf693988ad2d3ddc47afd2f8ad1@haskell.org> References: <045.3d70ccf693988ad2d3ddc47afd2f8ad1@haskell.org> Message-ID: <060.0cbbb117bc166772c4765e77f9bd9880@haskell.org> #14785: accumArray is too lazy -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4403 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4403 Comment: I have emailed the [https://mail.haskell.org/pipermail/libraries/2018-February/028509.html libraries list] and the CLC. In the mean time, I've uploaded a differential. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 10:06:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 10:06:14 -0000 Subject: [GHC] #14790: eqTypeRep does not inline Message-ID: <045.4b63c72352430124262929413983410f@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 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: -------------------------------------+------------------------------------- GHC never seems to inline `eqTypeRep`. That's no good! It produces a `Maybe`, which users will almost certainly want to match on immediately. I really don't understand ''why'' it doesn't inline. It's a tiny function, none of the functions it calls are themselves marked `INLINE`, and the advantage to inlining seems obvious. Does the `unsafeCoerce` get in the way somehow? If so, how can we fix it? Example: {{{#!hs {-# language GADTs, ScopedTypeVariables, TypeApplications #-} module Foo where import Type.Reflection foo :: forall proxy a. Typeable a => proxy a -> Bool foo _ = case eqTypeRep (typeRep @a) (typeRep @Int) of Just _ -> True Nothing -> False }}} compiles (with `-O2`) to {{{ foo = \ (@ (proxy_a6tT :: * -> *)) (@ a_a6tU) ($dTypeable_a6tW :: Typeable a_a6tU) -> let { lvl_s6Sc :: Maybe (a_a6tU :~~: Int) [LclId] lvl_s6Sc = eqTypeRep @ * @ * @ a_a6tU @ Int ($dTypeable_a6tW `cast` (base-4.11.0.0:Data.Typeable.Internal.N:Typeable[0] <*>_N _N :: (Typeable a_a6tU :: Constraint) ~R# (TypeRep a_a6tU :: *))) Foo.foo1 } in \ _ [Occ=Dead] -> case lvl_s6Sc of { Nothing -> GHC.Types.False; Just ds1_d6Rq -> GHC.Types.True } }}} For reference, `eqTypeRep` is defined like this: {{{#!hs eqTypeRep :: forall k1 k2 (a :: k1) (b :: k2). TypeRep a -> TypeRep b -> Maybe (a :~~: b) eqTypeRep a b | typeRepFingerprint a == typeRepFingerprint b = Just (unsafeCoerce HRefl) | otherwise = Nothing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 10:10:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 10:10:38 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.46e9aa63767a694c9876e0e5919af15a@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): In case you have any doubt that `eqTypeRep` performance is important, remember that it's used in every single exception handler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 10:52:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 10:52:48 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.d08b46a3b28a08ac49bf350d2b08b028@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > GHC never seems to inline `eqTypeRep`. That's no good! It produces a > `Maybe`, which users will almost certainly want to match on immediately. > > I really don't understand ''why'' it doesn't inline. It's a tiny > function, none of the functions it calls are themselves marked `INLINE`, > and the advantage to inlining seems obvious. Does the `unsafeCoerce` get > in the way somehow? If so, how can we fix it? > > Example: > > {{{#!hs > {-# language GADTs, ScopedTypeVariables, TypeApplications #-} > module Foo where > import Type.Reflection > > foo :: forall proxy a. Typeable a => proxy a -> Bool > foo _ = case eqTypeRep (typeRep @a) (typeRep @Int) of > Just _ -> True > Nothing -> False > > }}} > > compiles (with `-O2`) to > > {{{ > foo > = \ (@ (proxy_a6tT :: * -> *)) > (@ a_a6tU) > ($dTypeable_a6tW :: Typeable a_a6tU) -> > let { > lvl_s6Sc :: Maybe (a_a6tU :~~: Int) > [LclId] > lvl_s6Sc > = eqTypeRep > @ * > @ * > @ a_a6tU > @ Int > ($dTypeable_a6tW > `cast` (base-4.11.0.0:Data.Typeable.Internal.N:Typeable[0] > <*>_N _N > :: (Typeable a_a6tU :: Constraint) ~R# (TypeRep > a_a6tU :: *))) > Foo.foo1 } in > \ _ [Occ=Dead] -> > case lvl_s6Sc of { > Nothing -> GHC.Types.False; > Just ds1_d6Rq -> GHC.Types.True > } > }}} > > For reference, `eqTypeRep` is defined like this: > > {{{#!hs > eqTypeRep :: forall k1 k2 (a :: k1) (b :: k2). > TypeRep a -> TypeRep b -> Maybe (a :~~: b) > eqTypeRep a b > | typeRepFingerprint a == typeRepFingerprint b = Just (unsafeCoerce > HRefl) > | otherwise = Nothing > }}} New description: GHC never seems to inline `eqTypeRep`. That's no good! It produces a `Maybe`, which users will almost certainly want to match on immediately. I really don't understand ''why'' it doesn't inline. It's a tiny function, none of the functions it calls are themselves marked `INLINE`, and the advantage to inlining seems obvious. Does the `unsafeCoerce` get in the way somehow? If so, how can we fix it? Example: {{{#!hs {-# language GADTs, ScopedTypeVariables, TypeApplications, AllowAmbiguousTypes #-} module Foo where import Type.Reflection foo :: forall a. Typeable a => Bool foo = case eqTypeRep (typeRep @a) (typeRep @Int) of Just _ -> True Nothing -> False }}} compiles (with `-O2`) to {{{ foo [InlPrag=NOINLINE] :: forall a. Typeable a => Bool [GblId, Arity=1, Str=] foo = \ (@ a_a5un) ($dTypeable_a5up :: Typeable a_a5un) -> case eqTypeRep @ * @ * @ a_a5un @ Int ($dTypeable_a5up `cast` (base-4.10.1.0:Data.Typeable.Internal.N:Typeable[0] <*>_N _N :: (Typeable a_a5un :: Constraint) ~R# (TypeRep a_a5un :: *))) lvl4_r69g of { Nothing -> GHC.Types.False; Just ds_d5CQ -> GHC.Types.True } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 10:54:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 10:54:59 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.8114f43af4d405b63b7aac30eb3add7d@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > GHC never seems to inline `eqTypeRep`. That's no good! It produces a > `Maybe`, which users will almost certainly want to match on immediately. > > I really don't understand ''why'' it doesn't inline. It's a tiny > function, none of the functions it calls are themselves marked `INLINE`, > and the advantage to inlining seems obvious. Does the `unsafeCoerce` get > in the way somehow? If so, how can we fix it? > > Example: > > {{{#!hs > {-# language GADTs, ScopedTypeVariables, TypeApplications, > AllowAmbiguousTypes #-} > module Foo where > import Type.Reflection > > foo :: forall a. Typeable a => Bool > foo = case eqTypeRep (typeRep @a) (typeRep @Int) of > Just _ -> True > Nothing -> False > }}} > > compiles (with `-O2`) to > > {{{ > foo [InlPrag=NOINLINE] :: forall a. Typeable a => Bool > [GblId, Arity=1, Str=] > foo > = \ (@ a_a5un) ($dTypeable_a5up :: Typeable a_a5un) -> > case eqTypeRep > @ * > @ * > @ a_a5un > @ Int > ($dTypeable_a5up > `cast` (base-4.10.1.0:Data.Typeable.Internal.N:Typeable[0] > <*>_N _N > :: (Typeable a_a5un :: Constraint) ~R# (TypeRep > a_a5un :: *))) > lvl4_r69g > of { > Nothing -> GHC.Types.False; > Just ds_d5CQ -> GHC.Types.True > } > > }}} New description: GHC never seems to inline `eqTypeRep`. That's no good! It produces a `Maybe`, which users will almost certainly want to match on immediately. I really don't understand ''why'' it doesn't inline. It's a tiny function, none of the functions it calls are themselves marked `INLINE`, and the advantage to inlining seems obvious. Does the `unsafeCoerce` get in the way somehow? If so, how can we fix it? Example: {{{#!hs {-# language GADTs, ScopedTypeVariables, TypeApplications, AllowAmbiguousTypes #-} module Foo where import Type.Reflection foo :: forall a. Typeable a => Bool foo = case eqTypeRep (typeRep @a) (typeRep @Int) of Just _ -> True Nothing -> False }}} compiles (with `-O2`) to {{{ foo [InlPrag=NOINLINE] :: forall a. Typeable a => Bool [GblId, Arity=1, Str=] foo = \ (@ a_a5un) ($dTypeable_a5up :: Typeable a_a5un) -> case eqTypeRep @ * @ * @ a_a5un @ Int ($dTypeable_a5up `cast` (base-4.10.1.0:Data.Typeable.Internal.N:Typeable[0] <*>_N _N :: (Typeable a_a5un :: Constraint) ~R# (TypeRep a_a5un :: *))) lvl4_r69g of { Nothing -> GHC.Types.False; Just ds_d5CQ -> GHC.Types.True } }}} For reference, `eqTypeRep` is defined like this: {{{#!hs eqTypeRep :: forall k1 k2 (a :: k1) (b :: k2). TypeRep a -> TypeRep b -> Maybe (a :~~: b) eqTypeRep a b | typeRepFingerprint a == typeRepFingerprint b = Just (unsafeCoerce HRefl) | otherwise = Nothing }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 10:57:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 10:57:04 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.44536ccaac62808dddb520439136732e@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Using an explicit `TypeRep` instead of a `Typeable` constraint makes no difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 13:11:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 13:11:22 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.42b559b9783b763dd5493d37adf3bd40@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 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 mpickering): Compile with -dverbose-core2core and -ddump-inlinings and it will tell you exactly why it doesn’t get inlined. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 13:32:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 13:32:48 -0000 Subject: [GHC] #14791: Move stack checks out of code paths that don't use the stack. Message-ID: <047.2ea20512b2a37aa4c0736d7573c92c30@haskell.org> #14791: Move stack checks out of code paths that don't use the stack. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the simple function: {{{ func :: Int -> Int func 11 = 11111 func 41 = 4444 }}} We produce this cmm code: {{{ [section ""data" . T.func_closure" { T.func_closure: const T.func_info; const 0; }, T.func_entry() // [R2] { info_tbl: [(c2lk, label: block_c2lk_info rep:StackRep []), (c2ln, label: T.func_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c2ln: // global if ((Sp + -8) < SpLim) (likely: False) goto c2lo; else goto c2lp; c2lo: // global R2 = R2; R1 = T.func_closure; call (stg_gc_fun)(R2, R1) args: 8, res: 0, upd: 8; c2lp: // global I64[Sp - 8] = c2lk; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c2lk; else goto c2ll; c2ll: // global call (I64[R1])(R1) returns to c2lk, args: 8, res: 8, upd: 8; c2lk: // global _s2kY::I64 = I64[R1 + 7]; if (_s2kY::I64 != 11) goto u2ly; else goto c2lw; u2ly: // global if (_s2kY::I64 == 41) (likely: False) goto c2lx; else goto c2lv; c2lx: // global R1 = T.func1_closure+1; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c2lv: // global R1 = T.func3_closure; Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; c2lw: // global R1 = T.func2_closure+1; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] }}} However the code path if the argument is already evaluated never uses the stack: {{{ T.func_entry() // [R2] { info_tbl: [(c2lk, label: block_c2lk_info rep:StackRep []), (c2ln, label: T.func_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 8 updfr_space: Just 8 } {offset c2ln: // global if ((Sp + -8) < SpLim) (likely: False) goto c2lo; else goto c2lp; c2lp: // global I64[Sp - 8] = c2lk; R1 = R2; Sp = Sp - 8; if (R1 & 7 != 0) goto c2lk; else goto <..>; c2lk: // global _s2kY::I64 = I64[R1 + 7]; if (_s2kY::I64 != 11) goto u2ly; else goto c2lw; u2ly: // global if (_s2kY::I64 == 41) (likely: False) goto c2lx; else goto c2lv; c2lx: // global R1 = T.func1_closure+1; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c2lv: // global R1 = T.func3_closure; Sp = Sp + 8; call (I64[R1])(R1) args: 8, res: 0, upd: 8; c2lw: // global R1 = T.func2_closure+1; Sp = Sp + 8; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; } }] }}} This means if we have a tagged argument we * Perform a stack check * Decrement the stack * Move the continuation onto the stack. * Increment the stack Without any of it being necessary. If I'm not mistaken all of that could be done after we know we need to evaluate the argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 14:15:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 14:15:36 -0000 Subject: [GHC] #14792: compiling cabal-1.24.2.0 requires almost 3 GB of memory Message-ID: <043.eb98fb4a529dd0878c88812e1124a106@haskell.org> #14792: compiling cabal-1.24.2.0 requires almost 3 GB of memory -------------------------------------+------------------------------------- Reporter: bfrk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Not sure if this is really a bug, but I noticed that ghc-8.2.2 requires a whole lot more memory than ghc-7-10.3. This is how I found out about it: {{{ ben at yuiitsu[1]:.../src/Cabal-1.24.2.0>ulimit -v 2600000 ben at yuiitsu[1]:.../src/Cabal-1.24.2.0>cabal new-build Resolving dependencies... Build profile: -w ghc-8.2.2 -O1 In order, the following will be built (use -v for more details): - Cabal-1.24.2.0 (lib) (first run) Configuring library for Cabal-1.24.2.0.. Preprocessing library for Cabal-1.24.2.0.. Building library for Cabal-1.24.2.0.. [ 1 of 86] Compiling Distribution.Compat.Binary ( Distribution/Compat/Binary.hs, /home/ben/src/Cabal-1.24.2.0/dist- newstyle/build/x86_64-linux/ghc-8.2.2/Cabal-1.24.2.0/build/Distribution/Compat/Binary.o ) [...] [30 of 86] Compiling Distribution.PackageDescription ( Distribution/PackageDescription.hs, dist/build/Distribution/PackageDescription.o ) ghc: out of memory cabal: Failed to build Cabal-1.24.2.0 (which is required by darcs-2.13.0). The build process terminated with exit code 251 }}} It works when I ulimit -v 3000000. I previously had the limit at 2200000 and it worked just fine with ghc-7.10.3. The reason i limit the memory available to ghc is to avoid my machine freezing up due to thrashing (I only have 4GB physical RAM). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 14:34:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 14:34:42 -0000 Subject: [GHC] #14792: compiling cabal-1.24.2.0 requires almost 3 GB of memory In-Reply-To: <043.eb98fb4a529dd0878c88812e1124a106@haskell.org> References: <043.eb98fb4a529dd0878c88812e1124a106@haskell.org> Message-ID: <058.020f21846eeebb42bdf7774278523131@haskell.org> #14792: compiling cabal-1.24.2.0 requires almost 3 GB of memory -------------------------------------+------------------------------------- Reporter: bfrk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 bfrk): I am happy to report that the situation has improved with ghc-8.4.1. After making a few small changes to Cabal-1.24.2.0 I could compile it with ulimit -v 2500000. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 15:59:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 15:59:42 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.15f3f042d9c70764bfbe46e8d749bbd1@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I'm looking into doing this. First a remark: Instead of hashing for extra stability, we could also just use the increasing `[1 of 3] Compiling A` numbers for unique namespacing. But I noticed that the order of those is currently not stable: In a project with modules `A, B, C, Main`, `A` imports nothing, `B` and `C` both import `A`, `Main` imports `C` and `D`, sometimes you will get a different output of which of these modules is `[3 of 4]`. Example: {{{ % touch B.hs && /raid/src/ghc/git-8.2.1/inplace/bin/ghc-stage2 --make Main.hs [3 of 4] Compiling B ... }}} {{{ % touch C.hs && /raid/src/ghc/git-8.2.1/inplace/bin/ghc-stage2 --make Main.hs [3 of 4] Compiling C ... }}} That is because in `GhcMake.upsweep'` the `mod_index` is just counting up `+1`, but over `sccs :: [SCC ModSummary]` the order of which is somehow influenced by the file mtime (I haven't found yet how the mtime makes it to be a more significant field than the module name). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 16:20:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 16:20:24 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.8dbd4fa128bc3f918bc6273d209663f1@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): OK, the reason for the ordering being dependent on mtime is #7231: `mg = stable_mg ++ unsable_mg` was implemented to fix `GHCi erroneously unloads modules after a failed :reload`. https://ghc.haskell.org/trac/ghc/ticket/7231#comment:2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 16:28:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 16:28:17 -0000 Subject: [GHC] #7231: GHCi erroneously unloads modules after a failed :reload In-Reply-To: <044.01f6cfaddb4a80435b983101821a12bd@haskell.org> References: <044.01f6cfaddb4a80435b983101821a12bd@haskell.org> Message-ID: <059.0a247049a04fb380a80f45b72e520033@haskell.org> #7231: GHCi erroneously unloads modules after a failed :reload -------------------------------------+------------------------------------- Reporter: parcs | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 7.6.2 Component: GHCi | Version: 7.6.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): From over at https://ghc.haskell.org/trac/ghc/ticket/12935#comment:14, I found that this change is what makes the `[3 of 4]` order of `ghc --make` dependent on file mtime and thus generates different output depending on whether or not your resume a build. Could somebody shortly explain to me what the use case of the functionality that was broken and fixed in this issue is? Is it important that in ghci you can already use imports from the non- broken module imports while other imports are still broken? I'm asking because I'd imagine you'd first fix all imports anyway before you are doing anything sensible in the module, or am I wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 17:13:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 17:13:56 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.8c10bc7531672f8fdb253bc6b4ca966e@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): mpickering, I get a bunch of things that look like this: {{{#!hs Considering inlining: eqTypeRep arg infos [TrivArg, TrivArg] interesting continuation CaseCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [52 128] 210 0 discounted size = 180 ANSWER = NO }}} The continuation, some_benefit, and work-free lines all look good. I don't know how to read the guidance line. Has GHC allowed `eqTypeRep` to get too large to inline in most cases? If its decisions seem reasonable to you and other experienced folks, perhaps we should do something like {{{#!hs typeRepsSame :: forall k1 k2 (a :: k1) (b :: k2). TypeRep a -> TypeRep b -> Bool typeRepsSame a b = typeRepFingerprint a == typeRepFingerprint b eqTypeRep :: forall k1 k2 (a :: k1) (b :: k2). TypeRep a -> TypeRep b -> Maybe (a :~~: b) eqTypeRep a b | typeRepsSame a b = Just (unsafeCoerce# HRefl) | otherwise = Nothing {-# INLINE eqTypeRep #-} }}} inlining a very thin wrapper, but I was surprised enough by the choice that I figured it might point to a more general inlining heuristic problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 21:36:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 21:36:48 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.a0b5f57bc0ffabe81cac692ee46b966f@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * failure: Runtime crash => GHC rejects valid program * architecture: x86_64 (amd64) => Unknown/Multiple Comment: {{{ Compiling with -O avoids the bug , probably a good idea to change the current error message to mention that. On my Mac with 8.4.1 alpha 3 ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.0.20180204 ghc --make LongList.hs [1 of 1] Compiling Main ( LongList.hs, LongList.o ) ghc: sorry! (unimplemented feature or known bug) (GHC version 8.4.0.20180204 for x86_64-apple-darwin): Trying to allocate more than 129024 bytes. This is currently not possible due to a limitation of GHC's code generator. See http://hackage.haskell.org/trac/ghc/ticket/4505 for details. Suggestion: read data from a file instead of having large static data structures in code. bash-3.2$ ghc -O LongList.hs [1 of 1] Compiling Main ( LongList.hs, LongList.o ) Linking LongList ... bash-3.2$ ./LongList 8595 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 21:46:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 21:46:49 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.4f2d23ca58fc5da531503b8eeef3dc79@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * cc: George (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 21:47:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 21:47:53 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.18656b88a6f20d1ed71bfddaff36aaaf@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * os: Linux => Unknown/Multiple * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 21:54:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 21:54:53 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.58ec715a613c781f4ed1a43a2840d1f7@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: thread-local | state, TLS clang Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: 7678 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * priority: high => normal * cc: George (added) Comment: Changing from high to normal priority as it is 5 years olds with no fix in sight and there is a workaround of compiling with GCC which we do for our distributions. If anybody disagrees feel free to put back to high priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 22:13:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 22:13:17 -0000 Subject: [GHC] #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): stack depth overflow In-Reply-To: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> References: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> Message-ID: <067.fad90855c7850801e429e538b84b17ab@haskell.org> #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64 -apple-darwin): stack depth overflow -------------------------------------+------------------------------------- Reporter: iTotallyExist | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: panic! stack | depth overflow Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): I see type of failure is ghci crash, does it fail when compiled and then ran? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 22:24:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 22:24:25 -0000 Subject: [GHC] #14781: Incorrect CPU core counts in virtualized environments In-Reply-To: <048.1dba4d6ac0576664f82c4adab3b77df7@haskell.org> References: <048.1dba4d6ac0576664f82c4adab3b77df7@haskell.org> Message-ID: <063.83b349165e91524702451179e4d1d8da@haskell.org> #14781: Incorrect CPU core counts in virtualized environments -------------------------------------+------------------------------------- Reporter: rtfeldman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by rtfeldman: Old description: > To reproduce this bug: > > 1. Write a program that prints `numCapabilities` (the # of CPU cores the > program thinks are available for parallelization) to stdout > 2. Run this program in a virtualized environment such as Travis CI to see > what it prints > > Expected output: it prints the number of CPU cores available to the > process, which in the case of Travis's virtualized environment is 2. > > Actual output: it prints the number of *physical* cores on the machine, > which in the case of Travis's servers is 32. > > The real-world consequences of this bug manifest for the compiler for the > Elm programming language, which is written in Haskell and compiled with > GHC. By default, `elm-make` runs extremely slowly on Travis and Circle CI > because it's trying to parallelize across 32 cores when only 2 are > actually available to it. > > For a proof-of-concept for how to correctly detect the number of > available cores (as opposed to physical), here is the source code to a > Rust library which does so correctly: > https://github.com/seanmonstar/num_cpus/blob/master/src/lib.rs - the > library distinguishes between "number of CPUs" and "number of physical > CPUs," and on Travis it correctly reports 2 for CPUs and 32 for physical. New description: To reproduce this bug, use the following `main.hs`: {{{#!haskell import Control.Concurrent main = print =<< getNumCapabilities }}} Compile it with `ghc -O2 -threaded --make main.hs -o reproduce` and run `./reproduce` in a virtualized environment such as Travis CI. **Expected output:** it prints the number of CPU cores available to the process, which in the case of Travis's virtualized environment is 2. **Actual output:** it prints the number of *physical* cores on the machine, which in the case of Travis's servers is 32. == Example of Failure on Travis Here is an example build on Travis which demonstrates this failing: (scroll to the end of the console log to see the failure) https://travis- ci.org/rtfeldman/repro-ghc-bug/builds/340268785 Here is the repository which was used to reproduce this failure on Travis: https://github.com/rtfeldman/repro-ghc-bug == Real-World Consequences The real-world consequences of this bug manifest for the compiler for the Elm programming language, which is written in Haskell and compiled with GHC. By default, `elm-make` runs extremely slowly on Travis and Circle CI because it's trying to parallelize across 32 cores when only 2 are actually available to it. == How to Fix For an example implementation which correctly detects the number of available cores (as opposed to physical), here is the source code to a Rust library which does so correctly: https://github.com/seanmonstar/num_cpus/blob/master/src/lib.rs - the library distinguishes between "number of CPUs" and "number of physical CPUs," and on Travis it correctly reports 2 for CPUs and 32 for physical. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 22:31:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 22:31:20 -0000 Subject: [GHC] #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-apple-darwin): stack depth overflow In-Reply-To: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> References: <052.e459cbe75464651b19a5e1a8acf840a7@haskell.org> Message-ID: <067.4dea09b6e6e87ff0ca16be80d72910e1@haskell.org> #14535: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64 -apple-darwin): stack depth overflow -------------------------------------+------------------------------------- Reporter: iTotallyExist | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: panic! stack | depth overflow Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): What is the actual compiler error? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 22:44:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 22:44:32 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.7f3bb82476bf1196134f555228ae8a3d@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 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 mpickering): I think the proposed patch is the wrong idea. What does the core for `eqTypeRep` look like? that will surely resolve any confusion. Looking at the line, {{{ guidance IF_ARGS [52 128] 210 0 discounted size = 180 ANSWER = NO }}} That says that the discount for being applied to known arguments i 52 and 128 for each argument respectively. The 210 is the overall size of the function. If a function is size 80 or less, it is inlined. What I suspect is happening is that `typeRepFingerprint` is inlined into `eqTypeRep` which makes it big. This has some potential benefit as `typeRepFingerprint` is defined as a case but nothing further after that. I think the correct solution is to mark `typeRepFingerprint` as `{-# NOINLINE[0] typeRepFingerprint #-}` so that it might only be inlined in the last phase. It seems that the fact that `eqWord64` is marked as `INLINE` could be part of the problem as there is really no hope that we will resolve the equality of two type fingerprints computed by very complicated expressions. Another solution could be to stop deriving `Eq` for `Fingerprint` and instead hand writing the instance and adding a similar pragma as I suggested above. Could you test how these would work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 11 23:36:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Feb 2018 23:36:39 -0000 Subject: [GHC] #14793: some executables in the binary distribution are not versioned Message-ID: <044.e3ad112799da6f9265ed4760106961ea@haskell.org> #14793: some executables in the binary distribution are not versioned -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC is generally quite careful to play nicely when you install multiple versions, in particular by putting a version number somewhere in the filepath for almost every installed file. Then a few top-level non- versioned symlinks are made to (versioned) executables. Consequently, build tools with enough knowledge of the GHC versioning infrastructure can select an older or newer GHC to build things with by ignoring the top- level symlinks and explicitly selecting the versioned executable names. There are a few exceptions where this is not possible: hsc2hs, hp2ps, and hpc. These executables are *overwritten* on each installation, so it is not possible to select "the one that goes with the currently chosen compiler". I'd like to request that these begin being installed with the same scheme as other GHC executables: with an appended dash and version number, together with a non-versioned symlink. I don't know to what extent this matters for hp2ps and hpc; perhaps these change infrequently enough that it doesn't matter too much. But hsc2hs at least bakes some GHC version knowledge in; it has at least a default template that it #include's that defines some C macros, and this template changes occasionally. There is a command-line option to specify a template filepath explicitly, but it would be nice if build tools could reliably choose a version of hsc2hs that has the right defaults, so that using the command-line flag is a special case for special circumstances. (For some context: I have just finished hunting down an issue related to exactly this. I installed an older GHC to test that some code was backwards-compatible. All of a sudden, existing builds, still using the new compiler, started failing, because hsc2hs was now using an outdated template that did not define all the necessary macros.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 00:56:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 00:56:49 -0000 Subject: [GHC] #14794: -Weverything should not enable -Wmissing-exported-signatures Message-ID: <049.1806d387ab94f5c229447f9562a2a543@haskell.org> #14794: -Weverything should not enable -Wmissing-exported-signatures -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- The `-Weverything` compiler flag enables every compiler warning. That includes `-Wmissing-exported-signatures`, which disables `-Wmissing- signatures` (With `-Wmissing-signatures`, every top-level binding without a signature generates a warning, with `-Wmissing-exported-signatures`, only exported bindings generate a warning). While technically "every warning" includes `-Wmissing-exported- signatures`, I don't think this matches how people use `-Weverything`. At least personally I think of it as "`-Wall` isn't enough, give me the strictest possible warning settings", but actually `-Weverything` can have ''fewer'' warnings than `-Wall` because of `-Wmissing-exported- signatures`. Example reproduction case: {{{ -- Main.hs {-# LANGUAGE Safe #-} module Main (main) where import Prelude (IO, putStrLn, show, ($)) import Foo (foo) main :: IO () main = putStrLn $ show foo }}} {{{ -- Foo.hs {-# LANGUAGE Safe #-} module Foo (foo) where import Prelude (Integer) foo :: Integer foo = bar bar = (1 :: Integer) }}} Expected: when compiling with `-Weverything`, I get a superset of `-Wall`'s warnings. Actual: Actual `-Wall`: {{{ maximiliantagher at Maximilians-MacBook-Pro ~/D/C/H/ghc-warning> ghc -Wall Main.hs Foo.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:10:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: bar :: Integer | 10 | bar = (1 :: Integer) | ^^^ [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... }}} Actual `-Weverything` (note: you should remove run `rm main.o main.hi main Foo.o Foo.hi` in between invocations of the ghc to avoid it using something pre-built): {{{ maximiliantagher at Maximilians-MacBook-Pro ~/D/C/H/ghc-warning> ghc -Weverything Main.hs Foo.hs [1 of 2] Compiling Foo ( Foo.hs, Foo.o ) : warning: [-Wsafe] ‘Foo’ has been inferred as safe! [2 of 2] Compiling Main ( Main.hs, Main.o ) : warning: [-Wsafe] ‘Main’ has been inferred as safe! Linking Main ... }}} (I'm not familiar enough with Safe Haskell to get those warnings to go away—I tried the SafeHaskell pragma but that didn't seem to work. In any case, unrelated to this issue) I tested with these versions: * GHC: The Glorious Glasgow Haskell Compilation System, version 8.2.1 * OS Version: Mac OS 10.13.3 (17D47) (High Sierra) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 07:57:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 07:57:49 -0000 Subject: [GHC] #14609: Per-instance UndecidableInstances In-Reply-To: <048.249a939a6e76cafabb0ae79267f4d3cf@haskell.org> References: <048.249a939a6e76cafabb0ae79267f4d3cf@haskell.org> Message-ID: <063.176824cfc3f4c7a0a5673561a7553287@haskell.org> #14609: Per-instance UndecidableInstances -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.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 AntC): Ooh-er. I've just seen that Type Families also use the `UndecidableInstances` flag. https://downloads.haskell.org/~ghc/8.2.2/docs/html/users_guide/glasgow_exts.html #type-family-decidability The whole idea of making the flag per-instance is that we avoid putting a blanket flag on a whole module. So implementing this ticket needs a per- type-family-instance pragma as well as a per-class-instance(?). Then for Closed Type Families: is that a pragma for the whole family decl, or per- equation? yeuch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 09:40:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 09:40:46 -0000 Subject: [GHC] #14420: Data families should not instantiate to non-Type kinds In-Reply-To: <047.a64d114cfae11861b31f70375118e394@haskell.org> References: <047.a64d114cfae11861b31f70375118e394@haskell.org> Message-ID: <062.7b6d118c6bfa5d8f31ec66ea866cd2f6@haskell.org> #14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 10:46:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 10:46:46 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.cf2eba3d197e3b38a482ed7154cad0a1@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 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 mpickering): I looked at the interface file for `Data.Typeable.Internal` where `eqTypeRep` is defined. Here is the unfolding for `eqTypeRep`. {{{ 855825a70951c01dfa45bc3067373660 eqTypeRep :: forall k1 k2 (a :: k1) (b :: k2). TypeRep a -> TypeRep b -> Maybe (a :~~: b) {- Arity: 2, Strictness: , Unfolding: (\ @ k1 @ k2 @ a :: k1 @ b :: k2 (a1 :: TypeRep a) (b1 :: TypeRep b) -> let { $j :: Word# -> Word# -> Maybe (a :~~: b) {- Arity: 2, Strictness: -} = \ (dt :: Word#)[OneShot] (dt1 :: Word#)[OneShot] -> case b1 of wild { TrType co co1 -> case fpTYPELiftedRep of wild1 { Fingerprint dt2 dt3 -> case eqWord# dt dt2 of lwild { DEFAULT -> Nothing @ (a :~~: b) 1# -> case eqWord# dt1 dt3 of lwild1 { DEFAULT -> Nothing @ (a :~~: b) 1# -> eqTypeRep1 @ k1 @ a @ k2 @ b } } } TrTyCon dt2 dt3 ds ds1 ds2 -> case eqWord# dt dt2 of lwild { DEFAULT -> Nothing @ (a :~~: b) 1# -> case eqWord# dt1 dt3 of lwild1 { DEFAULT -> Nothing @ (a :~~: b) 1# -> eqTypeRep1 @ k1 @ a @ k2 @ b } } TrApp k4 a2 b2 co dt2 dt3 ds ds1 ds2 -> case eqWord# dt dt2 of lwild { DEFAULT -> Nothing @ (a :~~: b) 1# -> case eqWord# dt1 dt3 of lwild1 { DEFAULT -> Nothing @ (a :~~: b) 1# -> eqTypeRep1 @ k1 @ a @ k2 @ b } } TrFun r1 r2 a2 b2 co co1 dt2 dt3 ds ds1 -> case eqWord# dt dt2 of lwild { DEFAULT -> Nothing @ (a :~~: b) 1# -> case eqWord# dt1 dt3 of lwild1 { DEFAULT -> Nothing @ (a :~~: b) 1# -> eqTypeRep1 @ k1 @ a @ k2 @ b } } } } in case a1 of wild { TrType co co1 -> case fpTYPELiftedRep of wild1 { Fingerprint dt dt1 -> $j dt dt1 } TrTyCon dt dt1 ds ds1 ds2 -> $j dt dt1 TrApp k4 a2 b2 co dt dt1 ds ds1 ds2 -> $j dt dt1 TrFun r1 r2 a2 b2 co co1 dt dt1 ds ds1 -> $j dt dt1 }) -} }}} It appears that both functions I mentioned above are inlined (to no great effect) which make the definition quite large. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 12:05:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 12:05:43 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.9e63e5104ecf23eba074d2afbb44493e@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): mpickering, I'm happy to try it other ways, but there are a few things I don't understand: 1. What exactly do you think is wrong with the way I did it? I know it's not perfect (see point 3) but I don't know what ''you'' dislike about it. 2. How will the phased `NOINLINE`(s) you suggest reduce the size of the `eqTypeRep` unfolding? 3. While we don't ''generally'. want to inline the case expressions scrutinizing the arguments, we presumably ''do'' want to optimize the common case where ''one'' of those arguments is completely known at compile time (such as the `typeRep @Int` in my example). How does this desire fit into the rest of the program? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 12:38:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 12:38:16 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.8473d636662a7de7f2b6233bd51285d2@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 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 mpickering): Without a proper analysis of why the problem occurred in the first place, it can't be evaluated why the fix works at all or whether it is correct. Adding an `INLINE` pragma is a very big commitment when there is already a reason that the function is not inlined. Why is the wrapper necessary in addition to the pragma? I think you are right thought that the `NOINLINE[0]` pragmas I suggested won't make a difference to the unfolding. So perhaps just adding an `INLINABLE` pragma is the correct solution? I don't understand your 3rd point. There doesn't appear to be much advantage at all of knowing either argument as the quality condition will seemingly never simplify further? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 13:09:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 13:09:20 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.52767296048b502c84da29612ac4e779@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Adding an `INLINE` pragma to a wrapper is exactly what GHC does in its worker/wrapper transformation, so I don't think it's too big a commitment. My third point is that if we know one of the arguments at compile time, we only need to inspect the other one at run time. There's no real need to follow a pointer to get the fingerprint of `Int`; we already know it! It's just constant folding. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 13:31:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 13:31:27 -0000 Subject: [GHC] #14668: Ordering of declarations can cause typechecking to fail In-Reply-To: <050.d042aa520b7fcde791e49a2b284676e9@haskell.org> References: <050.d042aa520b7fcde791e49a2b284676e9@haskell.org> Message-ID: <065.c2ed61c6273dc530cd5f54b681d8a476@haskell.org> #14668: Ordering of declarations can cause typechecking to fail -------------------------------------+------------------------------------- Reporter: heptahedron | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): Hi! Yet another example which seems related! If you move the data declaration to be the first line, it compiles fine: {{{ {-# LANGUAGE TypeInType #-} module Type.Data.Map where import Prelude import Data.Kind type family KeyKind (obj :: Type) :: Type type family ValKind (obj :: Type) :: Type type family Get (key :: KeyKind a) (obj :: a) :: ValKind a data Map (k :: Type) (v :: Type) = Map [(k,v)] type instance Get k ('Map ('(k,v) ': _)) = v type instance KeyKind (Map k v) = k type instance ValKind (Map k v) = v }}} Otherwise it gives error: {{{ Main.hs:16:19: error: • Occurs check: cannot construct the infinite kind: k0 ~ KeyKind (Map k0 v0) The type variables ‘v0’, ‘k0’ are ambiguous • In the first argument of ‘Get’, namely ‘k’ In the type instance declaration for ‘Get’ | 16 | type instance Get k ('Map ('(k,v) ': _)) = v | ^ Main.hs:16:44: error: • Occurs check: cannot construct the infinite kind: v0 ~ ValKind (Map k0 v0) The type variables ‘k0’, ‘v0’ are ambiguous • In the type ‘v’ In the type instance declaration for ‘Get’ | 16 | type instance Get k ('Map ('(k,v) ': _)) = v }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 14:18:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 14:18:32 -0000 Subject: [GHC] #14795: Data type return kinds don't obey the forall-or-nothing rule Message-ID: <050.173b7cb4e41b62bd0d9860f7bdb12f92@haskell.org> #14795: Data type return kinds don't obey the forall-or-nothing rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: TypeInType | 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: -------------------------------------+------------------------------------- Originally noticed [https://github.com/ghc-proposals/ghc- proposals/pull/103#issuecomment-364562974 here]. GHC accepts this: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} import Data.Kind data Foo :: forall a. a -> b -> Type where MkFoo :: a -> Foo a b }}} Despite the fact that `Foo`'s return kind is headed by an explicit `forall` which does not quantify `b`. The users' guide doesn't explicitly indicate that the `forall`-or-nothing rule should apply to data type return kinds, but goldfirere believes that not doing so is an [https://github.com/ghc-proposals/ghc- proposals/pull/103#issuecomment-364670215 inconsistent design], so I'm opening this ticket to track this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 14:30:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 14:30:29 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.acae28c3671716f95068256be6dbebc5@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Hmmm... Actually, that constant folding notion is complicated by the fact that the `TypeRep` builders won't inline to expose the fingerprints anyway, thanks to recursion. Should we `INLINE` the wrapper function as I proposed, and just `NOINLINE` the worker? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 14:34:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 14:34:13 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.83184aef16f56968ddd4d9880317486c@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 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 mpickering): I still don't understand why you need the wrapper. Adding an `INLINABLE` pragma seems to be the least invasive way to fix this issue? Did you try that yet? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 14:44:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 14:44:49 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.7d35de69f92258c761126378b7f9e429@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): No, not yet. I'll do that later today if you like. But I also don't really understand what that will accomplish. `INLINABLE` tells GHC to make an unfolding. But GHC already makes an unfolding; it just doesn't use it. Does `INLINABLE` change what unfolding it makes? The purpose of the wrapper is to use the fact that we know more about what information will be available/useful at typical `eqTypeRep` call sites than the compiler does; we therefore have a better sense of which part will actually be useful to inline. If we inline the whole thing as it stands, then the call site will get two calls to `typeRepFingerprint` and a call to `==`. That's certainly larger than a call to `sameTypeRep`; is it also better in enough cases to matter? I don't know. On the other hand, I know that in virtually all realistic cases we want to use inlining to eliminate the `Maybe` business. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 15:41:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 15:41:19 -0000 Subject: [GHC] #14510: GHC.ExecutionStack.showStackTrace broken In-Reply-To: <043.9685830b69e2246f2b96ccff19455218@haskell.org> References: <043.9685830b69e2246f2b96ccff19455218@haskell.org> Message-ID: <058.66f5fa5b136af5d24251fc72dc326428@haskell.org> #14510: GHC.ExecutionStack.showStackTrace broken ---------------------------------+-------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | ---------------------------------+-------------------------------------- Changes (by niteria): * cc: niteria (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 16:12:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 16:12:01 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.1288ceb8a6fb2990acd51546cfe4344c@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: AndreasK Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T14619 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4348 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * testcase: => T14619 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 16:34:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 16:34:09 -0000 Subject: [GHC] #14796: Pretty-printer bug Message-ID: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> #14796: Pretty-printer bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From Ryan's [https://ryanglscott.github.io/2018/02/11/how-to-derive- generic-for-some-gadts/ How to derive Generic for (some) GADTs using QuantifiedConstraints]: {{{#!hs data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a }}} When instantiating types using `-XTypeApplications` something weird happens {{{ $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications Prelude> data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a Prelude> :t ECC @[] @() @() ECC @[] @() @() :: [()] -> ECC () :: Constraint [] () }}} Doesn't seem to happen in other cases: {{{ Prelude> :t ECC @[] @() @((), ()) ECC @[] @() @((), ()) :: [()] -> ECC (() :: Constraint, () :: Constraint) [] () Prelude> :t ECC @[] @() @(Eq Int) ECC @[] @() @(Eq Int) :: [()] -> ECC (Eq Int) [] () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 16:34:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 16:34:38 -0000 Subject: [GHC] #14796: Pretty-printer bug In-Reply-To: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> References: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> Message-ID: <066.ea6fa5cd244ed72f6b24200e77f6bdf7@haskell.org> #14796: Pretty-printer bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: 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: Old description: > From Ryan's [https://ryanglscott.github.io/2018/02/11/how-to-derive- > generic-for-some-gadts/ How to derive Generic for (some) GADTs using > QuantifiedConstraints]: > > {{{#!hs > data ECC ctx f a where > ECC :: ctx => f a -> ECC ctx f a > }}} > > When instantiating types using `-XTypeApplications` something weird > happens > > {{{ > $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci > GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help > Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications > Prelude> data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a > Prelude> :t ECC @[] @() @() > ECC @[] @() @() :: [()] -> ECC () :: Constraint [] () > }}} > > Doesn't seem to happen in other cases: > > {{{ > Prelude> :t ECC @[] @() @((), ()) > ECC @[] @() @((), ()) > :: [()] -> ECC (() :: Constraint, () :: Constraint) [] () > > Prelude> :t ECC @[] @() @(Eq Int) > ECC @[] @() @(Eq Int) :: [()] -> ECC (Eq Int) [] () > }}} New description: From Ryan's [https://ryanglscott.github.io/2018/02/11/how-to-derive- generic-for-some-gadts/ How to derive Generic for (some) GADTs using QuantifiedConstraints]: {{{#!hs data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a }}} When instantiating the `Constraint` using `-XTypeApplications` something weird happens {{{ $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications Prelude> data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a Prelude> :t ECC @[] @() @() ECC @[] @() @() :: [()] -> ECC () :: Constraint [] () }}} Doesn't seem to happen in other cases: {{{ Prelude> :t ECC @[] @() @((), ()) ECC @[] @() @((), ()) :: [()] -> ECC (() :: Constraint, () :: Constraint) [] () Prelude> :t ECC @[] @() @(Eq Int) ECC @[] @() @(Eq Int) :: [()] -> ECC (Eq Int) [] () }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 16:45:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 16:45:17 -0000 Subject: [GHC] #14796: Pretty-printer bug In-Reply-To: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> References: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> Message-ID: <066.1bf6646888eb761c8f1473da2d2050de@haskell.org> #14796: Pretty-printer bug -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: 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): Ryan had trouble reproducing it so here it is for 8.2.1 {{{ $ ghci-8.2.1 -ignore-dot-ghci GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications Prelude> data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a Prelude> :t ECC @() @[] @() ECC @() @[] @() :: [()] -> ECC () :: Constraint [] () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 16:47:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 16:47:43 -0000 Subject: [GHC] #14796: Pretty Printing: GHC doesn't parenthesise (() :: Constraint) (was: Pretty-printer bug) In-Reply-To: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> References: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> Message-ID: <066.4aeb0f7b5818b9cc566ecb58e07ac47a@haskell.org> #14796: Pretty Printing: GHC doesn't parenthesise (() :: Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: TypeApplications (removed) * cc: Calanz (added) * keywords: => TypeApplications Old description: > From Ryan's [https://ryanglscott.github.io/2018/02/11/how-to-derive- > generic-for-some-gadts/ How to derive Generic for (some) GADTs using > QuantifiedConstraints]: > > {{{#!hs > data ECC ctx f a where > ECC :: ctx => f a -> ECC ctx f a > }}} > > When instantiating the `Constraint` using `-XTypeApplications` something > weird happens > > {{{ > $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci > GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help > Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications > Prelude> data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a > Prelude> :t ECC @[] @() @() > ECC @[] @() @() :: [()] -> ECC () :: Constraint [] () > }}} > > Doesn't seem to happen in other cases: > > {{{ > Prelude> :t ECC @[] @() @((), ()) > ECC @[] @() @((), ()) > :: [()] -> ECC (() :: Constraint, () :: Constraint) [] () > > Prelude> :t ECC @[] @() @(Eq Int) > ECC @[] @() @(Eq Int) :: [()] -> ECC (Eq Int) [] () > }}} New description: From Ryan's [https://ryanglscott.github.io/2018/02/11/how-to-derive- generic-for-some-gadts/ How to derive Generic for (some) GADTs using QuantifiedConstraints]: {{{#!hs data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a }}} When instantiating the `Constraint` using `-XTypeApplications` with the empty constraint, GHC doesn't add parenthesis (it should look like `... -> ECC (() :: Constraint) [] ()`) {{{ $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications Prelude> data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a Prelude> :t ECC @[] @() @() ECC @[] @() @() :: [()] -> ECC () :: Constraint [] () }}} Doesn't seem to happen in other cases: {{{ Prelude> :t ECC @[] @() @((), ()) ECC @[] @() @((), ()) :: [()] -> ECC (() :: Constraint, () :: Constraint) [] () Prelude> :t ECC @[] @() @(Eq Int) ECC @[] @() @(Eq Int) :: [()] -> ECC (Eq Int) [] () }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 16:47:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 16:47:50 -0000 Subject: [GHC] #11671: Allow labels starting with uppercase with OverloadedLabels In-Reply-To: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> References: <044.a0bb36a4fb997b6415af764b9c7b0bc1@haskell.org> Message-ID: <059.7193bf1b887954efd99238082d835517@haskell.org> #11671: Allow labels starting with uppercase with OverloadedLabels -------------------------------------+------------------------------------- Reporter: inaki | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (Parser) | Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dwincort): Just to bump this, I also have a use case for labels starting with uppercase letters. Specifically, in the same way that overloaded labels have been used for record field selectors (lenses), my group is trying to use ones that start with uppercase letters for constructor selectors (prisms). Although the ability to use them in patterns would be great, this is truly a separate issue, and we have uses for just the prisms (for example, as handlers in the foldl package [https://hackage.haskell.org/package/foldl]). Right now, we have a hack where overloaded labels starting with `_` are treated as prisms, and we write, e.g., `#_Foo` to get the prism for the constructor `Foo`. Not only is this ugly, but it means that any record fields starting with `_` are turned into prisms instead of lenses. Having labels that can start with uppercase letters would fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 16:48:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 16:48:11 -0000 Subject: [GHC] #14796: Pretty Printing: GHC doesn't parenthesise (() :: Constraint) In-Reply-To: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> References: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> Message-ID: <066.8ab9ac879412dce96c3fc6d1ddc56760@haskell.org> #14796: Pretty Printing: GHC doesn't parenthesise (() :: Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: Calanz (removed) * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 16:54:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 16:54:29 -0000 Subject: [GHC] #14796: Pretty Printing: GHC doesn't parenthesise (() :: Constraint) In-Reply-To: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> References: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> Message-ID: <066.e970adb88887318362959381399ff73c@haskell.org> #14796: Pretty Printing: GHC doesn't parenthesise (() :: Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > From Ryan's [https://ryanglscott.github.io/2018/02/11/how-to-derive- > generic-for-some-gadts/ How to derive Generic for (some) GADTs using > QuantifiedConstraints]: > > {{{#!hs > data ECC ctx f a where > ECC :: ctx => f a -> ECC ctx f a > }}} > > When instantiating the `Constraint` using `-XTypeApplications` with the > empty constraint, GHC doesn't add parenthesis (it should look like `... > -> ECC (() :: Constraint) [] ()`) > > {{{ > $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci > GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help > Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications > Prelude> data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a > Prelude> :t ECC @[] @() @() > ECC @[] @() @() :: [()] -> ECC () :: Constraint [] () > }}} > > Doesn't seem to happen in other cases: > > {{{ > Prelude> :t ECC @[] @() @((), ()) > ECC @[] @() @((), ()) > :: [()] -> ECC (() :: Constraint, () :: Constraint) [] () > > Prelude> :t ECC @[] @() @(Eq Int) > ECC @[] @() @(Eq Int) :: [()] -> ECC (Eq Int) [] () > }}} New description: From Ryan's [https://ryanglscott.github.io/2018/02/11/how-to-derive- generic-for-some-gadts/ How to derive Generic for (some) GADTs using QuantifiedConstraints]: {{{#!hs data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a }}} When instantiating the `Constraint` using `-XTypeApplications` with the empty constraint, GHC doesn't add parentheses (it should look like `... -> ECC (() :: Constraint) [] ()`) {{{ $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications Prelude> data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a Prelude> :t ECC @[] @() @() ECC @[] @() @() :: [()] -> ECC () :: Constraint [] () }}} Doesn't seem to happen in other cases: {{{ Prelude> :t ECC @[] @() @((), ()) ECC @[] @() @((), ()) :: [()] -> ECC (() :: Constraint, () :: Constraint) [] () Prelude> :t ECC @[] @() @(Eq Int) ECC @[] @() @(Eq Int) :: [()] -> ECC (Eq Int) [] () }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 16:56:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 16:56:56 -0000 Subject: [GHC] #14797: High-residency modules during GHC build Message-ID: <047.916b3a5a2bf47612a2c2ec6726c0a648@haskell.org> #14797: High-residency modules during GHC build -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to figure out memory allocation failures on the CI server, I tracked allocations and residency on a per-module basis, and noticed that some modules require a lot more memory to compile than others. I've compiled a digest of the most memory-hungry compilation steps: {{{ "/usr/local/bin/ghc" ... compiler/stage1/build/OptCoercion.o: Max. residency: 991356584 / In use: 2094M "inplace/bin/ghc-stage1" ... compiler/stage2/build/OptCoercion.dyn_o: Max. residency: 714940528 / In use: 1471M "/usr/local/bin/ghc" ... compiler/stage1/build/X86/CodeGen.o: Max. residency: 679947656 / In use: 1497M "inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist- install/build/Distribution/SPDX/LicenseId.dyn_o: Max. residency: 653177496 / In use: 1355M "inplace/bin/ghc-stage1" ... compiler/stage2/build/X86/CodeGen.dyn_o: Max. residency: 641515344 / In use: 1425M "/usr/local/bin/ghc" ... -ilibraries/parsec: Max. residency: 593335568 / In use: 1355M "/usr/local/bin/ghc" ... libraries/Cabal/Cabal/dist- boot/build/Distribution/SPDX/LicenseId.o: Max. residency: 575034968 / In use: 1137M "inplace/bin/ghc-stage1" ... compiler/stage2/build/DynFlags.dyn_o: Max. residency: 402734408 / In use: 1059M "/usr/local/bin/ghc" ... compiler/stage1/build/DynFlags.o: Max. residency: 343154784 / In use: 892M "inplace/bin/ghc-stage1" ... libraries/template-haskell/dist- install/build/Language/Haskell/TH/Syntax.dyn_o: Max. residency: 266744312 / In use: 720M "/usr/local/bin/ghc" ... compiler/stage1/build/Parser.o: Max. residency: 258613584 / In use: 679M "inplace/bin/ghc-stage1" ... compiler/stage2/build/CmmOpt.dyn_o: Max. residency: 254639624 / In use: 568M "inplace/bin/ghc-stage1" ... compiler/stage2/build/Parser.dyn_o: Max. residency: 236774592 / In use: 635M "inplace/bin/ghc-stage1" ... ghc/stage2/build/GHCi/UI.dyn_o: Max. residency: 234055792 / In use: 609M "/usr/local/bin/ghc" ... compiler/stage1/build/HsExpr.o: Max. residency: 233724400 / In use: 657M "/usr/local/bin/ghc" ... compiler/stage1/build/CmmOpt.o: Max. residency: 208378888 / In use: 436M "/usr/local/bin/ghc" ... compiler/stage1/build/HscMain.o: Max. residency: 197177248 / In use: 500M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HsExpr.dyn_o: Max. residency: 192780496 / In use: 521M "inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist- install/build/Distribution/Simple/Setup.dyn_o: Max. residency: 191649952 / In use: 521M "/usr/local/bin/ghc" ... compiler/stage1/build/HsDecls.o: Max. residency: 183441120 / In use: 508M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcSplice.dyn_o: Max. residency: 176802000 / In use: 445M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcRnDriver.dyn_o: Max. residency: 172892128 / In use: 458M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HscMain.dyn_o: Max. residency: 172802688 / In use: 470M "inplace/bin/ghc-stage1" ... libraries/ghci/dist- install/build/GHCi/TH/Binary.dyn_o: Max. residency: 169775368 / In use: 455M "inplace/bin/ghc-stage1" ... compiler/stage2/build/GhcMake.dyn_o: Max. residency: 167305408 / In use: 431M "inplace/bin/ghc-stage1" ... compiler/stage2/build/PrimOp.dyn_o: Max. residency: 162532408 / In use: 455M "/usr/local/bin/ghc" ... compiler/stage1/build/HscTypes.o: Max. residency: 160814736 / In use: 421M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HsDecls.dyn_o: Max. residency: 160445552 / In use: 426M "inplace/bin/ghc-stage1" ... libraries/Cabal/Cabal/dist- install/build/Language/Haskell/Extension.dyn_o: Max. residency: 159817712 / In use: 363M "/usr/local/bin/ghc" ... compiler/stage1/build/TcSplice.o: Max. residency: 156738656 / In use: 375M "/usr/local/bin/ghc" ... compiler/stage1/build/TcRnDriver.o: Max. residency: 153910768 / In use: 421M "inplace/bin/ghc-stage1" ... libraries/containers/dist- install/build/Data/Sequence/Internal.dyn_o: Max. residency: 151318224 / In use: 405M "inplace/bin/ghc-stage1" ... compiler/stage2/build/MatchLit.dyn_o: Max. residency: 150681176 / In use: 382M "/usr/local/bin/ghc" ... compiler/stage1/build/ByteCodeGen.o: Max. residency: 144579176 / In use: 389M "/usr/local/bin/ghc" ... compiler/stage1/build/GhcMake.o: Max. residency: 144411312 / In use: 379M "/usr/local/bin/ghc" ... compiler/stage1/build/MatchLit.o: Max. residency: 142596736 / In use: 382M "inplace/bin/ghc-stage1" ... compiler/stage2/build/StgCmmPrim.dyn_o: Max. residency: 141484616 / In use: 340M "inplace/bin/ghc-stage1" ... libraries/ghci/dist- install/build/GHCi/Message.dyn_o: Max. residency: 139224136 / In use: 363M "/usr/local/bin/ghc" ... compiler/stage1/build/StgCmmPrim.o: Max. residency: 137390744 / In use: 346M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcExpr.dyn_o: Max. residency: 136387128 / In use: 370M "inplace/bin/ghc-stage1" ... compiler/stage2/build/Lexer.dyn_o: Max. residency: 135228120 / In use: 337M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcTyClsDecls.dyn_o: Max. residency: 134817024 / In use: 369M "/usr/local/bin/ghc" ... compiler/stage1/build/MkIface.o: Max. residency: 134039144 / In use: 339M "inplace/bin/ghc-stage1" ... compiler/stage2/build/RnExpr.dyn_o: Max. residency: 133947600 / In use: 345M "inplace/bin/ghc-stage1" ... compiler/stage2/build/HscTypes.dyn_o: Max. residency: 133938840 / In use: 366M "inplace/bin/ghc-stage1" ... compiler/stage2/build/TcGenDeriv.dyn_o: Max. residency: 133744056 / In use: 320M "/usr/local/bin/ghc" ... compiler/stage1/build/TcExpr.o: Max. residency: 131766896 / In use: 336M "inplace/bin/ghc-stage1" ... compiler/stage2/build/GHC.dyn_o: Max. residency: 130998912 / In use: 277M "inplace/bin/ghc-stage1" ... compiler/stage2/build/ByteCodeGen.dyn_o: Max. residency: 129499464 / In use: 348M "inplace/bin/ghc-stage1" ... compiler/stage2/build/InteractiveEval.dyn_o: Max. residency: 128902944 / In use: 286M }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 17:09:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 17:09:28 -0000 Subject: [GHC] #14798: Error message suggests applying (non-existant) function to more arguments Message-ID: <051.604bcd0d6b206658c5ced28f530a3b3b@haskell.org> #14798: Error message suggests applying (non-existant) function to more arguments -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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: -------------------------------------+------------------------------------- Applying a constraint that doesn't hold fails, this is expected {{{ $ ~/code/qc-ghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Prelude> :set -XGADTs -XConstraintKinds -XTypeApplications Prelude> data Dict c where Dict :: c => Dict c Prelude> data A Prelude> :t Dict @(Eq A) :1:1: error: No instance for (Eq A) arising from a use of ‘Dict’ }}} but for `(Eq (Int -> Int))` GHC additionally suggests maybe applying a function (what function?) to more arguments {{{ Prelude> :t Dict @(Eq (Int -> Int)) :1:1: error: No instance for (Eq (Int -> Int)) arising from a use of ‘Dict’ (maybe you haven't applied a function to enough arguments?) Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 17:29:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 17:29:38 -0000 Subject: [GHC] #14798: Error message suggests applying (non-existant) function to more arguments In-Reply-To: <051.604bcd0d6b206658c5ced28f530a3b3b@haskell.org> References: <051.604bcd0d6b206658c5ced28f530a3b3b@haskell.org> Message-ID: <066.916bac06b4b63ea7e77f4698f3edb122@haskell.org> #14798: Error message suggests applying (non-existant) function to more arguments -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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 goldfire): This makes sense to me: the user might have written something like `pow 5 == 10` where `pow :: Int -> Int -> Int`. Of course, the error message is silly in your case, but I think it would be useful in the common case and is phrased appropriately so be wrong sometimes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 17:53:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 17:53:45 -0000 Subject: [GHC] #14787: Remove StgLint type checks In-Reply-To: <043.b42d9efeb50c0ccd29b8b0185debbec2@haskell.org> References: <043.b42d9efeb50c0ccd29b8b0185debbec2@haskell.org> Message-ID: <058.f3998531f9ac62a3e76a5e0a48051811@haskell.org> #14787: Remove StgLint type checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 18:05:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 18:05:52 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.f03ab6282c5a17727a5a4ec143175480@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. I've pushed my refactoring of `NthCo` to the branch we've been working on. But I'm unsure the current state of affairs for the Phab stuff, so I didn't upload there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 18:39:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 18:39:31 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.7d567201379a476ef48fddf9024d8d6f@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508, DeterministicBuilds | Phab:D4388 -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268, Phab:D1360, Phab:D1373, Phab:D1396, Phab:D1457, Phab:D1468, Phab:D1487, Phab:D1504, Phab:D1508 => Phab:D910, Phab:D1073, Phab:D1133, Phab:D1192, Phab:D1268, Phab:D1360, Phab:D1373, Phab:D1396, Phab:D1457, Phab:D1468, Phab:D1487, Phab:D1504, Phab:D1508, Phab:D4388 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 18:40:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 18:40:00 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.86ad6b9eb31b41d521e0137ec2fac3d0@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4388 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: => Phab:D4388 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 19:10:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 19:10:27 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.12f192ced933a262eb936e05cc59a473@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4388 Wiki Page: | -------------------------------------+------------------------------------- Comment (by shlevy): D4388 fixes some of this, by removing non-determinism in cost centre symbol names (which caused linking errors when doing distributed builds with nix). A unique was replaced with a 0-based index that increments in source location order for a given module, cost centre name, and cost centre type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 19:10:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 19:10:53 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.127d126ed4aea741f2215664fa723598@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, | Phab:D1396, Phab:D1457, Phab:D1468, Wiki Page: | Phab:D1487, Phab:D1504, Phab:D1508, DeterministicBuilds | Phab:D4388 -------------------------------------+------------------------------------- Comment (by shlevy): D4388 chips away at more of this, by removing non-determinism in cost centre symbol names (which caused linking errors when doing distributed builds with nix). A unique was replaced with a 0-based index that increments in source location order for a given module, cost centre name, and cost centre type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 19:41:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 19:41:54 -0000 Subject: [GHC] #14799: QuantifiedConstraints: Problems with Typeable Message-ID: <051.12e070493552ed2932e8381c578bd458@haskell.org> #14799: QuantifiedConstraints: Problems with Typeable -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This compiles {{{#!hs {-# Language GADTs, ConstraintKinds, ScopedTypeVariables, QuantifiedConstraints #-} import Data.Typeable data Ex cls where MkEx :: cls xx => xx -> Ex cls a :: Ex Typeable -> TypeRep a (MkEx (_::xx)) = typeRep @_ @xx Proxy -- b :: (forall xx. cls xx => Typeable xx) => Ex cls -> TypeRep -- b (MkEx (_::xx)) = typeRep @_ @xx Proxy c :: (forall xx. cls xx => Show xx) => Ex cls -> String c (MkEx xx) = show xx }}} but uncommenting `b` is too much: {{{ $ qc hs/189-bug.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/189-bug.hs, interpreted ) hs/189-bug.hs:12:20: error: • Could not deduce (Typeable xx) arising from a use of ‘typeRep’ from the context: forall xx. cls xx => Typeable xx bound by the type signature for: b :: forall (cls :: * -> Constraint). (forall xx. cls xx => Typeable xx) => Ex cls -> TypeRep at hs/189-bug.hs:11:1-60 or from: cls xx bound by a pattern with constructor: MkEx :: forall xx (cls :: * -> Constraint). cls xx => xx -> Ex cls, in an equation for ‘b’ at hs/189-bug.hs:12:4-15 • In the expression: typeRep @_ @xx Proxy In an equation for ‘b’: b (MkEx (_ :: xx)) = typeRep @_ @xx Proxy | 12 | b (MkEx (_::xx)) = typeRep @_ @xx Proxy | ^^^^^^^^^^^^^^^^^^^^ Failed, no modules loaded. Prelude> }}} This is maybe because of the `Typeable` solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 19:48:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 19:48:03 -0000 Subject: [GHC] #14799: QuantifiedConstraints: Problems with Typeable In-Reply-To: <051.12e070493552ed2932e8381c578bd458@haskell.org> References: <051.12e070493552ed2932e8381c578bd458@haskell.org> Message-ID: <066.41adf8c6f525fd46c458f9f7ba0f8bfa@haskell.org> #14799: QuantifiedConstraints: Problems with Typeable -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): It works by creating a class alias for `Typeable` {{{#!hs class Typeable a => Typeable' a where typeRep' :: proxy a -> TypeRep typeRep' proxy = typeRep proxy instance Typeable a => Typeable' a b :: (forall xx. cls xx => Typeable' xx) => Ex cls -> TypeRep b (MkEx (_::xx)) = typeRep' @_ @xx Proxy }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 20:07:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 20:07:02 -0000 Subject: [GHC] #14800: -Wincomplete-uni-patterns should not warn about explicitly-marked irrefutable patterns Message-ID: <048.f1cc7f2dd7fc286b18d0288bb40c2d60@haskell.org> #14800: -Wincomplete-uni-patterns should not warn about explicitly-marked irrefutable patterns -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is very useful to catch accidentally partial uni-pattern matches: Cons x = someVal However, we explicitly want an irrefutable pattern match: Vector2 0 y = Vector2 0 a `op` Vector2 0 b In this case, it would be really useful to opt out of the warning via: ~(Vector2 0 y) = ... The fact the match is partial is explicit and visible with the ~ syntax, so the warning shouldn't tell us about it. Right now this warning rules out this useful way of opting in to partiality. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 21:02:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 21:02:24 -0000 Subject: [GHC] #14781: getNumCapabilities produces incorrect CPU counts (was: Incorrect CPU core counts in virtualized environments) In-Reply-To: <048.1dba4d6ac0576664f82c4adab3b77df7@haskell.org> References: <048.1dba4d6ac0576664f82c4adab3b77df7@haskell.org> Message-ID: <063.d8e7d0dce511e3c5119860cfbf0617e9@haskell.org> #14781: getNumCapabilities produces incorrect CPU counts -------------------------------------+------------------------------------- Reporter: rtfeldman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 22:29:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 22:29:13 -0000 Subject: [GHC] #14801: Multiple error messages confusing. Message-ID: <047.a54e5e940cf352b518d16938b14ad78f@haskell.org> #14801: Multiple error messages confusing. -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- More often than not, ghc reports very confusing errors when you use an undefined (lens) variable. The problem is that an undefined identifier generates subsequent type errors, and some of these type errors might be reported before the undefined message. When the error list has hundreds of messages it can be very time consuming to find the real error. Please add an error reporting mode that does not report type errors when there are undefined variables. Here's a sample message: {{{ tests/OneDUram.hs:160:5: error: • Couldn't match type ‘(Vec NumRegFiles (DelayReg.DelayReg 2 OneDUValues) -> f0 (Vec NumRegFiles (DelayReg.DelayReg 2 OneDUValues))) -> OneDUState -> f0 OneDUState’ with ‘Vec n1 a0’ Expected type: Vec n1 a0 Actual type: LensLike' f0 OneDUState (Vec NumRegFiles (DelayReg.DelayReg 2 OneDUValues)) • Probable cause: ‘osRegFileBP’ is applied to too few arguments In the first argument of ‘(^.)’, namely ‘osRegFileBP’ In the first argument of ‘(.~)’, namely ‘osRegFileBP ^. ix 0 . atDelay 1’ In the second argument of ‘(&)’, namely ‘osRegFileBP ^. ix 0 . atDelay 1 .~ fromList (mkTensor val "r0" [8])’ | 160 | & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8]) | ^^^^^^^^^^^ tests/OneDUram.hs:160:23: error: Variable not in scope: atDelay :: Integer -> (LensLike f OneDUState OneDUState b0 (Vec n0 OneDUValue) -> Constant (LensLike f OneDUState OneDUState b0 (Vec n0 OneDUValue)) b'0) -> a0 -> Constant (LensLike f OneDUState OneDUState b0 (Vec n0 OneDUValue)) a0 | 160 | & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8]) | ^^^^^^^ tests/OneDUram.hs:160:36: error: • No instance for (GHC.TypeNats.KnownNat n0) arising from a use of ‘fromList’ • In the second argument of ‘(.~)’, namely ‘fromList (mkTensor val "r0" [8])’ In the second argument of ‘(&)’, namely ‘osRegFileBP ^. ix 0 . atDelay 1 .~ fromList (mkTensor val "r0" [8])’ In the expression: oneDU & osDbgInstrs .~ Just instrs2 & osRegFileBP ^. ix 0 . atDelay 1 .~ fromList (mkTensor val "r0" [8]) | 160 | & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8]) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I only want to see the second message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 22:31:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 22:31:52 -0000 Subject: [GHC] #14801: Multiple error messages confusing. In-Reply-To: <047.a54e5e940cf352b518d16938b14ad78f@haskell.org> References: <047.a54e5e940cf352b518d16938b14ad78f@haskell.org> Message-ID: <062.4092c883583cacc986b3176fa4af33a5@haskell.org> #14801: Multiple error messages confusing. -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by augustss: Old description: > More often than not, ghc reports very confusing errors when you use an > undefined (lens) variable. The problem is that an undefined identifier > generates subsequent type errors, and some of these type errors might be > reported before the undefined message. When the error list has hundreds > of messages it can be very time consuming to find the real error. > > Please add an error reporting mode that does not report type errors when > there are undefined variables. > > Here's a sample message: > > {{{ > tests/OneDUram.hs:160:5: error: > • Couldn't match type ‘(Vec > NumRegFiles (DelayReg.DelayReg 2 > OneDUValues) > -> f0 (Vec NumRegFiles (DelayReg.DelayReg 2 > OneDUValues))) > -> OneDUState -> f0 OneDUState’ > with ‘Vec n1 a0’ > Expected type: Vec n1 a0 > Actual type: LensLike' > f0 OneDUState (Vec NumRegFiles (DelayReg.DelayReg > 2 OneDUValues)) > • Probable cause: ‘osRegFileBP’ is applied to too few arguments > In the first argument of ‘(^.)’, namely ‘osRegFileBP’ > In the first argument of ‘(.~)’, namely > ‘osRegFileBP ^. ix 0 . atDelay 1’ > In the second argument of ‘(&)’, namely > ‘osRegFileBP ^. ix 0 . atDelay 1 > .~ fromList (mkTensor val "r0" [8])’ > | > 160 | & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8]) > | ^^^^^^^^^^^ > > tests/OneDUram.hs:160:23: error: > Variable not in scope: > atDelay > :: Integer > -> (LensLike f OneDUState OneDUState b0 (Vec n0 OneDUValue) > -> Constant > (LensLike f OneDUState OneDUState b0 (Vec n0 > OneDUValue)) b'0) > -> a0 > -> Constant > (LensLike f OneDUState OneDUState b0 (Vec n0 OneDUValue)) > a0 > | > 160 | & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8]) > | ^^^^^^^ > > tests/OneDUram.hs:160:36: error: > • No instance for (GHC.TypeNats.KnownNat n0) > arising from a use of ‘fromList’ > • In the second argument of ‘(.~)’, namely > ‘fromList (mkTensor val "r0" [8])’ > In the second argument of ‘(&)’, namely > ‘osRegFileBP ^. ix 0 . atDelay 1 > .~ fromList (mkTensor val "r0" [8])’ > In the expression: > oneDU & osDbgInstrs .~ Just instrs2 > & osRegFileBP ^. ix 0 . atDelay 1 > .~ fromList (mkTensor val "r0" [8]) > | > 160 | & osRegFileBP^.ix 0.atDelay 1 .~ fromList (mkTensor val "r0" [8]) > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > }}} > > I only want to see the second message. New description: More often than not, ghc reports very confusing errors when you use an undefined (lens) variable. The problem is that an undefined identifier generates subsequent type errors, and some of these type errors might be reported before the undefined message. When the error list has hundreds of messages it can be very time consuming to find the real error. Please add an error reporting mode that does not report type errors when there are undefined variables. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 23:27:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 23:27:55 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.07f16b09c50fd4c4fd1db968127d7390@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 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:D4405 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4405 Comment: mpickering, it looks like writing the wrapper and marking it `INLINABLE` does the trick. I wish I had a better sense of ''why'' `INLINABLE` does that, but okay. I also don't really understand why this wrapper should be `INLINABLE`, whereas the wrappers GHC manufactures are `INLINE`. What difference merits that distinction? Nevertheless, I've updated the differential to use `INLINABLE` instead, and added some comments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 12 23:54:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Feb 2018 23:54:45 -0000 Subject: [GHC] #14801: Multiple error messages confusing. In-Reply-To: <047.a54e5e940cf352b518d16938b14ad78f@haskell.org> References: <047.a54e5e940cf352b518d16938b14ad78f@haskell.org> Message-ID: <062.21a43f87039c448dbd89a13de3ea4890@haskell.org> #14801: Multiple error messages confusing. -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Comment: Do you have an example of code that exhibits these symptoms? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 00:01:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 00:01:00 -0000 Subject: [GHC] #14668: Ordering of declarations can cause typechecking to fail In-Reply-To: <050.d042aa520b7fcde791e49a2b284676e9@haskell.org> References: <050.d042aa520b7fcde791e49a2b284676e9@haskell.org> Message-ID: <065.79a6bc7a41fe69eb01f977e3c06f0e63@haskell.org> #14668: Ordering of declarations can cause typechecking to fail -------------------------------------+------------------------------------- Reporter: heptahedron | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): What is even worse, this bug prevents us from refactoring the code to separate module, so I have to have the `Get` declaration in he same file, under all data definitions that are used to make instances of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 00:15:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 00:15:49 -0000 Subject: [GHC] #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? In-Reply-To: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> References: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> Message-ID: <065.965c015b2a45259b991b013dd3e4aacd@haskell.org> #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: deriving, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4402 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 01:32:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 01:32:42 -0000 Subject: [GHC] #14802: panic! (the 'impossible' happened) Message-ID: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> #14802: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Debugging) | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was debugging and tried to print a matrix but got the following error message: :34:21: error:: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: a1_IhXR[rt] Has this been fixed in the newer version of ghc? If so, what's the fastest way to update? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 01:40:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 01:40:44 -0000 Subject: [GHC] #14802: panic! (the 'impossible' happened) In-Reply-To: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> References: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> Message-ID: <061.81201c400fcfa4668822d2d9c6ff3e2a@haskell.org> #14802: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Debugging) | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Comment: It's hard to say without some more context. Can you post a minimal example of how to reproduce this panic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 03:32:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 03:32:57 -0000 Subject: [GHC] #14802: panic! (the 'impossible' happened) In-Reply-To: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> References: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> Message-ID: <061.f230c728f4824ef648c46138a63ed9d6@haskell.org> #14802: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Debugging) | 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: | -------------------------------------+------------------------------------- Changes (by Ebanflo): * Attachment "ghciBug.hs" added. Attempted replication of the situation that caused the error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 03:35:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 03:35:03 -0000 Subject: [GHC] #14802: panic! (the 'impossible' happened) In-Reply-To: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> References: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> Message-ID: <061.b523c8ea2d3b1def5fa3dc6cd74ffdcb@haskell.org> #14802: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Debugging) | 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: | -------------------------------------+------------------------------------- Changes (by Ebanflo): * Attachment "ghciBug.2.hs" added. Attempted replication of what caused the error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 03:50:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 03:50:26 -0000 Subject: [GHC] #14802: panic! (the 'impossible' happened) In-Reply-To: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> References: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> Message-ID: <061.3a376c6f0c15a95578fdd7211cb92013@haskell.org> #14802: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Debugging) | 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: | -------------------------------------+------------------------------------- Description changed by Ebanflo: Old description: > I was debugging and tried to print a matrix but got the following error > message: > > :34:21: error:: panic! (the 'impossible' > happened) > (GHC version 8.0.2 for x86_64-unknown-linux): > No skolem info: a1_IhXR[rt] > > Has this been fixed in the newer version of ghc? If so, what's the > fastest way to update? New description: I was debugging and tried to print a matrix but got the following error message: :34:21: error:: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): No skolem info: a1_IhXR[rt] UPDATE: I downloaded ghc 8.2.2, extracted, ran `./config` and then `make install`. Now when I run `ghc -v` it says Glasgow Haskell Compiler, Version 8.2.2, stage 2 booted by GHC version 8.0.2 But when I run `ghci` it says that it is version 8.0.2 and it gives the same 'impossible' error as I did before. I put the function I was debugging in a small file with the other functions that it depends on (sorry, I accidentally attached the same file twice). It would be very difficult to replicate the test cases I was working with without copying a lot more code. I tried running the function on a simple test case (some 3x4 matrix) and when I tried to print the helper variable desired (mat1) it said that the runtime type of mat1 could not be determined. This was fixed by giving the function `calc` a type signature. Indeed, when I put this type signature in my actual code, I was able to debug it without a problem. My biggest concern at this point is how to boot ghci 8.2.2 instead of 8.0.2, and because of this I'm not sure whether or not what I've described here is a problem with 8.2.2 or just 8.0.2. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 07:03:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 07:03:13 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.0481bdb70bf5abb4fd4cf3ab9667924f@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4325 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"5957405808fe89e9b108dc0bc3cf4b56aec37775/ghc" 5957405/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5957405808fe89e9b108dc0bc3cf4b56aec37775" Collect CCs in CorePrep, including CCs in unfoldings This patch includes two changes: 1. Move cost centre collection from `SCCfinal` to `CorePrep`, to be able to collect cost centres in unfoldings. `CorePrep` drops unfoldings, so that's the latest stage in the compilation pipeline for this. After this change `SCCfinal` no longer collects all cost centres, but it still generates & collects CAF cost centres + updates cost centre stacks of `StgRhsClosure` and `StgRhsCon`s. This fixes #5889. 2. Initialize cost centre stack fields of `StgRhs` in `coreToStg`. With this we no longer need to update cost centre stack fields in `SCCfinal`, so that module is removed. Cost centre initialization explained in Note [Cost-centre initialization plan]. Because with -fcaf-all we need to attach a new cost-centre to each CAF, `coreTopBindToStg` now returns `CollectedCCs`. Test Plan: validate Reviewers: simonpj, bgamari, simonmar Reviewed By: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #5889 Differential Revision: https://phabricator.haskell.org/D4325 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 07:05:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 07:05:17 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.6eca9a2bc673df42c7a6be404cec10b3@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: merge Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4325 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 08:56:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 08:56:47 -0000 Subject: [GHC] #14802: panic! (the 'impossible' happened) In-Reply-To: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> References: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> Message-ID: <061.0e958006017d91923456b3e31f995872@haskell.org> #14802: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Debugging) | 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 hsyl20): You can use `stack` to easily launch a GHCi session for different GHC compiler versions: {{{ stack --resolver=ghc-8.0.1 repl --package vector --package primitive stack --resolver=ghc-8.0.2 repl --package vector --package primitive stack --resolver=ghc-8.2.2 repl --package vector --package primitive }}} Otherwise use `which ghci` to check which `ghci` is being used or use `ghc --interactive` instead of `ghci` (as `ghc -v` shows the expected version, it should work). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 12:14:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 12:14:33 -0000 Subject: [GHC] #14803: Panic during desugaring I think Message-ID: <045.85406ad066460903bbee6b0e27f8cfee@haskell.org> #14803: Panic during desugaring I think --------------------------------------+--------------------------------- Reporter: justus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: --------------------------------------+--------------------------------- This is the panic message itself {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-apple-darwin): mkOneConFull: Not TyConApp: bndType_aeGK Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/deSugar/Check.hs:976:30 in ghc:Check }}} And these are the options I use to compile: - {{{-Wall}}} - {{{-Wall}}} - {{{-Wcompat}}} - {{{-Wincomplete-record-updates}}} - {{{-Wincomplete-uni-patterns}}} - {{{-Wredundant-constraints}}} This is the file I am trying to compile [https://github.com/ohua-dev/ohua- core/blob/master/src/Ohua/ALang/Passes.hs]. Unfortunately the error message tells me very little about where the error actually occurs, but the {{{bndType}}} variables are generally used in the family of {{{AExpr}}} types defined here [https://github.com/ohua-dev /ohua-core/blob/master/src/Ohua/ALang/Lang.hs#L141]. To get the power of {{{recursion-schemes}}} all expression types are implemented on a variation of the base functor {{{AExprF}}} and then {{{newtype}}}s are used to create individual expression types. If anyone has an idea as to how I could create a minimal example for you guys feel free to tell me and I'll see what I can do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 12:43:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 12:43:51 -0000 Subject: [GHC] #14776: Add equality rule for `eqString` In-Reply-To: <049.437696e7d156821fd2d7478e285fedb5@haskell.org> References: <049.437696e7d156821fd2d7478e285fedb5@haskell.org> Message-ID: <064.4780f4fa83349fb3977991c4d1c43c90@haskell.org> #14776: Add equality rule for `eqString` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 carter): That’s no sound for floating point when nan is treated as a valid value rather than an error/ exception trigger. In the former case this optimization will break ALL isNan code in Haskell. If we also have a mode where calculations that would produce a nan throw an exception, this rule would be safe. Is there a way to provide this rule but prevent it from running on floats and doubles ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 12:44:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 12:44:48 -0000 Subject: [GHC] #14776: Add equality rule for `eqString` In-Reply-To: <049.437696e7d156821fd2d7478e285fedb5@haskell.org> References: <049.437696e7d156821fd2d7478e285fedb5@haskell.org> Message-ID: <064.fa7e4b1b67ddad00cd9524f4675911ee@haskell.org> #14776: Add equality rule for `eqString` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 carter): To clarify, x==x evaluates to false for nans... at least with value equality.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 12:52:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 12:52:21 -0000 Subject: [GHC] #14776: Add equality rule for `eqString` In-Reply-To: <049.437696e7d156821fd2d7478e285fedb5@haskell.org> References: <049.437696e7d156821fd2d7478e285fedb5@haskell.org> Message-ID: <064.643511ddce168ba9374a547ed8a69eb8@haskell.org> #14776: Add equality rule for `eqString` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 mpickering): This is specifically about `eqString` rather than generally `==` so I don't think that applies? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 13:05:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 13:05:27 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.9311d2dd701c2fc88647237f5ed91dbf@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 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:D4405 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): When a definition is marked `INLINABLE` the unfolding created is the same as the source definition and so it will be smaller. In the worker wrapper transformation (which only applies to recursive functions) the point of inlining the wrapper is to eliminate the mutual recursion in the worker which creates a nice loop working just with unboxed values. None of that is going on here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 13:52:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 13:52:53 -0000 Subject: [GHC] #14801: Multiple error messages confusing. In-Reply-To: <047.a54e5e940cf352b518d16938b14ad78f@haskell.org> References: <047.a54e5e940cf352b518d16938b14ad78f@haskell.org> Message-ID: <062.cf9746fb0aece60cd681553dc7bbc5d3@haskell.org> #14801: Multiple error messages confusing. -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14106 Comment: I //think// this is a duplicate of #14106. Can you confirm, augustss? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 14:03:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 14:03:52 -0000 Subject: [GHC] #14776: Add equality rule for `eqString` In-Reply-To: <049.437696e7d156821fd2d7478e285fedb5@haskell.org> References: <049.437696e7d156821fd2d7478e285fedb5@haskell.org> Message-ID: <064.0db965b6ffc4ff5489f89b3f01ea1713@haskell.org> #14776: Add equality rule for `eqString` -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 carter): woops, i misread this ticket, please ignore my remarks :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 14:04:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 14:04:00 -0000 Subject: [GHC] #14802: panic! (the 'impossible' happened) In-Reply-To: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> References: <046.b36113b8217c90c32832d6e9f4eebb0b@haskell.org> Message-ID: <061.b0e4753b9a5381e73800a8190e708c88@haskell.org> #14802: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Ebanflo | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Debugging) | 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 RyanGlScott): Thanks for posting the code, Ebanflo. But I'm still missing some important info here—I load the file into `ghci-8.0.2`, but I don't experience any sort of panic. What am I doing wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 14:16:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 14:16:01 -0000 Subject: [GHC] #14803: Panic during desugaring I think In-Reply-To: <045.85406ad066460903bbee6b0e27f8cfee@haskell.org> References: <045.85406ad066460903bbee6b0e27f8cfee@haskell.org> Message-ID: <060.42ed9a9b25be6fc31a475051256c8a97@haskell.org> #14803: Panic during desugaring I think ---------------------------------+--------------------------------------- Reporter: justus | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: PatternSynonyms Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14326 | Differential Rev(s): Wiki Page: | ---------------------------------+--------------------------------------- Changes (by RyanGlScott): * status: new => closed * keywords: => PatternSynonyms * resolution: => duplicate * related: => #14326 Comment: Thanks for the bug report. This is a duplicate of #14326, which has been fixed in GHC 8.4.1. This bug could be tickled when you nest pattern-synonym pattern matches in just the right way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 16:31:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 16:31:57 -0000 Subject: [GHC] #14711: Machine readable output of coverage In-Reply-To: <050.d858ad27520ca4b1ee3c013a327a8c68@haskell.org> References: <050.d858ad27520ca4b1ee3c013a327a8c68@haskell.org> Message-ID: <065.6d35fcd3f21abc44297de900e633b03f@haskell.org> #14711: Machine readable output of coverage -------------------------------------+------------------------------------- Reporter: Koterpillar | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 8.2.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jml): There's already an `--xml-output` flag for `report`: {{{ $ hpc help report Usage: hpc report [OPTION] .. [ [ ..]] Output textual report about program coverage Options: --per-module show module level detail --decl-list show unused decls --exclude=[PACKAGE:][MODULE] exclude MODULE and/or PACKAGE --include=[PACKAGE:][MODULE] include MODULE and/or PACKAGE --srcdir=DIR path to source directory of .hs files multi-use of srcdir possible --hpcdir=DIR append sub-directory that contains .mix files default .hpc [rarely used] --reset-hpcdirs empty the list of hpcdir's [rarely used] --xml-output show output in XML --verbosity=[0-2] verbosity level, 0-2 default 1 $ hpc version hpc tools, version 0.67 $ hpc report $(stack path --stack-yaml=stack-8.2.yaml --local-hpc-root )/graphql-api/graphql-api-tests/graphql-api-tests.tix --hpcdir=$(stack path --stack-yaml=stack-8.2.yaml --dist-dir)/hpc/ --xml-output }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 16:43:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 16:43:13 -0000 Subject: [GHC] #14803: Panic during desugaring I think In-Reply-To: <045.85406ad066460903bbee6b0e27f8cfee@haskell.org> References: <045.85406ad066460903bbee6b0e27f8cfee@haskell.org> Message-ID: <060.42830f8b532e75dfdaf454a4669e681c@haskell.org> #14803: Panic during desugaring I think ---------------------------------+--------------------------------------- Reporter: justus | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: PatternSynonyms Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14326 | Differential Rev(s): Wiki Page: | ---------------------------------+--------------------------------------- Comment (by justus): Ah. Sorry I did not see that duplicate. I tried searching for it but was unsuccessful. Now I'll have to add CPP to the {{{COMPLETE}}} pragmas in my code :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 17:35:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 17:35:18 -0000 Subject: [GHC] #14804: hGetLine does not document whether newline is returned. Message-ID: <043.13eb04d8889a6c408bc2d51c04fcc7a1@haskell.org> #14804: hGetLine does not document whether newline is returned. -------------------------------------+------------------------------------- Reporter: akfp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | 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: -------------------------------------+------------------------------------- Current documentation on hackage: hGetLine :: Handle -> IO String Computation hGetLine hdl reads a line from the file or channel managed by hdl. This operation may fail with: isEOFError if the end of file is encountered when reading the first character of the line. If hGetLine encounters end-of-file at any other point while reading in a line, it is treated as a line terminator and the (partial) line is returned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 18:47:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 18:47:10 -0000 Subject: [GHC] #14805: Allow disabling warnings on a per-block of code basis Message-ID: <049.5c0c1b7a35df788b3fb25b03c8c04686@haskell.org> #14805: Allow disabling warnings on a per-block of code basis -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Haskell developers frequently want to disable a warning, but not for their whole project. Right now the only way to do that is on a per-file basis. This isn't ideal, because it's a pretty broad brush for what is often a warning you only want to disable in one place. The way other compilers solve this is by allowing you to ignore warnings only between two lines in the code. Here's Clang and GCC: {{{ #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wunused-variable" int a; #pragma clang diagnostic pop }}} {{{ #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wunused-result" write(foo, bar, baz); #pragma GCC diagnostic pop }}} Examples of warnings people may want to ignore only in a certain location: In [https://github.com/yesodweb/yesod/blob/f2b651b69537985c5a2ca378018fd50537c3454b /yesod-core/Yesod/Core.hs#L5 yesod-core/yesod/Core.hs], deprecation warnings are disabled for the whole file, but it's not clear what deprecations are trying to be avoided. It's possible that code is no longer relevant. The tests for the `yesod-test` package test a function that yesod-test has deprecated, but still wants to test. Because of this, [https://github.com/yesodweb/yesod/blob/f2b651b69537985c5a2ca378018fd50537c3454b /yesod-test/test/main.hs#L1-L2 it ignores all deprecation warnings], when it could be only ignoring them for a few lines. It's pretty easy to find examples of this; just search a repo for `{-# OPTIONS_GHC -fno` and you'll probably find cases where warnings are disabled in a more broad way than is necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 19:23:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 19:23:15 -0000 Subject: [GHC] #14801: Multiple error messages confusing. In-Reply-To: <047.a54e5e940cf352b518d16938b14ad78f@haskell.org> References: <047.a54e5e940cf352b518d16938b14ad78f@haskell.org> Message-ID: <062.a05c6cbadfa387abfcefdd7130c8d7a7@haskell.org> #14801: Multiple error messages confusing. -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by augustss): Yes, it look like a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 19:23:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 19:23:53 -0000 Subject: [GHC] #14801: Multiple error messages confusing. In-Reply-To: <047.a54e5e940cf352b518d16938b14ad78f@haskell.org> References: <047.a54e5e940cf352b518d16938b14ad78f@haskell.org> Message-ID: <062.d6a98fdb2b4358915e5ffaa5db7b8ab4@haskell.org> #14801: Multiple error messages confusing. -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by augustss): * status: infoneeded => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 20:29:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 20:29:43 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.bc999c3b1bf043731d2641706bb5a5b5@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:75 simonpj]: > OK: once we have a separate Phab for the `simplCast` change, I'll review it. Ping me, Tobias! I split up D4385 into https://phabricator.haskell.org/D4394 (the NthCo stuff) and https://phabricator.haskell.org/D4395 (simplCast / Simplify). May I assume that the refactoring mentioned in comment:76 should go in D4394? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 21:08:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 21:08:08 -0000 Subject: [GHC] #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples Message-ID: <045.b43126faa75979b0b544659bcaa087ec@haskell.org> #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that it should be okay to `unsafeCoerce` between types that wrap certain things in unboxed unary tuples and ones that do not. For example, {{{#!hs unsafeCoerce :: (A -> B) -> A -> (# B #) unsafeCoerce :: ((# A #) -> B) -> A -> B }}} Generally, I believe `unsafeCoerce :: E1 -> E2` should be okay when the only differences are in what is wrapped in an unboxed unary tuple and both of the following hold: 1. Each new unary tuple wrapper in `E2` is in a positive position. 2. Each new unary tuple wrapper in `E1` is in a negative position. Semantically, {{{#!hs unsafeCoerce :: (A -> B) -> A -> (# B #) = \f a -> let !fa = f a in (# fa #) unsafeCoerce :: ((# A #) -> B) -> A -> B = \f !a -> f a }}} Am I correct in this interpretation? If so, is this something the developers would be willing to commit to and document? The first version in particular (a new unary tuple wrapper in positive position in the result) would be very useful for reducing both source code and generated code size in libraries supporting both strict and lazy operations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 21:12:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 21:12:08 -0000 Subject: [GHC] #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples In-Reply-To: <045.b43126faa75979b0b544659bcaa087ec@haskell.org> References: <045.b43126faa75979b0b544659bcaa087ec@haskell.org> Message-ID: <060.2017d20445b9d780f94cafe34cb05ea6@haskell.org> #14806: Officially sanction certain unsafeCoerce applications with unboxed unary tuples -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > It seems that it should be okay to `unsafeCoerce` between types that wrap > certain things in unboxed unary tuples and ones that do not. For example, > > {{{#!hs > unsafeCoerce :: (A -> B) -> A -> (# B #) > unsafeCoerce :: ((# A #) -> B) -> A -> B > }}} > > Generally, I believe `unsafeCoerce :: E1 -> E2` should be okay when the > only differences are in what is wrapped in an unboxed unary tuple and > both of the following hold: > > 1. Each new unary tuple wrapper in `E2` is in a positive position. > 2. Each new unary tuple wrapper in `E1` is in a negative position. > > Semantically, > > {{{#!hs > unsafeCoerce :: (A -> B) -> A -> (# B #) > = > \f a -> let !fa = f a in (# fa #) > > unsafeCoerce :: ((# A #) -> B) -> A -> B > = > \f !a -> f a > }}} > > Am I correct in this interpretation? If so, is this something the > developers would be willing to commit to and document? The first version > in particular (a new unary tuple wrapper in positive position in the > result) would be very useful for reducing both source code and generated > code size in libraries supporting both strict and lazy operations. New description: It seems that it should be okay to `unsafeCoerce` between types that wrap certain things in unboxed unary tuples and ones that do not. For example, {{{#!hs unsafeCoerce :: (A -> B) -> A -> (# B #) unsafeCoerce :: ((# A #) -> B) -> A -> B }}} Generally, I believe `unsafeCoerce :: E1 -> E2` should be okay when the only differences are in what is wrapped in an unboxed unary tuple and both of the following hold: 1. Each new unary tuple wrapper in `E2` is in a positive position. 2. Each new unary tuple wrapper in `E1` is in a negative position. Semantically, {{{#!hs unsafeCoerce :: (A -> B) -> A -> (# B #) = \f a -> let !fa = f a in (# fa #) unsafeCoerce :: ((# A #) -> B) -> A -> B = \f !a -> f (# a #) }}} Am I correct in this interpretation? If so, is this something the developers would be willing to commit to and document? The first version in particular (a new unary tuple wrapper in positive position in the result) would be very useful for reducing both source code and generated code size in libraries supporting both strict and lazy operations. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 22:49:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 22:49:52 -0000 Subject: [GHC] #8258: GHC accepts `data Foo where` in H2010 mode In-Reply-To: <042.7ae0b1be303dde5e66c52f6566614572@haskell.org> References: <042.7ae0b1be303dde5e66c52f6566614572@haskell.org> Message-ID: <057.2d4fbab16355cacb717da12198451498@haskell.org> #8258: GHC accepts `data Foo where` in H2010 mode -------------------------------------+------------------------------------- Reporter: hvr | Owner: sighingnow Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: parser/T8258, invalid program | parser/T8258NoGADTs Blocked By: | Blocking: 11384 Related Tickets: | Differential Rev(s): Phab:D4350 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8936ab69d18669bab3ca4edf40458f88ae5903f0/ghc" 8936ab6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8936ab69d18669bab3ca4edf40458f88ae5903f0" Raise parse error for `data T where`. Empty GADTs data declarations can't be identified in type checker. This patch adds additional checks in parser and raise a parse error when encounter empty GADTs declarations but extension `GADTs` is not enabled. Only empty declarations are checked in parser to avoid affecting existing error messages related to missing GADTs extension. This patch should fix issue 8258. Signed-off-by: HE, Tao Test Plan: make test TEST="T8258 T8258NoGADTs" Reviewers: bgamari, mpickering, alanz, RyanGlScott Reviewed By: bgamari, RyanGlScott Subscribers: adamse, RyanGlScott, rwbarton, thomie, mpickering, carter GHC Trac Issues: #8258 Differential Revision: https://phabricator.haskell.org/D4350 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 23:29:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 23:29:11 -0000 Subject: [GHC] #14807: GHC does not pass -dstg-lint Message-ID: <044.caec3e8004c95da59f586a54066aeaf5@haskell.org> #14807: GHC does not pass -dstg-lint -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 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 building ghc-8.4 branch with -dstg-lint enabled I got a GHC panic error (please see attachment as it's really big). The error is reproducible on Windows and Debian Linux 64 bit operating systems. As a side note, it seems that it would be good to enable `-dstg-lint` and `-dcmm-lint` in `devel2` flavour, and possibly some other flavours, or at least on CI, so that they will be tested more frequently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 23:30:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 23:30:21 -0000 Subject: [GHC] #14807: GHC does not pass -dstg-lint In-Reply-To: <044.caec3e8004c95da59f586a54066aeaf5@haskell.org> References: <044.caec3e8004c95da59f586a54066aeaf5@haskell.org> Message-ID: <059.076297193a31b6b17fb351a23d8cb1a1@haskell.org> #14807: GHC does not pass -dstg-lint -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 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 sergv): * Attachment "ghc-error.xz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 13 23:32:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Feb 2018 23:32:48 -0000 Subject: [GHC] #14807: GHC does not pass -dstg-lint In-Reply-To: <044.caec3e8004c95da59f586a54066aeaf5@haskell.org> References: <044.caec3e8004c95da59f586a54066aeaf5@haskell.org> Message-ID: <059.0323eb8615d26de9916ce8844713aaa5@haskell.org> #14807: GHC does not pass -dstg-lint -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 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: | -------------------------------------+------------------------------------- Description changed by sergv: Old description: > When building ghc-8.4 branch with -dstg-lint enabled I got a GHC panic > error (please see attachment as it's really big). The error is > reproducible on Windows and Debian Linux 64 bit operating systems. > > As a side note, it seems that it would be good to enable `-dstg-lint` and > `-dcmm-lint` in `devel2` flavour, and possibly some other flavours, or at > least on CI, so that they will be tested more frequently. New description: When building ghc-8.4 branch with -dstg-lint enabled I got a GHC panic error (please see attachment for full log as it's really big). The error is reproducible on Windows and Debian Linux 64 bit operating systems. Short error: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O -H64m -Wall -this-unit-id ghc-prim-0.5.2.0 -hide-all-packages -i -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build -Ilibraries /ghc-prim/dist-install/build -ilibraries/ghc-prim/dist- install/build/./autogen -Ilibraries/ghc-prim/dist-install/build/./autogen -Ilibraries/ghc-prim/. -optP-include -optPlibraries/ghc-prim/dist- install/build/./autogen/cabal_macros.h -package-id rts -this-unit-id ghc- prim -XHaskell2010 -O -dcore-lint -dstg-lint -dcmm-lint -no-user-package- db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-prim/dist- install/build -hidir libraries/ghc-prim/dist-install/build -stubdir libraries/ghc-prim/dist-install/build -dynamic-too -c libraries/ghc- prim/./GHC/Types.hs -o libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.0.20180204 for x86_64-unknown-linux): *** Stg Lint ErrMsgs: in Unarise *** : warning: [in body of lambda with binders v_s9Xn :: (a_12 :: k0_10) ~~ (b_13 :: k1_11)] In some algebraic case alternative, number of arguments doesn't match constructor: Eq# (arity 1) [] : warning: [in body of lambda with binders v_s9Xp :: Coercible a_11 b_12] In some algebraic case alternative, number of arguments doesn't match constructor: MkCoercible (arity 1) [] *** Offending Program *** ... lots of lines skipped ... *** End of Offense *** Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/stgSyn/StgLint.hs:68:19 in ghc:StgLint Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/GHC/Types.o' failed }}} As a side note, it seems that it would be good to enable `-dstg-lint` and `-dcmm-lint` in `devel2` flavour, and possibly some other flavours, or at least on CI, so that they will be tested more frequently. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 00:06:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 00:06:25 -0000 Subject: [GHC] #14805: Allow disabling warnings on a per-block of code basis In-Reply-To: <049.5c0c1b7a35df788b3fb25b03c8c04686@haskell.org> References: <049.5c0c1b7a35df788b3fb25b03c8c04686@haskell.org> Message-ID: <064.2076c3520b9ea19c9590c42f59e05b3c@haskell.org> #14805: Allow disabling warnings on a per-block of code basis -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #602 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #602 Comment: This is the subject of #602, so I'll close this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 00:08:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 00:08:05 -0000 Subject: [GHC] #14807: GHC does not pass -dstg-lint In-Reply-To: <044.caec3e8004c95da59f586a54066aeaf5@haskell.org> References: <044.caec3e8004c95da59f586a54066aeaf5@haskell.org> Message-ID: <059.bded8c40e457200f2cf043e3d21ceb54@haskell.org> #14807: GHC does not pass -dstg-lint -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 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 RyanGlScott): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 02:19:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 02:19:59 -0000 Subject: [GHC] #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order Message-ID: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: GADTs | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14529, #14796 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Originally noticed in #14796. This program: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Kind data ECC ctx f a where ECC :: ctx => f a -> ECC ctx f a f :: [()] -> ECC () [] () f = ECC @() @[] @() }}} Typechecks in GHC 8.2.2 and 8.4.1, but not in GHC HEAD: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:12:5: error: • Couldn't match type ‘()’ with ‘[]’ Expected type: [()] -> ECC (() :: Constraint) [] () Actual type: () [] -> ECC (() :: Constraint) () [] • In the expression: ECC @() @[] @() In an equation for ‘f’: f = ECC @() @[] @() | 12 | f = ECC @() @[] @() | ^^^^^^^^^^^^^^^ Bug.hs:12:10: error: • Expected kind ‘* -> *’, but ‘()’ has kind ‘*’ • In the type ‘()’ In the expression: ECC @() @[] @() In an equation for ‘f’: f = ECC @() @[] @() | 12 | f = ECC @() @[] @() | ^^ Bug.hs:12:14: error: • Expecting one more argument to ‘[]’ Expected a type, but ‘[]’ has kind ‘* -> *’ • In the type ‘[]’ In the expression: ECC @() @[] @() In an equation for ‘f’: f = ECC @() @[] @() | 12 | f = ECC @() @[] @() | ^^ }}} This is because the order of type variables for `ECC` has changed between GHC 8.4.1 and HEAD. In 8.4.1, it's {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs -XTypeApplications -fprint-explicit- foralls GHCi, version 8.4.0.20180209: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. λ> :type +v ECC ECC :: forall (ctx :: Constraint) (f :: * -> *) a. ctx => f a -> ECC ctx f a }}} In GHC HEAD, however, it's: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -XTypeApplications -fprint-explicit-foralls GHCi, version 8.5.20180213: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. λ> :type +v ECC ECC :: forall (f :: * -> *) a (ctx :: Constraint). ctx => f a -> ECC ctx f a }}} This regression was introduced in fa29df02a1b0b926afb2525a258172dcbf0ea460 (Refactor ConDecl: Trac #14529). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 02:24:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 02:24:03 -0000 Subject: [GHC] #14796: Pretty Printing: GHC doesn't parenthesise (() :: Constraint) In-Reply-To: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> References: <051.7c740abd2da79f78e6b41c16e1857e91@haskell.org> Message-ID: <066.ab06108774c7bc126718e55938c2429e@haskell.org> #14796: Pretty Printing: GHC doesn't parenthesise (() :: Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14808 | Differential Rev(s): Phab:D4408 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4408 * related: => #14808 Comment: Egads, there's an even more serious bug lurking here—the fact that you have to visibly apply the arguments to `ECC` in completely different orders on GHC 8.2.2/8.4.1 and HEAD! I've opened #14808 for this. In the meantime, I've opened Phab:D4408 for this bug, which is straightforward to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 02:24:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 02:24:40 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.809dfcd4eac44d0b21ac35e57d48c8e7@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Ok, I know what's going on "mechanically", but I'm missing some big picture stuff. In https://phabricator.haskell.org/D3051, bgamari added some logic in `Simplify.prepareRhs.go` to not tick top level string literals. Namely this fragment: {{{ ; let tickIt (id, expr) -- we have to take care not to tick top-level literal -- strings. See Note [CoreSyn top-level string literals]. | isTopLevel top_lvl && exprIsLiteralString expr = (id, expr) | otherwise = (id, mkTick (mkNoCount t) expr) }}} In the case that I'm looking at `top_level = NotTopLevel` and the literal string gets floated to the top. The call stack is as follows `Simplify.simplNonRecE` calls `Simplify.simplLazyBind` calls `Simplify.prepareRhs`. Now `simplNonRecE` always calls `simplLazyBind` with `NotTopLevel` and `simplLazyBind` uses that to call `prepareRhs`. So either: 1. `top_level` doesn't mean that we're floating to top level, or 2. it means that we're floating to top level, and we're not supposed to float the string to the top. I suspect it's 1., but I wasn't able to find a comment that explains its purpose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 03:30:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 03:30:06 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.19e4eb9364ea09d1e9e0de47956e72d5@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, please. Many thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 05:52:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 05:52:52 -0000 Subject: [GHC] #14809: Invocation of ghc with --make flag should be smarter about hs-boot and lhs-boot files Message-ID: <045.53197590a27411ebfe5298374cc07c99@haskell.org> #14809: Invocation of ghc with --make flag should be smarter about hs-boot and lhs- boot files -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, `--make` in handy for compiling programs with boot files using only one `ghc` invocation. But it behaves strange. If I pass `A.hs`, `B.hs`, and `A.hs-boot` (where `B.hs` imports module `A` with that `{-# SOURCE -#}` thing), I get an error message complaining about module `A` defined twice. Surely GHC should be able to figure out that if the second file has the extension `hs-boot`, it's a boot file and should be used as such. After all, GHC is perfectly capable of finding boot files if it's given import directories to search in (with `-i`). We can't however easily use that because it so happens that if we tell ghc about such directories, they can contain files that should not be visible. I even tried a workaround: copy all boot files to a separate location and then point to that location with `-i`. To my surprise in that case ghc does not pick up those boot files. (And with more complex nesting of modules I expect more problems with this approach.) So it would be great if we could just feed all the relevant files into ghc and it would be smart enough not to complain about modules defined twice if one of the modules is in a file with `hs-boot` or `lhs-boot` extension, but use it as a boot file for corresponding module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 07:15:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 07:15:01 -0000 Subject: [GHC] #14807: GHC does not pass -dstg-lint In-Reply-To: <044.caec3e8004c95da59f586a54066aeaf5@haskell.org> References: <044.caec3e8004c95da59f586a54066aeaf5@haskell.org> Message-ID: <059.3724625b08d5702122e34bffe4d7cd75@haskell.org> #14807: GHC does not pass -dstg-lint -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #14787 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => duplicate * related: => #14787 Comment: Thanks for reporting. `-dstg-lint` was broken for a long time and only recently fixed in #14787. It should be merged sometime next week (currently waiting for @simonpj's review). However I don't know if it'll be merged to 8.4 branch, @bgamari would know. Closing as duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 10:50:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 10:50:24 -0000 Subject: [GHC] #12422: Add decidable equality class In-Reply-To: <045.cc846fa4626d50a4033ca66a47264374@haskell.org> References: <045.cc846fa4626d50a4033ca66a47264374@haskell.org> Message-ID: <060.bfa3a44bfef649f0afb370721fe68023@haskell.org> #12422: Add decidable equality class -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) 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 int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 12:33:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 12:33:15 -0000 Subject: [GHC] #9269: Type families returning quantified types In-Reply-To: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> References: <046.d2986c8d4f1d8bdce682f681ff6827a2@haskell.org> Message-ID: <061.f153bd66429b5fcdb1c6065ee0a2f151@haskell.org> #9269: Type families returning quantified types -------------------------------------+------------------------------------- Reporter: pumpkin | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11962 Related Tickets: #13901 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * cc: Tritlo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 12:48:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 12:48:15 -0000 Subject: [GHC] #14810: Define MVar "This function is atomic only if there are no other producers for this MVar." Message-ID: <043.d53f05eab9834c235f9f2a1b9cc7aee0@haskell.org> #14810: Define MVar "This function is atomic only if there are no other producers for this MVar." -------------------------------------+------------------------------------- Reporter: akfp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The sentence: This function is atomic only if there are no other producers for this MVar. Is repeated lots of times in the Control.Concurrent.MVar documentation. However, there is no definition of what "producers for an MVar" means. There needs to be a definition of producer (and consumer I guess). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 12:50:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 12:50:27 -0000 Subject: [GHC] #11735: Optimize coercionKind In-Reply-To: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> References: <047.4a7a4b5184d1293c5e3d53524b93fe89@haskell.org> Message-ID: <062.e59329c35254f6242e437ed4aedeb20f@haskell.org> #11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Alright, all the changes from the wip/11735 branch should be on either D4394 or D4395 now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 12:51:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 12:51:15 -0000 Subject: [GHC] #14810: Define MVar "This function is atomic only if there are no other producers for this MVar." In-Reply-To: <043.d53f05eab9834c235f9f2a1b9cc7aee0@haskell.org> References: <043.d53f05eab9834c235f9f2a1b9cc7aee0@haskell.org> Message-ID: <058.bc2a74229206ff08ea04a778479846d0@haskell.org> #14810: Define MVar "This function is atomic only if there are no other producers for this MVar." -------------------------------------+------------------------------------- Reporter: akfp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akfp): The sentence might need to link to the section: "In particular, the "bigger" functions in this module (readMVar, swapMVar, withMVar, modifyMVar_ and modifyMVar) are simply the composition of a takeMVar followed by a putMVar with exception safety. These only have atomicity guarantees if all other threads perform a takeMVar before a putMVar as well; otherwise, they may block." or that section needs to define "producer". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 13:29:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 13:29:45 -0000 Subject: [GHC] #14810: Define MVar "This function is atomic only if there are no other producers for this MVar." In-Reply-To: <043.d53f05eab9834c235f9f2a1b9cc7aee0@haskell.org> References: <043.d53f05eab9834c235f9f2a1b9cc7aee0@haskell.org> Message-ID: <058.b059c65ebd9327dd19e23bdb17fbc481@haskell.org> #14810: Define MVar "This function is atomic only if there are no other producers for this MVar." -------------------------------------+------------------------------------- Reporter: akfp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Agreed that the documentation should be improved. I was also confused about this some time ago. Producer simply means "putMVar". For example, `swapMVar` takes the current value and puts a new value. If another thread puts between the `swapMVar`s take and put, `swapMVar` blocks and other threads observe the intermediate step, so it won't be atomic in this case. Similarly consumer means "takeMVar". Would you like to open a pull request? I think we accept documentation patches via Github PRs these days. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 14:47:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 14:47:01 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.446113f605ddaa15a0e0acc83d8801a8@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > cse and circsim really do allocate (a little) more. But in your investigation you didn't find any allocation differences. Doesn't -ticky nail it for you? Just compared original vs. late demand analysis version of the same function in mate with help from ticky profiler and found the source of allocation. (the function is huge, copying the important bits. Both functions have same number of entries) Original function, important bit is how the second argument (Int) used: {{{ $warg_sciK [InlPrag=NOUSERINLINE[0], Occ=OnceL*!, Dmd=] :: Board.Kind -> GHC.Types.Int -> GHC.Types.Int -> GHC.Types.Bool -> GHC.Types.Bool [LclId, Arity=4, Str=, Unf=OtherCon []] = sat-only [w_scin ww_scio ww1_scip ds_sciq lvl17_scis lvl18_sciB] \r [ww2_sciL ww3_sciM ww4_sciN w1_sciO] let { lvl19_sciP [Occ=Once*!, Dmd=] :: GHC.Types.Bool [LclId] = [ww_scio ww1_scip ds_sciq ww3_sciM] \s [] let { lvl20_sciQ [Occ=OnceL*!, Dmd=] :: GHC.Types.Int [LclId] = [ds_sciq ww3_sciM] \u [] case ww3_sciM of wild_sciR { GHC.Types.I# x1_sciS [Occ=Once] -> case ds_sciq of { (,) xk_sciU [Occ=Once!] _ [Occ=Dead] -> case xk_sciU of wild2_sciW { GHC.Types.I# y1_sciX [Occ=Once] -> case <=# [x1_sciS y1_sciX] of { __DEFAULT -> wild_sciR; 1# -> wild2_sciW; }; }; }; }; } in let { lvl21_sciZ [Occ=OnceL*!, Dmd=] :: GHC.Types.Int [LclId] = [ds_sciq ww3_sciM] \u [] case ww3_sciM of wild_scj0 { GHC.Types.I# x1_scj1 [Occ=Once] -> case ds_sciq of { (,) xk_scj3 [Occ=Once!] _ [Occ=Dead] -> case xk_scj3 of wild2_scj5 { GHC.Types.I# y1_scj6 [Occ=Once] -> case <=# [x1_scj1 y1_scj6] of { __DEFAULT -> wild2_scj5; 1# -> wild_scj0; }; }; }; }; } in ... }}} It's used strictly, but also returned in boxed form in `__DEFAULT` case of first case expression and `1#` case of the second. Now with late demand analysis: {{{ $w$warg_sd96 [InlPrag=NOUSERINLINE[0], Occ=OnceL*!, Dmd=] :: Board.Kind -> GHC.Prim.Int# -> GHC.Types.Int -> GHC.Types.Bool -> GHC.Types.Bool [LclId, Arity=4, Str=, Unf=OtherCon []] = sat-only [w_sd8J ww_sd8K ww1_sd8L ds_sd8M lvl17_sd8O lvl18_sd8X] \r [w1_sd97 ww2_sd98 w2_sd99 w3_sd9a] let { ww3_sd9b [Dmd=] :: GHC.Types.Int [LclId, Unf=OtherCon []] = CCCS GHC.Types.I#! [ww2_sd98]; } in let { lvl19_sd9c [Occ=Once*!, Dmd=] :: GHC.Types.Bool [LclId] = [ww_sd8K ww1_sd8L ds_sd8M ww2_sd98 ww3_sd9b] \s [] let { lvl20_sd9d [Occ=OnceL*!, Dmd=] :: GHC.Types.Int [LclId] = [ds_sd8M ww2_sd98 ww3_sd9b] \u [] case ds_sd8M of { (,) xk_sd9f [Occ=Once!] _ [Occ=Dead] -> case xk_sd9f of wild1_sd9h { GHC.Types.I# y1_sd9i [Occ=Once] -> case <=# [ww2_sd98 y1_sd9i] of { __DEFAULT -> ww3_sd9b; 1# -> wild1_sd9h; }; }; }; } in let { lvl21_sd9k [Occ=OnceL*!, Dmd=] :: GHC.Types.Int [LclId] = [ds_sd8M ww2_sd98 ww3_sd9b] \u [] case ds_sd8M of { (,) xk_sd9m [Occ=Once!] _ [Occ=Dead] -> case xk_sd9m of wild1_sd9o { GHC.Types.I# y1_sd9p [Occ=Once] -> case <=# [ww2_sd98 y1_sd9p] of { __DEFAULT -> wild1_sd9o; 1# -> ww3_sd9b; }; }; }; } in ... }}} now the second argument is `Int#` instead of `Int` as before, but we pack it in the first `let` because we need to return it boxed (`_DEFAULT` case of first case expression and `1#` case of the second case). This is the only extra source of allocation in mate as far as I can see from the ticky output so this should be responsible for 5% increase in `mate`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 16:48:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 16:48:15 -0000 Subject: [GHC] #7411: Exceptions are optimized away in certain situations In-Reply-To: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> References: <050.f2f3c96ba0efbcc7fad89b869c0b1e35@haskell.org> Message-ID: <065.59a04a93f3b73fd4faad6689cf8ab73b@haskell.org> #7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Nor for 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 16:48:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 16:48:42 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.f8854fcaf6644f36fec590dc1b8a192e@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This won't be fixed for 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 16:48:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 16:48:48 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.8e98a407cea5f9c7e94d915c77b2503b@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 16:49:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 16:49:51 -0000 Subject: [GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 In-Reply-To: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> References: <042.588059ee1290b666bd7f0947c071e1ff@haskell.org> Message-ID: <057.04c4bb503fc3da5dbe47bb59a6c5ea43@haskell.org> #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2 -------------------------------------+------------------------------------- Reporter: hvr | Owner: dfeuer Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7258 | Differential Rev(s): Phab:D3399, Wiki Page: | Phab:D3400, Phab:D3421 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: This won't be fixed for 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 22:42:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 22:42:19 -0000 Subject: [GHC] #8258: GHC accepts `data Foo where` in H2010 mode In-Reply-To: <042.7ae0b1be303dde5e66c52f6566614572@haskell.org> References: <042.7ae0b1be303dde5e66c52f6566614572@haskell.org> Message-ID: <057.ba7f418123cfec2915250ea5f1b0acca@haskell.org> #8258: GHC accepts `data Foo where` in H2010 mode -------------------------------------+------------------------------------- Reporter: hvr | Owner: sighingnow Type: bug | Status: closed Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: parser/T8258, invalid program | parser/T8258NoGADTs Blocked By: | Blocking: 11384 Related Tickets: | Differential Rev(s): Phab:D4350 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 22:55:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 22:55:21 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.a38d10a4353ffe770513f1e379e3fdaa@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * priority: high => normal Comment: given that it works compiled with -O this doesn't seem high priority. If anybody disagrees feel free to raise the priority back to high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 23:01:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 23:01:50 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.9c15fb850fe412c8a69e2df7854f98e4@haskell.org> #8949: switch -msse2 to be on by default --------------------------------------------+------------------------------ Reporter: errge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (CodeGen) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13540, #13624 | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Changes (by George): * related: #13540 => #13540, #13624 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 23:04:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 23:04:22 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.1a8934ee4c8c25fd9acb8240509e19d2@haskell.org> #8949: switch -msse2 to be on by default --------------------------------------------+------------------------------ Reporter: errge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (CodeGen) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Test Case: Blocked By: 13624 | Blocking: Related Tickets: #13540, #13624 | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Changes (by George): * blockedby: => 13624 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 14 23:25:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Feb 2018 23:25:35 -0000 Subject: [GHC] #13011: Simplifier ticks exhausted: a 10-line case In-Reply-To: <052.bf42032c1e22b5cab8fc1d52eefb6688@haskell.org> References: <052.bf42032c1e22b5cab8fc1d52eefb6688@haskell.org> Message-ID: <067.11f6f9586ec93426f792d377e00a032f@haskell.org> #13011: Simplifier ticks exhausted: a 10-line case -------------------------------------+------------------------------------- Reporter: L.K.Rebellion | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Simplifier | ticks exhausted Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #8319 #12776 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Given Simon's comment above and the doc that seems to say this will never be fixed does it make sense to leave this as high priority? Note also that the error message says: If GHC was unable to complete compilation even with a very large factor (a thousand or more), please consult the "Known bugs or infelicities" section in the Users Guide before filing a report. There are a few situations unlikely to occur in practical programs for which simplifier non-termination has been judged acceptable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 00:17:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 00:17:04 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.ae737af715e0eb1152f00cdaade68c91@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: dfeuer Type: bug | Status: merge Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1-rc3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T13943 Blocked By: | Blocking: Related Tickets: #12791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): fixed in 8.4.1 alpha 3 is there going to be an 8.2.3? if not should the milestone be changed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 01:47:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 01:47:12 -0000 Subject: [GHC] #14807: GHC does not pass -dstg-lint In-Reply-To: <044.caec3e8004c95da59f586a54066aeaf5@haskell.org> References: <044.caec3e8004c95da59f586a54066aeaf5@haskell.org> Message-ID: <059.00418aed80d953a34d643ca7c4fd7029@haskell.org> #14807: GHC does not pass -dstg-lint -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #14787 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.6.1 Comment: I don't see a compelling reason to merge to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 02:12:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 02:12:03 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.2d49a90d5821ed7ac20f7dbcebcd1122@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Not sure if compiling the code in comment 7 with -O -prof is still a valid test case. If so, it seems to be fixed on 8.4.1 alpha 3 with parsec 3.1.13 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 02:17:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 02:17:03 -0000 Subject: [GHC] #14811: Unary unboxed tuple field causes panic Message-ID: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> #14811: Unary unboxed tuple field causes panic -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- Compiling this code under 8.2 or HEAD (but not 8.0), I get an error. {{{#!hs {-# language UnboxedTuples #-} module Reccy where data Foo a = Foo (# a #) }}} {{{ Reccy.hs:1:1: error: Can't find interface-file declaration for variable GHC.Types.$tcUnit# Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error | 1 | -- {-# language GADTs, TypeOperators #-} | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 03:18:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 03:18:28 -0000 Subject: [GHC] #14811: Unary unboxed tuple field causes interface file error (was: Unary unboxed tuple field causes panic) In-Reply-To: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> References: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> Message-ID: <060.c6da880ad24945391b56a260d331dbe3@haskell.org> #14811: Unary unboxed tuple field causes interface file error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 06:18:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 06:18:32 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.ff73cd4bee09389f5a804018e34818c9@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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 dfeuer): As best I can tell, everything is fine for long, long time. After SpecConstr, the simplifier runs iteration 1 successfully, but then the next round blows up. It looks like the problematic binding is converted to a join point here, if I'm reading it right. Around when that happens, its type signature changes. The specialization rule for it, however, still rewrites it to something with its original type, causing the lint error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 07:04:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 07:04:43 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.c8f07edde76480b0eb1b5da69fca1646@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Now that I understand ticky profiling better I also took another look at `cse` again. The difference is is these two functions: {{{ Entries Alloc Alloc'd Non-void Arguments STG Name -------------------------------------------------------------------------------- 524 12072 0 2 Li $wgo1{v r6T8} (main:Main) (fun) 394 9984 0 2 LL $wdraw{v r6Tg} (main:Main) (fun) total: 918 22056 }}} after late demand analysis this becomes: {{{ Entries Alloc Alloc'd Non-void Arguments STG Name -------------------------------------------------------------------------------- 524 11424 0 2 Li $w$wgo{v r71J} (main:Main) (fun) 394 12768 0 2 LL $wdraw{v r71R} (main:Main) (fun) total: 918 24192 }}} Definitions: (common parts in `wdraw` functions removed) {{{ $wgo1_r6T8 :: [GHC.Types.Char] -> GHC.Prim.Int# -> [GHC.Types.Char] [GblId, Arity=2, Str=m2, Unf=OtherCon []] = sat-only [] \r [w_s6XW ww_s6XX] case w_s6XW of { [] -> $wxs1_r6T7 ww_s6XX; : y_s6XZ [Occ=Once*] ys_s6Y0 [Occ=Once] -> case ww_s6XX of ds11_s6Y1 { __DEFAULT -> let { sat_s6Y3 [Occ=Once] :: [GHC.Types.Char] [LclId] = [ys_s6Y0 ds11_s6Y1] \u [] case -# [ds11_s6Y1 1#] of sat_s6Y2 { __DEFAULT -> $wgo1_r6T8 ys_s6Y0 sat_s6Y2; }; } in : [y_s6XZ sat_s6Y3]; 1# -> : [y_s6XZ n_r6T1]; }; }; $wdraw_r6Tg :: [GHC.Types.Char] -> [Main.GenTree [GHC.Types.Char]] -> [[GHC.Types.Char]] [GblId, Arity=2, Str=, Unf=OtherCon []] = sat-only [] \r [ww_s6ZI ww1_s6ZJ] let { sat_s70m [Occ=Once, Dmd=] :: [GHC.Types.Char] [LclId] = [ww_s6ZI] \s [] let { sat_s70l [Occ=Once, Dmd=] :: [GHC.Types.Char] [LclId] = [ww_s6ZI] \s [] $wgo1_r6T8 ww_s6ZI 4#; } in GHC.Base.++ ds10_r6SZ sat_s70l; } in case case ww1_s6ZJ of { [] -> lvl23_r6Tc; : t_s6ZL [Occ=Once*!] ds11_s6ZM [Occ=Once!] -> case ds11_s6ZM of { [] -> case case t_s6ZL of { Main.Node ww3_s6ZP [Occ=Once] ww4_s6ZQ [Occ=Once] -> $wdraw_r6Tg ww3_s6ZP ww4_s6ZQ; } of sat_s6ZR { __DEFAULT -> $sgo1_r6SJ sat_s6ZR ds9_r6SX xs2_r6Tf; }; : ipv_s6ZS [Occ=Once] ipv1_s6ZT [Occ=Once] -> let { z_s6ZU [Occ=OnceL] :: [[GHC.Types.Char]] [LclId] = [ipv_s6ZS ipv1_s6ZT] \u [] $srsLoop_r6Th ipv_s6ZS ipv1_s6ZT; } in let { z1_s6ZV :: [[GHC.Types.Char]] [LclId, Unf=OtherCon []] = CCCS :! [ds5_r6SS z_s6ZU]; } in let { go4_s6ZX [Occ=LoopBreaker] :: [[GHC.Types.Char]] -> [[GHC.Types.Char]] -> [[GHC.Types.Char]] } in let { $sgo6_s6ZW [Occ=Once!T[3]] :: [[GHC.Types.Char]] -> [GHC.Types.Char] -> [[GHC.Types.Char]] -> [[GHC.Types.Char]] } in case case t_s6ZL of { Main.Node ww3_s70h [Occ=Once] ww4_s70i [Occ=Once] -> $wdraw_r6Tg ww3_s70h ww4_s70i; } of sat_s70j { __DEFAULT -> $sgo6_s6ZW sat_s70j ds7_r6SV xs_r6ST; }; }; } of sat_s70k { __DEFAULT -> $sgo2_r6SH sat_s70k sat_s70m xs1_r6T5; }; }}} after late demand analysis: {{{ $w$wgo_r71J :: [GHC.Types.Char] -> GHC.Prim.Int# -> (# GHC.Types.Char, [GHC.Types.Char] #) [GblId, Arity=2, Str=, Unf=OtherCon []] = sat-only [] \r [w_s76A w1_s76B] case w_s76A of { [] -> $w$wxs_r71I w1_s76B; : y_s76D [Occ=Once*] ys_s76E [Occ=Once] -> case w1_s76B of ds11_s76F { __DEFAULT -> let { sat_s76K [Occ=Once] :: [GHC.Types.Char] [LclId] = [ys_s76E ds11_s76F] \u [] case -# [ds11_s76F 1#] of sat_s76G { __DEFAULT -> case $w$wgo_r71J ys_s76E sat_s76G of { (#,#) ww1_s76I [Occ=Once] ww2_s76J [Occ=Once] -> : [ww1_s76I ww2_s76J]; }; }; } in (#,#) [y_s76D sat_s76K]; 1# -> (#,#) [y_s76D n_r71D]; }; }; $wdraw_r71R :: [GHC.Types.Char] -> [Main.GenTree [GHC.Types.Char]] -> [[GHC.Types.Char]] [GblId, Arity=2, Str=, Unf=OtherCon []] = sat-only [] \r [ww_s78p ww1_s78q] let { karg_s78r [Occ=Once*, Dmd=] :: [GHC.Types.Char] [LclId] = [ww_s78p] \s [] let { sat_s78v [Occ=Once, Dmd=] :: [GHC.Types.Char] [LclId] = [ww_s78p] \s [] case $w$wgo_r71J ww_s78p 4# of { (#,#) ww3_s78t [Occ=Once] ww4_s78u [Occ=Once] -> : [ww3_s78t ww4_s78u]; }; } in GHC.Base.++ ds10_r71B sat_s78v; } in case ww1_s78q of { [] -> $sgo2_r71j lvl22_r71N karg_s78r xs1_r71H; : t_s78x [Occ=Once*!] ds11_s78y [Occ=Once!] -> case ds11_s78y of { [] -> case t_s78x of { Main.Node ww3_s78B [Occ=Once] ww4_s78C [Occ=Once] -> case $wdraw_r71R ww3_s78B ww4_s78C of sat_s78D { __DEFAULT -> case $sgo1_r71l sat_s78D ds9_r71z xs2_r71Q of sat_s78E { __DEFAULT -> $sgo2_r71j sat_s78E karg_s78r xs1_r71H; }; }; }; : ipv_s78F [Occ=Once!] ipv1_s78G [Occ=Once] -> let { z_s78H [Occ=OnceL] :: [[GHC.Types.Char]] [LclId] = [ipv_s78F ipv1_s78G] \u [] case ipv_s78F of { Main.Node ww3_s78J [Occ=Once] ww4_s78K [Occ=Once] -> $w$srsLoop_r71S ww3_s78J ww4_s78K ipv1_s78G; }; } in let { z1_s78L :: [[GHC.Types.Char]] [LclId, Unf=OtherCon []] = CCCS :! [ds5_r71u z_s78H]; } in let { go4_s78N [Occ=LoopBreaker] :: [[GHC.Types.Char]] -> [[GHC.Types.Char]] -> [[GHC.Types.Char]] } in let { $sgo6_s78M [Occ=Once!] :: [[GHC.Types.Char]] -> [GHC.Types.Char] -> [[GHC.Types.Char]] -> [[GHC.Types.Char]] } in case t_s78x of { Main.Node ww3_s797 [Occ=Once] ww4_s798 [Occ=Once] -> case $wdraw_r71R ww3_s797 ww4_s798 of sat_s799 { __DEFAULT -> case $sgo6_s78M sat_s799 ds7_r71x xs_r71v of sat_s79a { __DEFAULT -> $sgo2_r71j sat_s79a karg_s78r xs1_r71H; }; }; }; }; }; }}} Somehow new `wdraw` function should be doing more allocation but I couldn't figure how yet. Also attached the whole STG dumps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 07:05:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 07:05:34 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.6ff6718b4f78be1481b5bdaab50d0d17@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * Attachment "Main_stock.dump-stg" added. cse -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 07:05:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 07:05:56 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.46575fb60012a02e27250085a5ff8b89@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * Attachment "Main_late_dmd.dump-stg" added. cse late demand analysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 07:28:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 07:28:45 -0000 Subject: [GHC] #6070: Fun with the demand analyser In-Reply-To: <046.c6530061559c47a83051d5bf2c366594@haskell.org> References: <046.c6530061559c47a83051d5bf2c366594@haskell.org> Message-ID: <061.819025b7ddd69679249807a893ca6824@haskell.org> #6070: Fun with the demand analyser -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.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): Just tried with GHC HEAD, unused arg in join point in `Unboxed.hs` vanishes with late demand analysis. {{{ let-no-escape { $j_s4wc [Occ=Once*!T[2], Dmd=] :: GHC.Prim.Int# -> GHC.Types.Int -> (# Unboxed.FingerTree Unboxed.Size (Unboxed.Node Unboxed.Size c_s44z), Unboxed.FingerTree Unboxed.Size (Unboxed.Node Unboxed.Size c_s44z) #) [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] = ... }}} After: {{{ let-no-escape { $w$j_s4BK [InlPrag=NOUSERINLINE[0], Occ=Once*!T[1], Dmd=] :: GHC.Prim.Int# -> (# Unboxed.FingerTree Unboxed.Size (Unboxed.Node Unboxed.Size c_s45o), Unboxed.FingerTree Unboxed.Size (Unboxed.Node Unboxed.Size c_s45o) #) [LclId[JoinId(1)], Arity=1, Str=, Unf=OtherCon []] = ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 07:30:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 07:30:39 -0000 Subject: [GHC] #5302: Unused arguments in join points In-Reply-To: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> References: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> Message-ID: <061.b38bcacc7c560533ea00ffa0a2440397@haskell.org> #5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Just tried with GHC HEAD. Late demand analysis removes unused join point argument. {{{ let-no-escape { $j_s4wc [Occ=Once*!T[2], Dmd=] :: GHC.Prim.Int# -> GHC.Types.Int -> (# Unboxed.FingerTree Unboxed.Size (Unboxed.Node Unboxed.Size c_s44z), Unboxed.FingerTree Unboxed.Size (Unboxed.Node Unboxed.Size c_s44z) #) [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] = ... }}} After: {{{ let-no-escape { $w$j_s4BK [InlPrag=NOUSERINLINE[0], Occ=Once*!T[1], Dmd=] :: GHC.Prim.Int# -> (# Unboxed.FingerTree Unboxed.Size (Unboxed.Node Unboxed.Size c_s45o), Unboxed.FingerTree Unboxed.Size (Unboxed.Node Unboxed.Size c_s45o) #) [LclId[JoinId(1)], Arity=1, Str=, Unf=OtherCon []] = ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 07:31:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 07:31:16 -0000 Subject: [GHC] #5302: Unused arguments in join points In-Reply-To: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> References: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> Message-ID: <061.e5803f465ba41157d2e09bd87a250350@haskell.org> #5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * Attachment "Unboxed_late_dmd.dump-stg" added. Unboxed.hs, late demand analysis -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 07:31:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 07:31:31 -0000 Subject: [GHC] #5302: Unused arguments in join points In-Reply-To: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> References: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> Message-ID: <061.22626e224e3f38653f102182f83d5c97@haskell.org> #5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * Attachment "Unboxed_stock.dump-stg" added. Unboxed.hs, default -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 07:42:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 07:42:44 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.bb45fe302e364ffd717809b388c283e8@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > comment:12 of #5075 identifies three more tickets that claim to benefit from late-dmd-anal. Let's see if they do. One of those tickets is the current ticket. I updated #5302. I checked #6070 but late demand analysis didn't make any difference in the example functions `h` and `c` shown in the ticket. I don't know how to generated the `CPR2.c_go2`, the ticket is missing that detail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 08:50:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 08:50:17 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.978144d0cd4965b25aeaa08249ab02bc@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 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:D4405 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"8529fbba309cd692bbbb0386321515d05a6ed256/ghc" 8529fbba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8529fbba309cd692bbbb0386321515d05a6ed256" Get eqTypeRep to inline GHC didn't inline `eqTypeRep`, presumably because it ended up being too big. This was unfortunate because it produces a `Maybe`, which will almost always be scrutinized immediately. Split `eqTypeRep` into a worker and a tiny wrapper, and mark the wrapper `INLINABLE`. This change actually seems to reduce Core size, at least in a small test. Reviewers: hvr, bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, thomie, carter GHC Trac Issues: #14790 Differential Revision: https://phabricator.haskell.org/D4405 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 08:51:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 08:51:29 -0000 Subject: [GHC] #14790: eqTypeRep does not inline In-Reply-To: <045.4b63c72352430124262929413983410f@haskell.org> References: <045.4b63c72352430124262929413983410f@haskell.org> Message-ID: <060.afd95987f0a8f8f7a2f567bcba3ad65f@haskell.org> #14790: eqTypeRep does not inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4405 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 13:01:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 13:01:09 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.81313482d31d1fb44a08f5a5a7aa1ad6@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I tried reproducing the problem with GHC 8.2.1, but unfortunately the build instructions no longer work with Cabal 2.0.x. It seems that `fltkhs` doesn't support Cabal 2.0, and [this github issue](https://github.com/deech/fltkhs/issues/38) tells me this might not get fixed anytime soon. Is there an up-to-date way of reproducing the issue that I could use? Preferably one that doesn't involve `stack`, simply because I want to hook a custom-built GHC directly from git into the build so I can play with some things and cherry-pick selected changes, and this isn't trivial with stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 13:43:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 13:43:06 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.b06d1c355e1df6ea4e250e73148e546d@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by deech): Replying to [comment:14 tdammers]: > I tried reproducing the problem with GHC 8.2.1, but unfortunately the build instructions no longer work with Cabal 2.0.x. It seems that `fltkhs` doesn't support Cabal 2.0, and [this github issue](https://github.com/deech/fltkhs/issues/38) tells me this might not get fixed anytime soon. > > Is there an up-to-date way of reproducing the issue that I could use? Preferably one that doesn't involve `stack`, simply because I want to hook a custom-built GHC directly from git into the build so I can play with some things and cherry-pick selected changes, and this isn't trivial with stack. I should have closed that issue, the [master branch](https://github.com/deech/fltkhs) and the latest [stable release](https://hackage.haskell.org/package/fltkhs) [should](https://github.com/deech/fltkhs/blob/master/Setup.hs#L47) work with Cabal 2.0.0.2 and GHC 8.2.1. I'm happy to help you through it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 14:47:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 14:47:18 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.48af66d4da9753f19201215982695901@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Great catch. Indeed, I cannot reproduce the issue anymore with GHC 8.2.2, GHC 8.4.1, or HEAD with the program in comment:7, and moreover, I can compile `lambdabot-haskell-plugins` on GHC 8.2.2 in a reasonable amount of time with profiling enabled. Here's what you get for the Core for `list` on GHC HEAD: {{{ -- RHS size: {terms: 1, types: 0, coercions: 7, joins: 0/0} list :: Parser Expr list = Parser.list1 `cast` (Sym (Text.Parsec.Prim.N:ParsecT[0] <[Char]>_R <()>_R _R _R) :: (forall b. Text.Parsec.Prim.State [Char] () -> (Expr -> Text.Parsec.Prim.State [Char] () -> Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Expr -> Text.Parsec.Prim.State [Char] () -> Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> Data.Functor.Identity.Identity b :: *) ~R# (Text.Parsec.Prim.ParsecT [Char] () Data.Functor.Identity.Identity Expr :: *)) -- RHS size: {terms: 8, types: 32, coercions: 0, joins: 0/0} Parser.list1 :: forall b. Text.Parsec.Prim.State [Char] () -> (Expr -> Text.Parsec.Prim.State [Char] () -> Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Expr -> Text.Parsec.Prim.State [Char] () -> Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> Data.Functor.Identity.Identity b Parser.list1 = \ (@ b_X3Bv) _ [Occ=Dead] _ [Occ=Dead] _ [Occ=Dead] _ [Occ=Dead] _ [Occ=Dead] -> case Parser.list2 of wild_00 { } }}} Hooray! I'll add this as a test case, since GHC HEAD includes `parsec` as a boot library nowadays. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 14:53:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 14:53:02 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.3f77a48f4ebbc36746e4544b119efde8@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: patch 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:D4412 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4412 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 14:54:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 14:54:24 -0000 Subject: [GHC] #13943: Compiler infinite loop with GHC-8.2 In-Reply-To: <048.054af5c39346b78fae836436fb73b68c@haskell.org> References: <048.054af5c39346b78fae836436fb73b68c@haskell.org> Message-ID: <063.d2bd30dff553de6cea07214f16ad87f4@haskell.org> #13943: Compiler infinite loop with GHC-8.2 -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: dfeuer Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T13943 Blocked By: | Blocking: Related Tickets: #12791 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: merge => closed * milestone: 8.2.3 => 8.4.1 Comment: Sounds good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 15:17:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 15:17:00 -0000 Subject: [GHC] #14811: Unary unboxed tuple field causes interface file error In-Reply-To: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> References: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> Message-ID: <060.cc3fcb2ffce1f0439003fc05a1260286@haskell.org> #14811: Unary unboxed tuple field causes interface file error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: bgamari (added) Comment: This regression was introduced in 8fa4bf9ab3f4ea4b208f4a43cc90857987e6d497 (`Type-indexed Typeable`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 15:37:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 15:37:12 -0000 Subject: [GHC] #14812: Dot-Notation for Function Application Message-ID: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> #14812: Dot-Notation for Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Please allow to put a dot `.` (without spaces) between two things for ''flipped'' function application. This could make for code in pseudo-OOP style: {{{#!hs encrypt(str) = do { str.map(succ); } }}} Currently, as a workaround, this can be achieved by defining `(.) = flip ($)` (making `.` for function composition unavailable, though): {{{#!hs encrypt(str) = do { str.map(succ); } where (.) = flip ($) }}} (For a remotely similar look-and-feel, one could use `Data.Function.((&))` instead of `(.)`.) Please note that `.` without spaces is already an OOP-like notational convenience in order to denote Modules and their elements. {{{#!hs x = do { Prelude.length("Hello World!"); } }}} This means, that a distinction between ` . ` (with spaces) and `.` (without spaces) is already been made, which is why `Just . Just $ 42` compiles, wheras `Just.Just $ 42` doesn't. Analogously, with this Feature Request implemented, `"Hello".map(succ)` would compile whereas `"Hello" . map(succ)"` wouldn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 15:37:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 15:37:29 -0000 Subject: [GHC] #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order In-Reply-To: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> References: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> Message-ID: <065.d21c64f8376b6981c5f6eac9e5636fef@haskell.org> #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14529, #14796 | Differential Rev(s): Phab:D4413 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4413 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 15:37:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 15:37:39 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application (was: Dot-Notation for Function Application) In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.811c808d7c4d41f35ede983bc4ec2eeb@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 16:42:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 16:42:56 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.1c47283bba5379cff8e86029c49e151d@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Old description: > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || Needs revision || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || on-release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || ready || https://github.com/haskell/filepath/issues/65 > || > || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 > || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || needs revision || || > || `parsec` || needs release || > https://github.com/haskell/parsec/issues/86 || > || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || > || `primitive` || needs release || > https://github.com/haskell/primitive/issues/72 || > || `process` || ready || https://github.com/haskell/primitive/issues/72 > || > || `stm` || ready || #14698 || > || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || > || `text` || ready || https://github.com/haskell/text/issues/215 || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || Needs revision || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || ready || https://github.com/haskell/filepath/issues/65 || || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || || `parallel` || needs revision || || || `parsec` || needs release || https://github.com/haskell/parsec/issues/86 || || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || || `primitive` || ready || https://github.com/haskell/primitive/issues/72 || || `process` || ready || https://github.com/haskell/primitive/issues/72 || || `stm` || ready || #14698 || || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || || `text` || ready || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- Comment (by bgamari): `primitive` bumped to 0.6.3.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 16:44:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 16:44:15 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.d4e110158b16f320728a53f8072cfa01@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Old description: > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || Needs revision || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || on-release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || ready || https://github.com/haskell/filepath/issues/65 > || > || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 > || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || needs revision || || > || `parsec` || needs release || > https://github.com/haskell/parsec/issues/86 || > || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || > || `primitive` || ready || > https://github.com/haskell/primitive/issues/72 || > || `process` || ready || https://github.com/haskell/primitive/issues/72 > || > || `stm` || ready || #14698 || > || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || > || `text` || ready || https://github.com/haskell/text/issues/215 || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || Needs revision || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || ready || https://github.com/haskell/filepath/issues/65 || || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || || `parallel` || needs revision || || || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 || || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || || `primitive` || on-release || https://github.com/haskell/primitive/issues/72 || || `process` || ready || https://github.com/haskell/primitive/issues/72 || || `stm` || ready || #14698 || || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || || `text` || ready || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- Comment (by bgamari): Bumped `parsec` to 0.3.13.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 16:51:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 16:51:38 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.e5fcc0d020ab2aec7d43c41e886d38be@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || Needs revision || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || on-release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || ready || https://github.com/haskell/filepath/issues/65 > || > || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 > || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || needs revision || || > || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 > || > || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || > || `primitive` || on-release || > https://github.com/haskell/primitive/issues/72 || > || `process` || ready || https://github.com/haskell/primitive/issues/72 > || > || `stm` || ready || #14698 || > || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || > || `text` || ready || https://github.com/haskell/text/issues/215 || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || needs revision || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || ready || https://github.com/haskell/filepath/issues/65 || || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || || `parallel` || needs revision || || || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 || || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || || `primitive` || on-release || https://github.com/haskell/primitive/issues/72 || || `process` || ready || https://github.com/haskell/primitive/issues/72 || || `stm` || ready || #14698 || || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || || `text` || ready || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 16:57:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 16:57:53 -0000 Subject: [GHC] #14811: Unary unboxed tuple field causes interface file error In-Reply-To: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> References: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> Message-ID: <060.6460d78ef53768aee67e31b828fef5da@haskell.org> #14811: Unary unboxed tuple field causes interface file error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4414 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4414 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 18:50:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 18:50:13 -0000 Subject: [GHC] #14782: typeclass polymorphism defeats bang patterns In-Reply-To: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> References: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> Message-ID: <059.3206354a0b188940a232b94a7b2dfc5a@haskell.org> #14782: typeclass polymorphism defeats bang patterns -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: | MonomorphismRestriction Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmwit): Okay, I think I understand your explanation. But the more I think about this, the more it seems like there is still something a bit off in the current implementation. Here's an almost identical example, but with `Monoid` instead of `Num` to avoid having to think about defaulting: {{{ {-# LANGUAGE BangPatterns #-} main = let n :: Monoid a => a; !n = undefined in return () }}} Now that I have thought more carefully about what this means, I no longer understand why this is allowed to pass the type checker. If I'm following what you're saying, it seems like it ought to be an ambiguous type error, for exactly the same reason `main = seq (undefined :: Monoid a => a) (return ())` is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 20:24:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 20:24:02 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.e721e94eb6f642715538d2a1bde38c3f@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 bgamari): This is definitely a request that should go through [[https://github.com /ghc-proposals/ghc-proposals|GHC's proposal process]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 15 23:57:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Feb 2018 23:57:19 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.9463b4dbf5de4562f46e5f1da0b72c54@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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 Bodigrim): * owner: (none) => Bodigrim Comment: I'll continue with my patch this weekend, sorry for long delay. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 02:10:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 02:10:23 -0000 Subject: [GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is Message-ID: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC warns on this program: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# OPTIONS_GHC -Wall #-} module Bug where import Data.Kind import Data.Void data SBool (z :: Bool) where SFalse :: SBool 'False STrue :: SBool 'True type family F (b :: Bool) (a :: Type) :: Type where F 'True a = a F 'False _ = Void dispatch :: forall (b :: Bool) (a :: Type). SBool b -> F b a -> a dispatch STrue x = x dispatch SFalse x = case x of {} }}} {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:22:21: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ :: F b a | 22 | dispatch SFalse x = case x of {} | ^^^^ }}} This warning is incorrect, as `x` is of type `F 'False a`, or `Void`, in that case alternative. Curiously, if you ascribe either the pattern for `x`: {{{#!hs dispatch SFalse (x :: F 'False a) = case x of {} }}} Or the case scrutinee: {{{#!hs dispatch SFalse x = case x :: F 'False a of {} }}} Then the warning goes away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 08:14:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 08:14:15 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.81e8e4faadc8b85c3c497490c198b2e2@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 svenpanne): I don't even think this should go into the proposal process. The ``Foo.Bar.baz`` notation has nothing to do with OO, it is just about hierarchical names, which is a lexical issue. Furthermore, apart from the offside rule, whitespace should not have a meaning at all. Another complication/quiz: What should ``Foo.bar`` mean at all then? The hierarchical name ``Foo.bar`` or ``bar Foo`` (flipped application of the function ``bar`` to the constructor ``Foo``)? It can't be the latter, otherwise hierarchical names wouldn't work, so in addition to one exception to the language (whitespace matters) it would introduce another exception (. means something different if things look like a hierarchical name). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 08:40:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 08:40:09 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.843629edaa02ed72b9925fe201960aa2@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 tepan): Replying to [comment:2 bgamari]: > This is definitely a request that should go through [[https://github.com /ghc-proposals/ghc-proposals|GHC's proposal process]]. Sorry and thanks for the hint. What's the difference between GHC proposals and feature requests? Or where to find a FAQ that answers that? Thanks in advance! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 09:16:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 09:16:13 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.0b66eead80fe4b7965700f241ff566be@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 tepan): Replying to [comment:3 svenpanne]: Your premise is that whitespaces do or should only matter for indentation ("offside rule"), but they do matter as I pointed out, exactly when it comes to modules and the `.` syntax: `Foo . bar` is function composition of constructor `Foo` and function `bar`, whereas `Foo.bar` is `bar` of module `Foo`. The aim of my proposal is not to change that. Current dot-notation for modules (not to be changed): * `Foo.bar` (`bar` of module `Foo`) Proposed dot-notation for function application: * `foo.bar` (function `bar` applied to `foo`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 09:24:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 09:24:42 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.da4d6fd5a261be7323f8def3aedb87e5@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 tepan): Replying to [comment:3 svenpanne]: Side note: `Prelude.length("Hello")` in an OOP language is likely to refer to a (static) method `length` of class `Prelude` applied to `"Hello"`, hence my wording "OOP-like". Thanks for pointing it out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 09:34:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 09:34:33 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.a166165e8d99f7f35ae11db764a7c305@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by tepan: Old description: > Please allow to put a dot `.` (without spaces) between two things for > ''flipped'' function application. This could make for code in pseudo-OOP > style: > > {{{#!hs > encrypt(str) = do { > str.map(succ); > } > }}} > > Currently, as a workaround, this can be achieved by defining `(.) = flip > ($)` (making `.` for function composition unavailable, though): > > {{{#!hs > encrypt(str) = do { > str.map(succ); > } where (.) = flip ($) > }}} > > (For a remotely similar look-and-feel, one could use > `Data.Function.((&))` instead of `(.)`.) > > Please note that `.` without spaces is already an OOP-like notational > convenience in order to denote Modules and their elements. > > {{{#!hs > x = do { > Prelude.length("Hello World!"); > } > }}} > > This means, that a distinction between ` . ` (with spaces) and `.` > (without spaces) is already been made, which is why `Just . Just $ 42` > compiles, wheras `Just.Just $ 42` doesn't. Analogously, with this Feature > Request implemented, `"Hello".map(succ)` would compile whereas `"Hello" . > map(succ)"` wouldn't. New description: Please allow to put a dot `.` (without whitespaces) between two things for ''flipped'' function application. This could make for code in pseudo-OOP style: {{{#!hs encrypt(str) = do { str.map(succ); } }}} Currently, as a workaround, this can be achieved by defining `(.) = flip ($)` (making `.` for function composition unavailable, though): {{{#!hs encrypt(str) = do { str.map(succ); } where (.) = flip ($) }}} (For a remotely similar look-and-feel, one could use `Data.Function.((&))` instead of `(.)`.) Side note: `.` without whitespaces is already an OOP-like notational convenience in order to denote Modules and their elements in Haskell. OOP: * `Prelude.length("Hello")` (static function `length` of class `Prelude` applied to `"Hello"`) Haskell: * `Prelude.length("Hello")` (function `length` of module `Prelude` applied to `"Hello"`) This means, that a distinction between ` . ` (with whitespaces) and `.` (without whitespaces) is already been made, which is why `Just . Just $ 42` compiles, whereas `Just.Just $ 42` doesn't. Analogously, with this Feature Request implemented, `"Hello".map(succ)` would compile whereas `"Hello" . map(succ)"` wouldn't. Current dot-notation for modules (not to be changed): * `Foo.bar` (`bar` of module `Foo`) Proposed dot-noation for function application: * `foo.bar` (function `bar` applied to `foo`) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 10:36:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 10:36:41 -0000 Subject: [GHC] #14814: -g causes "cc failed in phase Assembler" in yaml package Message-ID: <047.0ec1c42d7c5cd9e380e117cf34df7306@haskell.org> #14814: -g causes "cc failed in phase Assembler" in yaml package -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!bash git clone https://github.com/snoyberg/yaml cd yaml git checkout yaml-0.8.28 stack build yaml --resolver=lts-10.5 --ghc-options='-g' }}} With this I get (I'm using nix below but should be irrelevant): {{{ [nix-shell:~/programming/yaml]$ stack build yaml --nix -j1 --resolver=lts-10.5 --ghc-options='-g' raw-strings-qq-1.1: download raw-strings-qq-1.1: configure raw-strings-qq-1.1: build raw-strings-qq-1.1: copy/register Building all executables for `yaml' once. After a successful build of all of them, only specified executables will be rebuilt. yaml-0.8.28: configure (lib + exe) Configuring yaml-0.8.28... yaml-0.8.28: build (lib + exe) Preprocessing library for yaml-0.8.28.. Building library for yaml-0.8.28.. [ 1 of 10] Compiling Text.Libyaml ( Text/Libyaml.hs, .stack- work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Text/Libyaml.o ) [ 2 of 10] Compiling Data.Yaml.Parser ( Data/Yaml/Parser.hs, .stack- work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Data/Yaml/Parser.o ) [ 3 of 10] Compiling Data.Yaml.Internal ( Data/Yaml/Internal.hs, .stack- work/dist/x86_64-linux-nix/Cabal-2.0.1.0/build/Data/Yaml/Internal.o ) /run/user/1000/ghc25193_0/ghc_30.s: Assembler messages: /home/shana/programming/yaml//run/user/1000/ghc25193_0/ghc_30.s:67519:0: error: Error: can't resolve `.Lc1azh_entry_end' {*UND* section} - `c1azh_entry' {*UND* section} | 67519 | .quad .Lc1azh_entry_end-c1azh_entry | ^ `cc' failed in phase `Assembler'. (Exit code: 1) Progress: 1/2 -- While building custom Setup.hs for package yaml-0.8.28 using: /home/shana/.stack/setup-exe-cache/x86_64-linux-nix/Cabal- simple_mPHDZzAJ_2.0.1.0_ghc-8.2.2 --builddir=.stack-work/dist/x86_64 -linux-nix/Cabal-2.0.1.0 build lib:yaml exe:examples exe:json2yaml exe:yaml2json --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics- color=always" Process exited with code: ExitFailure 1 Completed 2 action(s). }}} {{{ $ uname -a Linux kagami 4.14.12 #1-NixOS SMP Fri Jan 5 14:48:59 UTC 2018 x86_64 GNU/Linux }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 11:12:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 11:12:54 -0000 Subject: [GHC] #13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions? In-Reply-To: <054.7970fd47b788896732a324aafb5794c0@haskell.org> References: <054.7970fd47b788896732a324aafb5794c0@haskell.org> Message-ID: <069.fcee89cd9ddfa87aa4d07278058d8a7a@haskell.org> #13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions? -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): This looks like it would be a good GSoC project to me. What do others think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 11:25:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 11:25:01 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.5e06a5f6f7756c2ba1b0a53952253823@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 svenpanne): Just to reiterate a few points: The fact that `Foo.bar` is a single entity is a ''lexical'' issue, as you can see in the Haskell report (https://www.haskell.org/onlinereport/haskell2010/haskellch10.html#x17-17700010.2, look for ''modid''). Of course whitespace is relevant on that level. The initial proposal (https://mail.haskell.org/pipermail/libraries/2001-February/000258.html) already mentions that this syntax effectively steals some syntax with previously different semantics, but the consensus was that this is not nice, but OK: Hierarchical names are a big win and chaining constructors with dots but without whitespace was considered sufficiently rare. Your proposal would steal yet another syntax and give it completely different semantics for a very low benefit: `foo.bar` is currently semantically equivalent to `foo . bar`, and you propose to change that to `bar $ foo`. I bet this will break lots of code, and one should have a very, very good reason to do that. Emulating some surface syntax from a different programming paradigm is not really enough for that. Furthermore, you would introduce syntactic ambiguity for `Foo.bar`, because one can't distinguish module names and constructor names on the lexical level. This needs to be resolved to the meaning "hierarchical name", but obscure, non-regular things like this are warts in any language design, so plesase let's not do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 12:03:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 12:03:03 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.4d4d8c5a57c62da637de2a9eb4871966@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: 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): Could we not fix this by reverting 1fcede43d2b30f33b7505e25eb6b1f321be0407f ? Is there enough motivation to replace the evidence type? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 12:04:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 12:04:59 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.129cb99b38de2a0a527f10cc502f514f@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): Ok, I've just re-visited this issue and I've got one additional question. GHC.Base has definition of `(.)` like the following : {{{ (.) :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) ; {-# INLINE (.) #-} }}} @simonpj You've told that making own definition of (.) with one of its arguments strict, obviously affects the performance (makes the custom (.) implementation 40x faster in some use cases). I still consider it to be GHC bug even if we can justify it by some internal compiler design. If GHC is told to inline the `(.)` definition, why inlining such code into strict code doesn't make GHC automatically discover that every parameter was already strict there? Why inlining such definition makes strict code run slow? I'm looking at it from user perspective. For me telling users to have two definitions of (.) - one strict and one lazy and using strict one in strict code and lazy one in lazy code makes Haskell so hard to understand and so hard to use. Thus I believe we should consider this bug and should expect from GHC to automatically optimize usages of (.) in strict code. If I understand correctly, what happens here is that arguments to (.) are boxed (because (.) was defined as lazy) and are unboxed as soon as passed to `f` and `g`, because they were defined as strict. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 12:05:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 12:05:20 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.4eb6cc83e2dda759adf3a8a2de991b85@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danilo2): * status: closed => new * resolution: invalid => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 13:28:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 13:28:39 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.e70f61fcf3fbc0493e7f85d576e7f551@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 tepan): Replying to [comment:8 svenpanne]: I cannot argue with historical consensus and what is and isn't a "very, very good reason"/"warts in language design". So, if it's going to be "let's not do this", then "meh" it is. Concerning breaking old code, a language pragma `{-# LANGUAGE FlippedFunctionApplicationDot #-}` might provide the necessary backward- compatibility. But, so far, I haven't seen Haskell code with the dot-operator without white-spaces. It seems to be consensus (or at least advisable) to use the dot-operator with whitespaces, and to leave `.` without whitespaces only for module access. Thanks for the links, though. Maybe they will help me understand why, on a "lexical level" `Foo.bar` would cease to be unambiguously parsed as "`bar` of module `Foo`" once `foo.bar` would be parsed as "`bar` applied to `foo`". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 13:48:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 13:48:23 -0000 Subject: [GHC] #14814: -g causes "cc failed in phase Assembler" in yaml package In-Reply-To: <047.0ec1c42d7c5cd9e380e117cf34df7306@haskell.org> References: <047.0ec1c42d7c5cd9e380e117cf34df7306@haskell.org> Message-ID: <062.fd113cf22747e65d283538f2301de80e@haskell.org> #14814: -g causes "cc failed in phase Assembler" in yaml package -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14221 Comment: Thanks for the bug report. This is a duplicate of #14221, which is fixed in GHC 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 13:50:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 13:50:30 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.0ab149a46541a9877d63af063f370b69@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 goldfire): In my opinion, given that we have the ghc-proposals process now, I don't think we should have "Feature Request" tickets in Trac. Regardless, I do encourage you, @tepan, so post a proposal if you're keen on this. This debate is better there, where more eyes will see it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 13:51:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 13:51:55 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.238e5c8c227e842aca842c00a787fc29@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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: phadej (added) Comment: We certainly wouldn't want to revert that commit in its entirety (if that is the route we decide to embark on)—besides changing the evidence type, that commit also reworked `base` a bit to export a different API in the form of the `GHC.TypeNats` module. We could conceivably change the evidence type and keep the new API, but it would take some care. To be honest, I'm inclined to just wait for Bodigrim's patch. After all, these changes are already in a released version of GHC—I'd rather wait slightly longer to get things right. (cc'ing phadej, who authored 1fcede43d2b30f33b7505e25eb6b1f321be0407f) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 14:09:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 14:09:54 -0000 Subject: [GHC] #14815: -XStrict prevents code inlining. Message-ID: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> #14815: -XStrict prevents code inlining. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, let's consider the following code: {{{ {-# LANGUAGE Strict #-} -- Comment/uncommenting this {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} module K where import Control.Monad.Trans import qualified Control.Monad.State.Strict as S import Control.Monad.Primitive newtype StateT s m a = StateT (S.StateT s m a) -- S is Control.Monad.State.Strict deriving (Functor, Applicative, Monad, MonadTrans) instance PrimMonad m => PrimMonad (StateT s m) where type PrimState (StateT s m) = PrimState m primitive ~a = lift (primitive a) ; {-# INLINE primitive #-} }}} If compiled with `-XStrict` this code is not inlined properly and it badly affects the performance. While discussing it on Haskell IRC `lyxia` helped very much with discovering the CORE differences. The lazy version has couple of things which the strict version is missing in form of `[InlPrag=INLINE (sat-args=0)]` on toplevel identifiers. Core: https://gist.github.com/Lysxia/34684c9ca9fe4772ea38a5065414f542 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 14:14:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 14:14:53 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.2a85b4f40facdc1a3c4f596ae3983afd@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 AntC): Replying to [ticket:14812 tepan]: > Please allow to put a dot `.` (without whitespaces) between two things for ''flipped'' function application. This could make for code in pseudo- OOP style: Great idea! It's been suggested many times, including by SPJ https://prime.haskell.org/wiki/TypeDirectedNameResolution; and especially to represent field application to a record or struct, similar to OOP https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/DotPostfix. Sadly, it was shot down in flames; because it seems there's lots of code using dot as function composition not surrounded by whitespace -- for example, it's a common idiom with lenses. But I think worth asking again. As others have said, please submit a proposal on github. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 14:27:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 14:27:01 -0000 Subject: [GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is In-Reply-To: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> References: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> Message-ID: <065.cbbe5c1293306745ccf8a43e48ed9b7c@haskell.org> #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The line of code which is responsible for this infelicity is [http://git.haskell.org/ghc.git/blob/7c173b9043f7a9a5da46c5b0cc5fc3b38d1a7019:/compiler/deSugar/Check.hs#l415 here], within `checkEmptyCase'`: {{{#!hs mb_candidates <- inhabitationCandidates fam_insts (idType var) }}} But this is checking the inhabitation candidates of the raw `idType` of `x`, which is `F b a` instead of `F 'False a`. It seems that what needs to happen is that we need to take the local dictionary evidence in scope (i.e., `liftD getDictsDs`)—in this example, `b ~ 'False`—and somehow use that to turn `F b a` into `F 'False a`. On the other hand, I have no idea how one would do this, as `liftD getDictsDs` gives you a `Bag EvVar` instead of, say, a substitution, it's far from clear to me how you'd "apply" a `Bag EvVar`... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 14:28:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 14:28:47 -0000 Subject: [GHC] #14815: -XStrict prevents code inlining. In-Reply-To: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> References: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> Message-ID: <061.d0d3d584931a13803f16ab74610b4778@haskell.org> #14815: -XStrict prevents code inlining. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.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 lyxia): Maybe it's more correct to look at the interface rather than the simplifier. INLINE annotations still differ, but at least unfoldings appear in both. https://gist.github.com/Lysxia/355c4f1fa4ad0724c105d3baa42cbd4c -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 18:52:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 18:52:09 -0000 Subject: [GHC] #14811: Unary unboxed tuple field causes interface file error In-Reply-To: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> References: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> Message-ID: <060.62e01d1f1f23e821b0a53288094238c7@haskell.org> #14811: Unary unboxed tuple field causes interface file error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4414 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"d5ac5820111bc957e72c8ce11e59d7cbbdd63526/ghc" d5ac582/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d5ac5820111bc957e72c8ce11e59d7cbbdd63526" Fix #14811 by wiring in $tcUnit# Previously, we were skipping over `$tcUnit#` entirely when wiring in `Typeable` tycons, resulting in #14811. Easily fixed. Test Plan: make test TEST=T14811 Reviewers: bgamari, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, rwbarton, thomie, carter GHC Trac Issues: #14811 Differential Revision: https://phabricator.haskell.org/D4414 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 18:57:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 18:57:14 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? Message-ID: <045.816de325f41605669038c6c4fef6d573@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I compile {{{#!hs test :: (a -> a -> a) -> Int -> a -> HashMap Int a -> HashMap Int a test f k a m = insertModifying a (blink (f a)) k m blink :: (a -> b) -> a -> (# b #) -- Or blink g = \a -> (# g a #) ; it makes no difference. blink g a = (# g a #) }}} I get {{{ test = \ (@ a_a9o3) (f_a7iP :: a_a9o3 -> a_a9o3 -> a_a9o3) (k_a7iQ :: Int) (a1_a7iR :: a_a9o3) (m_a7iS :: HashMap Int a_a9o3) -> case k_a7iQ of { GHC.Types.I# ww1_sa1Z -> RULES.$w$sinsertModifying @ a_a9o3 a1_a7iR (let { g_s9E1 [Dmd=] :: a_a9o3 -> a_a9o3 [LclId] g_s9E1 = f_a7iP a1_a7iR } in \ (a2_a7iU :: a_a9o3) -> (# g_s9E1 a2_a7iU #)) ww1_sa1Z m_a7iS } }}} We build `g_s9E1 = f_a7iP a1_a7iR` for no apparent reason. Trouble persists into STG: {{{ RULES.test :: forall a. (a -> a -> a) -> GHC.Types.Int -> a -> Data.HashMap.Base.HashMap GHC.Types.Int a -> Data.HashMap.Base.HashMap GHC.Types.Int a [GblId, Arity=4, Str=, Unf=OtherCon []] = [] \r [f_saiX k_saiY a1_saiZ m_saj0] case k_saiY of { GHC.Types.I# ww1_saj2 [Occ=Once] -> let { g_saj3 [Occ=OnceL!, Dmd=] :: a_a9o3 -> a_a9o3 [LclId] = [f_saiX a1_saiZ] \u [] f_saiX a1_saiZ; } in let { sat_saj6 [Occ=Once] :: a_a9o3 -> (# a_a9o3 #) [LclId] = [g_saj3] \r [a2_saj4] let { sat_saj5 [Occ=Once] :: a_a9o3 [LclId] = [g_saj3 a2_saj4] \u [] g_saj3 a2_saj4; } in Unit# [sat_saj5]; } in RULES.$w$sinsertModifying a1_saiZ sat_saj6 ww1_saj2 m_saj0; }; }}} `insertModifying` uses its function argument at most once, so there is no possible benefit to this partial application. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 19:00:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 19:00:26 -0000 Subject: [GHC] #14811: Unary unboxed tuple field causes interface file error In-Reply-To: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> References: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> Message-ID: <060.a34f76928768102537f69fd3ea5995ee@haskell.org> #14811: Unary unboxed tuple field causes interface file error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4414 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => merge Comment: This was a fairly recent regression, and the fix is very small. It would be nice to get it merged to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 19:00:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 19:00:32 -0000 Subject: [GHC] #14815: -XStrict prevents code inlining. In-Reply-To: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> References: <046.08bab70ba7e4277e77ed3f217479b09d@haskell.org> Message-ID: <061.9acdc33fe9caf6620c1835d181cd65fe@haskell.org> #14815: -XStrict prevents code inlining. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.2.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 lyxia): In the previous link, one difference for example is, in `K.lazy-iface`, `$fPrimMonadStateT_$cprimitive` is marked `Inline: INLINE (sat-args=1)`, whereas in `K.strict-iface`, `$fPrimMonadStateT1` is not marked such, and also has a much larger unfolding for some reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 19:33:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 19:33:34 -0000 Subject: [GHC] #14782: typeclass polymorphism defeats bang patterns In-Reply-To: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> References: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> Message-ID: <059.5b286c7f3d92813834f9120fad20025f@haskell.org> #14782: typeclass polymorphism defeats bang patterns -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: | MonomorphismRestriction Operating System: 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): Let's look at your two examples: {{{#!hs main = seq (undefined :: Monoid a => a) (return ()) }}} The type-checker looks at the first argument of `seq` and sees something of `forall a. Monoid a => a`. So it instantiates this argument, providing a unification variable `t` and generating the constraint `Monoid t`. Later, the constraint solver discovers that it can't solve for `Monoid t`, and you've lost the game. {{{#!hs main = let n :: Monoid a => a; !n = undefined in return () }}} Here, the `undefined` is checked in an environment where we've quantified over `a` and can assume `Monoid a`, as is usual in the definition of a variable with a constrained type. No problem there. And, despite thinking of `!n` as desugaring to `seq n` somewhere, there is nowhere that GHC instantiates `n`. (Maybe you're arguing that we're not faithful to that desugaring... and you'd be right.) GHC just forces `n` right as it is, which exposes the lambda -- but not the `undefined` -- and then carries on. Does that help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 16 19:37:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Feb 2018 19:37:51 -0000 Subject: [GHC] #14782: typeclass polymorphism defeats bang patterns In-Reply-To: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> References: <044.996cfd7c03b2e2fdb2afecbd06afe714@haskell.org> Message-ID: <059.8793d678e05bd22db2da548dfb4002f4@haskell.org> #14782: typeclass polymorphism defeats bang patterns -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | MonomorphismRestriction 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 dmwit): * status: closed => new * resolution: invalid => Comment: If you agree that you are not faithful to the desugaring, then I feel justified in reopening this as a genuine bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 17 04:20:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Feb 2018 04:20:35 -0000 Subject: [GHC] #10822: GHC inconsistently handles \\?\ for long paths on Windows In-Reply-To: <047.7e6bb9965cce015f93541e4a1a931ae5@haskell.org> References: <047.7e6bb9965cce015f93541e4a1a931ae5@haskell.org> Message-ID: <062.83e8d05f0c7018f6e8396398674ee107@haskell.org> #10822: GHC inconsistently handles \\?\ for long paths on Windows ---------------------------------+---------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4416 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D4416 * milestone: => 8.6.1 Comment: GCC/libiberty still needs a patch but this takes care of the Haskell side. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 17 07:42:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Feb 2018 07:42:37 -0000 Subject: [GHC] #14817: GHC 8.4.1 pretty-prints data family instances with redundant kind signatures using -ddump-splices Message-ID: <050.79b05eb6509492d423346b61e70e23a4@haskell.org> #14817: GHC 8.4.1 pretty-prints data family instances with redundant kind signatures using -ddump-splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 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 this program: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| data family Foo :: * data instance Foo :: * |]) }}} On GHC 8.2.2, this gives the following `-ddump-splices` output: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(7,31): Splicing declarations [d| data family Foo_a1sB :: * data instance :: * |] ======> data family Foo_a494 :: GHC.Types.Type data instance :: GHC.Types.Type }}} But on GHC 8.4.1, we have: {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20180209: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(7,31): Splicing declarations [d| data family Foo_a1xd :: * data instance Foo_a1xd :: * :: * |] ======> data family Foo_a487 :: GHC.Types.Type data instance Foo_a487 :: GHC.Types.Type :: GHC.Types.Type }}} Notice how there is a redundant kind signature in `data instance Foo_a1xd :: * :: *`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 17 14:40:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Feb 2018 14:40:52 -0000 Subject: [GHC] #13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions? In-Reply-To: <054.7970fd47b788896732a324aafb5794c0@haskell.org> References: <054.7970fd47b788896732a324aafb5794c0@haskell.org> Message-ID: <069.511bf5bd85b42b4dc79616959312bb33@haskell.org> #13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions? -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): While technically the ptoject is of the right scale for a GSoC student, I'm a bit weary of suggesting it as a relatively small fraction of the community would stand to benefit from its completion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 17 14:59:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Feb 2018 14:59:50 -0000 Subject: [GHC] #9671: Allow expressions in patterns In-Reply-To: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> References: <051.5c0ed72ec50bbc2111e7cfd2e5c841ff@haskell.org> Message-ID: <066.06dd7263ae1039a95eb00f1fc1105392@haskell.org> #9671: Allow expressions in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Artyom.Kazak): * cc: Artyom.Kazak (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 17 19:43:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Feb 2018 19:43:16 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.d90d042c7bc149407491818a4a8da350@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by deech): I've put together a [https://github.com/deech/Trac12506 reduced example] that has the same issues. It's much easier to work with. In putting this together I noticed there is a vast difference in compilation time and memory between GHC 8.02 and GHC 8.22; the former takes 45 seconds and uses 1.4GB RAM to compile, the latter, 10 seconds and 200 MB so that is a great improvement. However while compilation speed is much improved between 8.0.2 and 8.2.2 that still only brings it up to par with GHC 7.10 which is GHC version against which I reported the issue in the first place so the problem still exists. Hopefully this reduced example helps clarify the underlying issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 17 19:44:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Feb 2018 19:44:49 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.abd63eb596f30cfc1ac695f8ed8b6d69@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Sorry. I commented here, but my comment seems to have disappeared… probably did not send it. > `insertModifying` uses its function argument at most once, so there is no possible benefit to this partial application. but does GHC know this (non-local) fact? What is the strictness signature of `RULES.$w$sinsertModifying`. Also, what is the Core directly after Call Arity? (`-ddump-call-arity`)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 17 19:47:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Feb 2018 19:47:49 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.510730f11f9be6ec04ff8e515b87b495@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Also, if call arity is too stupid, you might avoid the problem by using `oneShot` in the right place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 17 20:09:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Feb 2018 20:09:30 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.08affdfc5086393bd96387a73f16b15a@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by deech): I've added a rough [https://github.com/deech/Trac12506#compile-timememory- usage-comparisons comparison table] showing compile times and memory usage going back to 7.8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 17 22:59:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Feb 2018 22:59:14 -0000 Subject: [GHC] #13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions? In-Reply-To: <054.7970fd47b788896732a324aafb5794c0@haskell.org> References: <054.7970fd47b788896732a324aafb5794c0@haskell.org> Message-ID: <069.8a4d91ea02d07160c486a12d34521bde@haskell.org> #13852: Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions? -------------------------------------+------------------------------------- Reporter: leftaroundabout | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.1 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): Maybe there are other bits of the code generator which would give more bang for buck? I think I will propose this anyway but with a comment to ask the GSoC student to spend a few days seeing if this is the highest priority (but doable) part of the CG that needs addressing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 17 23:42:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Feb 2018 23:42:43 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.275b9438f6326b93ecd818cf74c98a70@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): I'm giving this ticket a try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 02:40:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 02:40:05 -0000 Subject: [GHC] #14817: GHC 8.4.1 pretty-prints data family instances with redundant kind signatures using -ddump-splices In-Reply-To: <050.79b05eb6509492d423346b61e70e23a4@haskell.org> References: <050.79b05eb6509492d423346b61e70e23a4@haskell.org> Message-ID: <065.d175912973390987aef8dd10b38597cf@haskell.org> #14817: GHC 8.4.1 pretty-prints data family instances with redundant kind signatures using -ddump-splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 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:D4418 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4418 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 03:45:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 03:45:28 -0000 Subject: [GHC] #14818: Provide highestOneBit function in Data.Bits module Message-ID: <045.4448296efa961e19c5d039ee8f2127a8@haskell.org> #14818: Provide highestOneBit function in Data.Bits module -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This function yields the [https://stackoverflow.com/a/17379704/105137 largest power of 2 less than or equal to the given number]. Relative to the Java standard library, which [https://docs.oracle.com/javase/7/docs/api/java/lang/Integer.html#highestOneBit(int) provides this function], there is a gap in the Haskell library, even though the Haskell docs [https://hackage.haskell.org/package/base-4.10.1.0/docs/Data- Bits.html#v:countLeadingZeros describe a method to calculate logBase2 via the `countLeadingZeros` function]. From the Java documentation: > The implementations of the "bit twiddling" methods (such as `highestOneBit` and `numberOfTrailingZeros`) are based on material from Henry S. Warren, Jr.'s ''Hacker's Delight'', (Addison Wesley, 2002). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 04:26:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 04:26:29 -0000 Subject: [GHC] #14819: GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling Message-ID: <046.3cff902adb709d7e7df64a2fe7e8f873@haskell.org> #14819: GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling -------------------------------------+------------------------------------- Reporter: clinton | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.2.2 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 GHC docs for GeneralisedNewtypeDeriving at (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #generalised-derived-instances-for-newtypes) suggest British spelling should be accepted, and indeed it's the preferred spelling in the docs. However GHC 8.2 throws an error. I haven't tested this against HEAD so if it's fixed there please feel free to close. I know this is a bit picky but it's caught me out a few times and I couldn't see it previously reported (I may have missed it though). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 11:35:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 11:35:12 -0000 Subject: [GHC] #14819: GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling In-Reply-To: <046.3cff902adb709d7e7df64a2fe7e8f873@haskell.org> References: <046.3cff902adb709d7e7df64a2fe7e8f873@haskell.org> Message-ID: <061.ddbda5217c5a558720b51c55a3dd20bf@haskell.org> #14819: GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling -------------------------------------+------------------------------------- Reporter: clinton | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Happens in HEAD too. Looking at `DynFlags` at the time when `-XGeneralisedNewtypeDeriving` added, I think this version of the flag was never supported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 13:14:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 13:14:23 -0000 Subject: [GHC] #14820: MultiFunctionalDependencies Message-ID: <044.0fcd53c17d342a3cdec4f68c004621d2@haskell.org> #14820: MultiFunctionalDependencies -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 13:49:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 13:49:42 -0000 Subject: [GHC] #14420: Data families should not instantiate to non-Type kinds In-Reply-To: <047.a64d114cfae11861b31f70375118e394@haskell.org> References: <047.a64d114cfae11861b31f70375118e394@haskell.org> Message-ID: <062.ecfa991aa1c92f76cb89d5f8c78a2ebf@haskell.org> #14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kcsongor): * cc: kcsongor (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 15:47:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 15:47:09 -0000 Subject: [GHC] #14818: Provide highestOneBit function in Data.Bits module In-Reply-To: <045.4448296efa961e19c5d039ee8f2127a8@haskell.org> References: <045.4448296efa961e19c5d039ee8f2127a8@haskell.org> Message-ID: <060.12b1aab96397989ff95bd6714af27c28@haskell.org> #14818: Provide highestOneBit function in Data.Bits module -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.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 nomeata): JFTR: The `containers` library needs this function, and defines it in its `Utils` module: http://hackage.haskell.org/package/containers-0.5.11.0/docs/Utils- Containers-Internal-BitUtil.html: {{{ -- The highestBitMask implementation is based on -- http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 -- which has been put in the public domain. -- | Return a word where only the highest bit is set. highestBitMask :: Word -> Word highestBitMask x1 = let x2 = x1 .|. x1 `shiftRL` 1 x3 = x2 .|. x2 `shiftRL` 2 x4 = x3 .|. x3 `shiftRL` 4 x5 = x4 .|. x4 `shiftRL` 8 x6 = x5 .|. x5 `shiftRL` 16 #if !(defined(__GLASGOW_HASKELL__) && WORD_SIZE_IN_BITS==32) x7 = x6 .|. x6 `shiftRL` 32 in x7 `xor` (x7 `shiftRL` 1) #else in x6 `xor` (x6 `shiftRL` 1) #endif {-# INLINE highestBitMask #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 15:59:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 15:59:26 -0000 Subject: [GHC] #14768: -O1 changes result at runtime, duplicating __DEFAULT case In-Reply-To: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> References: <047.b112f10ba6567e53d5ca21917b1286e6@haskell.org> Message-ID: <062.14f46522ba10e9332615b59cf3317b3e@haskell.org> #14768: -O1 changes result at runtime, duplicating __DEFAULT case -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_run/T14768 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 4e0b4b36aca29b4d67df5f36d1a06bdfdfeec612. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 15:59:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 15:59:50 -0000 Subject: [GHC] #14763: GHC 8.4.1-alpha regression with FunctionalDependencies In-Reply-To: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> References: <050.95a12d878b0c31e5b32fa24f9d9b8854@haskell.org> Message-ID: <065.e05b2959898aa877b97166660aa38e70@haskell.org> #14763: GHC 8.4.1-alpha regression with FunctionalDependencies -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha3 checker) | Resolution: fixed | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/typecheck/should_compile/T14763 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as f2bb550eb745d57afbc574e02900653281ae0212. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:01:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:01:16 -0000 Subject: [GHC] #14821: -O2 forces -optlo-O3 in a way that cannot be overridden at command line Message-ID: <047.f0bbe76f7e62f3251e5a424f7cdfd4d3@haskell.org> #14821: -O2 forces -optlo-O3 in a way that cannot be overridden at command line -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I would expect -O2 -optlo-O2 to pass -O2 to the llvm optimiser. However, it seems that -O2 implies -optlo-O3, overriding the command-line's -optlo-O2. The workaround seems to be to use -O1 -optlo-O2, but of course this misses some ghc optimizations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:12:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:12:57 -0000 Subject: [GHC] #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? In-Reply-To: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> References: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> Message-ID: <065.f8f5f946e872abfe7816caf2df10fdbc@haskell.org> #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: deriving, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4402 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:18:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:18:32 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.dace0ec8d92e679959aa85ed9dbf3dd4@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || needs revision || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || on-release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || ready || https://github.com/haskell/filepath/issues/65 > || > || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 > || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || needs revision || || > || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 > || > || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || > || `primitive` || on-release || > https://github.com/haskell/primitive/issues/72 || > || `process` || ready || https://github.com/haskell/primitive/issues/72 > || > || `stm` || ready || #14698 || > || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || > || `text` || ready || https://github.com/haskell/text/issues/215 || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || revised || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || ready || https://github.com/haskell/filepath/issues/65 || || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || || `parallel` || revised || || || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 || || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || || `primitive` || on-release || https://github.com/haskell/primitive/issues/72 || || `process` || ready || https://github.com/haskell/primitive/issues/72 || || `stm` || ready || #14698 || || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || || `text` || ready || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:24:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:24:17 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.22786eef466ab0d22160b79fecda3859@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || revised || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || on-release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || ready || https://github.com/haskell/filepath/issues/65 > || > || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 > || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || revised || || > || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 > || > || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || > || `primitive` || on-release || > https://github.com/haskell/primitive/issues/72 || > || `process` || ready || https://github.com/haskell/primitive/issues/72 > || > || `stm` || ready || #14698 || > || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || > || `text` || ready || https://github.com/haskell/text/issues/215 || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || revised || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || ready || https://github.com/haskell/filepath/issues/65 || || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || || `parallel` || revised || || || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 || || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || || `primitive` || on-release || https://github.com/haskell/primitive/issues/72 || || `process` || ready || https://github.com/haskell/process/issues/114 || || `stm` || ready || #14698 || || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || || `text` || ready || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:27:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:27:20 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.5a04cfc831314b4ed037505957e4e531@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || revised || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || on-release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || ready || https://github.com/haskell/filepath/issues/65 > || > || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 > || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || revised || || > || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 > || > || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || > || `primitive` || on-release || > https://github.com/haskell/primitive/issues/72 || > || `process` || ready || https://github.com/haskell/process/issues/114 || > || `stm` || ready || #14698 || > || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || > || `text` || ready || https://github.com/haskell/text/issues/215 || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: * `needs revision`: No interface changes needed; only a bounds bump necessary * `revised`: Revised bounds uploaded to Hackage * `needs release`: Waiting for upstream to tag and upload release * `ready`: Final version has been released * `on-release`: Final version has been released and submodule bumped ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || revised || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || ready || https://github.com/haskell/filepath/issues/65 || || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || || `parallel` || revised || || || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 || || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || || `primitive` || on-release || https://github.com/haskell/primitive/issues/72 || || `process` || ready || https://github.com/haskell/process/issues/114 || || `stm` || ready || #14698 || || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || || `text` || ready || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:31:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:31:09 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.b9bea7210107b5ca855027d3b1db1491@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > * `needs revision`: No interface changes needed; only a bounds bump > necessary > * `revised`: Revised bounds uploaded to Hackage > * `needs release`: Waiting for upstream to tag and upload release > * `ready`: Final version has been released > * `on-release`: Final version has been released and submodule bumped > > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || revised || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || on-release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || ready || https://github.com/haskell/filepath/issues/65 > || > || `haskeline` || ready || https://github.com/judah/haskeline/issues/75 > || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || revised || || > || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 > || > || `pretty` || ready || https://github.com/haskell/pretty/issues/47 || > || `primitive` || on-release || > https://github.com/haskell/primitive/issues/72 || > || `process` || ready || https://github.com/haskell/process/issues/114 || > || `stm` || ready || #14698 || > || `terminfo` || ready || https://github.com/judah/terminfo/issues/27 || > || `text` || ready || https://github.com/haskell/text/issues/215 || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: * `needs revision`: No interface changes needed; only a bounds bump necessary * `revised`: Revised bounds uploaded to Hackage * `needs release`: Waiting for upstream to tag and upload release * `ready`: Final version has been released * `on-release`: Final version has been released and submodule bumped ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || revised || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || on-release || https://github.com/haskell/filepath/issues/65 || || `haskeline` || on-release || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || || `parallel` || revised || || || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 || || `pretty` || on-release || https://github.com/haskell/pretty/issues/47 || || `primitive` || on-release || https://github.com/haskell/primitive/issues/72 || || `process` || on-release || https://github.com/haskell/process/issues/114 || || `stm` || on-release || #14698 || || `terminfo` || on-release || https://github.com/judah/terminfo/issues/27 || || `text` || ready || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:32:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:32:07 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.e4d31b264cda3b167e73f3eb85ba5d50@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > * `needs revision`: No interface changes needed; only a bounds bump > necessary > * `revised`: Revised bounds uploaded to Hackage > * `needs release`: Waiting for upstream to tag and upload release > * `ready`: Final version has been released > * `on-release`: Final version has been released and submodule bumped > > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || revised || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || on-release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || on-release || > https://github.com/haskell/filepath/issues/65 || > || `haskeline` || on-release || > https://github.com/judah/haskeline/issues/75 || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || revised || || > || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 > || > || `pretty` || on-release || https://github.com/haskell/pretty/issues/47 > || > || `primitive` || on-release || > https://github.com/haskell/primitive/issues/72 || > || `process` || on-release || > https://github.com/haskell/process/issues/114 || > || `stm` || on-release || #14698 || > || `terminfo` || on-release || > https://github.com/judah/terminfo/issues/27 || > || `text` || ready || https://github.com/haskell/text/issues/215 || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: * `needs revision`: No interface changes needed; only a bounds bump necessary * `revised`: Revised bounds uploaded to Hackage * `needs release`: Waiting for upstream to tag and upload release * `ready`: Final version has been released * `on-release`: Final version has been released and submodule bumped ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || revised || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || on-release || https://github.com/haskell/filepath/issues/65 || || `haskeline` || on-release || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || || `parallel` || revised || || || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 || || `pretty` || on-release || https://github.com/haskell/pretty/issues/47 || || `primitive` || on-release || https://github.com/haskell/primitive/issues/72 || || `process` || on-release || https://github.com/haskell/process/issues/114 || || `stm` || on-release || #14698 || || `terminfo` || on-release || https://github.com/judah/terminfo/issues/27 || || `text` || on-release || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:59:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:59:53 -0000 Subject: [GHC] #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? In-Reply-To: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> References: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> Message-ID: <065.7f2ca517aee47aea34fea37f1f905175@haskell.org> #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: deriving, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4402 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1ede46d415757f53af33bc6672bd9d3fba7f205d/ghc" 1ede46d4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1ede46d415757f53af33bc6672bd9d3fba7f205d" Implement stopgap solution for #14728 It turns out that one can produce ill-formed Core by combining `GeneralizedNewtypeDeriving`, `TypeInType`, and `TypeFamilies`, as demonstrated in #14728. The root of the problem is allowing the last parameter of a class to appear in a //kind// of an associated type family, as our current approach to deriving associated type family instances simply doesn't work well for that situation. Although it might be possible to properly implement this feature today (see https://ghc.haskell.org/trac/ghc/ticket/14728#comment:3 for a sketch of how this might work), there does not currently exist a performant implementation of the algorithm needed to accomplish this. Until such an implementation surfaces, we will make this corner case of `GeneralizedNewtypeDeriving` an error. Test Plan: make test TEST="T14728a T14728b" Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14728 Differential Revision: https://phabricator.haskell.org/D4402 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:59:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:59:54 -0000 Subject: [GHC] #14787: Remove StgLint type checks In-Reply-To: <043.b42d9efeb50c0ccd29b8b0185debbec2@haskell.org> References: <043.b42d9efeb50c0ccd29b8b0185debbec2@haskell.org> Message-ID: <058.b930db6b9a8c188900388292aa379513@haskell.org> #14787: Remove StgLint type checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4404 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7f389a580f42a105623853adad15ab3323b41ed5/ghc" 7f389a58/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7f389a580f42a105623853adad15ab3323b41ed5" StgLint overhaul - Remove all type checks - Check two STG invariants (no unboxed let bindings, variables defined before used) and post-unarisation invariants. See the module header and #14787. This version validates with `-dstg-lint` added to `GhcStage2HcOpts` and `GhcLibHcOpts` and `EXTRA_HC_OPTS`. Unarise changes: - `unariseConArgBinder` and `unariseFunArgBinder` functions were almost the same; only difference was when unarising fun args we keep void args while in con args we drop them. A new function `unariseArgBinder` added with a `Bool` argument for whether we're unarising a con arg. `unariseConArgBinder` and `unariseFunArgBinder` are now defined as unariseConArgBinder = unarsieArgBinder True -- data con unariseFunArgBinder = unariseArgBinder False -- not data con - A bug in `unariseConArgBinder` and `unariseFunArgBinder` (which are just calls to `unariseArgBinder` now) that invalidated the post-unarise invariants when the argument has single type rep (i.e. `length (typePrimRep x) == 1`) fixed. This isn't a correctness issue (it's fine not to unarise if a variable is already represented as single value), but it triggers StgLint. Test Plan: - Pass testsuite with `-dstg-lint` [done] - Boot stage2 (including libraries) with `-dstg-lint` [done] Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: duog, rwbarton, thomie, carter GHC Trac Issues: #14787 Differential Revision: https://phabricator.haskell.org/D4404 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:59:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:59:53 -0000 Subject: [GHC] #14761: Incorrect diagnostic for UNPACK/missing strictness In-Reply-To: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> References: <047.a9957a185a6b53ba929f1216d03f36d2@haskell.org> Message-ID: <062.8c06ac1542a08e7d03ff847c19ccfb97@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7210 | Differential Rev(s): Phab:D4397 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fc33f8b31b9c23cc12f02a028bbaeab06ba8fe96/ghc" fc33f8b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fc33f8b31b9c23cc12f02a028bbaeab06ba8fe96" Improve error message for UNPACK/strictness annotations. Print different error message for improper UNPACK and strictness annotations. Fix Trac #14761. Signed-off-by: HE, Tao Test Plan: make test TEST="T7210 T14761a T14761b" Reviewers: goldfire, bgamari, RyanGlScott, simonpj Reviewed By: RyanGlScott, simonpj Subscribers: simonpj, goldfire, rwbarton, thomie, carter GHC Trac Issues: #14761 Differential Revision: https://phabricator.haskell.org/D4397 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:59:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:59:54 -0000 Subject: [GHC] #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order In-Reply-To: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> References: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> Message-ID: <065.1d6a2a1bb65089acab4543f327a4060a@haskell.org> #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14529, #14796 | Differential Rev(s): Phab:D4413 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"043466b9aac403553e2aaf8054c064016f963f80/ghc" 043466b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="043466b9aac403553e2aaf8054c064016f963f80" Rename the types in a GADT constructor in toposorted order Previously, we were extracting the free variables from a GADT constructor in an incorrect order, which caused the type variables for the constructor's type signature to end up in non-toposorted order. Thankfully, rearranging the order of types during renaming makes swift work of this bug. This fixes a regression introduced in commit fa29df02a1b0b926afb2525a258172dcbf0ea460. For whatever reason, that commit also commented out a significant portion of the `T13123` test. This code appears to work, so I've opted to uncomment it. Test Plan: make test TEST=T14808 Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14808 Differential Revision: https://phabricator.haskell.org/D4413 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 16:59:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 16:59:53 -0000 Subject: [GHC] #14226: Common Block Elimination pass doesn't eliminate common blocks In-Reply-To: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> References: <046.64e654c74c7432ac06e937473b6324b1@haskell.org> Message-ID: <061.48d1063b7efd34e7130f24817a40bdd1@haskell.org> #14226: Common Block Elimination pass doesn't eliminate common blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: michalt Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 (CodeGen) | Keywords: newcomer, Resolution: | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9157, #14754 | Differential Rev(s): Phab:D3973, Wiki Page: | Phab:D3999 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4e513bf758c32804fc71b98215f96e8481697a36/ghc" 4e513bf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4e513bf758c32804fc71b98215f96e8481697a36" CBE: re-introduce bgamari's fixes During some recent work on CBE we discovered that `zipWith` is used to check for equality, but that doesn't quite work if lists are of different lengths! This was fixed by bgamari, but unfortunately the fix had to be rolled back due to other changes in CBE in 50adbd7c5fe5894d3e6e2a58b353ed07e5f8949d. Since I wanted to have another look at CBE anyway, we agreed that the first thing to do would be to re-introduce the fix. Sadly I don't have any actual test case that would exercise this. Signed-off-by: Michal Terepeta Test Plan: ./validate Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14226 Differential Revision: https://phabricator.haskell.org/D4387 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 17:02:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 17:02:02 -0000 Subject: [GHC] #14787: Remove StgLint type checks In-Reply-To: <043.b42d9efeb50c0ccd29b8b0185debbec2@haskell.org> References: <043.b42d9efeb50c0ccd29b8b0185debbec2@haskell.org> Message-ID: <058.a51a6f75c72351cc4d2d614e888e03f1@haskell.org> #14787: Remove StgLint type checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 17:02:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 17:02:11 -0000 Subject: [GHC] #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order In-Reply-To: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> References: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> Message-ID: <065.18617371127bfdb8eba346c54bafec11@haskell.org> #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14529, #14796 | Differential Rev(s): Phab:D4413 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 17:08:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 17:08:25 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.0ff35473eb8660eab87fcdddba7be6aa@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kcsongor): * cc: kcsongor (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 17:15:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 17:15:04 -0000 Subject: [GHC] #9429: Alternative to type family Any In-Reply-To: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> References: <044.bec1242c5bc4b988ef076d40a7a5f5dc@haskell.org> Message-ID: <059.13ba9c10648147ba7cf5d7b1f525d57a@haskell.org> #9429: Alternative to type family Any -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 9097, 9380 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kcsongor): * cc: kcsongor (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 18:30:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 18:30:51 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.5495f4278766863cef07edceee51e985@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * owner: (none) => sjakobi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 19:38:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 19:38:07 -0000 Subject: [GHC] #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) In-Reply-To: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> References: <052.7cf8871089bbe0aab7ba792447e09946@haskell.org> Message-ID: <067.a21575088d37b0ebe299614538f8bb36@haskell.org> #13185: haskell-relational-query: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: LocutusOfBorg | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.2 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: build crash or panic | relational-query with ghc 8.0.2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.2 Comment: `relational-query-0.11.0.0` builds fine with GHC 8.2.2. I suspect that this is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 19:40:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 19:40:55 -0000 Subject: [GHC] #13994: STG lint failure on master In-Reply-To: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> References: <046.5016d5ec5ebb8180ad382ac86e8db74e@haskell.org> Message-ID: <061.860c431c6ddb9167a6345cfc1336526a@haskell.org> #13994: STG lint failure on master -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14787 | Differential Rev(s): Phab:D4404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This was resolved via #14787. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 18 19:45:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Feb 2018 19:45:59 -0000 Subject: [GHC] #14811: Unary unboxed tuple field causes interface file error In-Reply-To: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> References: <045.8821c734f29bd5d1ac13b473ea1e894c@haskell.org> Message-ID: <060.7ced210bbb4cef3d9027e268889cbd01@haskell.org> #14811: Unary unboxed tuple field causes interface file error -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | 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): Phab:D4414 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.6.1 => 8.4.1 Comment: Merged with a66ddb5599a71c31be5f95972156e86debb3c7bf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 01:58:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 01:58:00 -0000 Subject: [GHC] #14821: -O2 forces -optlo-O3 in a way that cannot be overridden at command line In-Reply-To: <047.f0bbe76f7e62f3251e5a424f7cdfd4d3@haskell.org> References: <047.f0bbe76f7e62f3251e5a424f7cdfd4d3@haskell.org> Message-ID: <062.6d586faf5431d663cde87100195d05dd@haskell.org> #14821: -O2 forces -optlo-O3 in a way that cannot be overridden at command line -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4421 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4421 Comment: I suspect that Phab:D4421 will resolve this although I haven't yet tested it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 02:04:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 02:04:52 -0000 Subject: [GHC] #14820: MultiFunctionalDependencies In-Reply-To: <044.0fcd53c17d342a3cdec4f68c004621d2@haskell.org> References: <044.0fcd53c17d342a3cdec4f68c004621d2@haskell.org> Message-ID: <059.e7ef418274108d1cf634a9a56e9edf40@haskell.org> #14820: MultiFunctionalDependencies -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 bgamari): I'm afraid we'll need a bit of elaboration to know what this means. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 02:27:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 02:27:07 -0000 Subject: [GHC] #14818: Provide highestOneBit function in Data.Bits module In-Reply-To: <045.4448296efa961e19c5d039ee8f2127a8@haskell.org> References: <045.4448296efa961e19c5d039ee8f2127a8@haskell.org> Message-ID: <060.aaacc2da0b7ae1f72bd5e55830ccea4f@haskell.org> #14818: Provide highestOneBit function in Data.Bits module -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.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 bgamari): If I understand correctly, we already have these: * `countLeadingZeros` is `GHC.Prim.clzN#`, which is exposed by `Data.Bits.countLeadingZeros`. * `highestOneBit` is `GHC.Prim.ctzN#`, which is exposed by `Data.Bits.countTrailingZeros` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 02:28:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 02:28:21 -0000 Subject: [GHC] #14818: Provide highestOneBit function in Data.Bits module In-Reply-To: <045.4448296efa961e19c5d039ee8f2127a8@haskell.org> References: <045.4448296efa961e19c5d039ee8f2127a8@haskell.org> Message-ID: <060.acebd33cdeb60d2529bb845b54395bc5@haskell.org> #14818: Provide highestOneBit function in Data.Bits module -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 02:36:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 02:36:57 -0000 Subject: [GHC] #14819: GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling In-Reply-To: <046.3cff902adb709d7e7df64a2fe7e8f873@haskell.org> References: <046.3cff902adb709d7e7df64a2fe7e8f873@haskell.org> Message-ID: <061.2c64ccbe4c9558c0ca3f82fe698fc0a9@haskell.org> #14819: GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling -------------------------------------+------------------------------------- Reporter: clinton | Owner: (none) Type: bug | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4372 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4372 Comment: Indeed this has caught me by surprise as well. Fixed in Phab:D4372. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 02:53:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 02:53:19 -0000 Subject: [GHC] #14818: Provide highestOneBit function in Data.Bits module In-Reply-To: <045.4448296efa961e19c5d039ee8f2127a8@haskell.org> References: <045.4448296efa961e19c5d039ee8f2127a8@haskell.org> Message-ID: <060.09c8285d0dfb1d5e176c9e0a84d6de3b@haskell.org> #14818: Provide highestOneBit function in Data.Bits module -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * cc: core-libraries-committee@… (added) * resolution: fixed => * milestone: 7.10.1 => Comment: Whoops, my apologies; I clearly misunderstood the description. I see now that you are actually proposing a new addition to `Data.Bits`. I think it would be best if this request went through the [[https://wiki.haskell.org/Core_Libraries_Committee|core libraries process]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 03:14:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 03:14:15 -0000 Subject: [GHC] #14818: Provide highestOneBit function in Data.Bits module In-Reply-To: <045.4448296efa961e19c5d039ee8f2127a8@haskell.org> References: <045.4448296efa961e19c5d039ee8f2127a8@haskell.org> Message-ID: <060.a15aa65bfe9d52a1efc2640d24866352@haskell.org> #14818: Provide highestOneBit function in Data.Bits module -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4102 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #4102 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 03:14:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 03:14:41 -0000 Subject: [GHC] #4102: Bit manipulation built-ins In-Reply-To: <049.9814fd052d90f7d2841adf98c6e4a213@haskell.org> References: <049.9814fd052d90f7d2841adf98c6e4a213@haskell.org> Message-ID: <064.016a7e0d67ff51ab96d92562f49d64f2@haskell.org> #4102: Bit manipulation built-ins -------------------------------------+------------------------------------- Reporter: uzytkownik | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Core Libraries | Version: 6.12.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14819 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #14819 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 04:16:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 04:16:07 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.aa44fa73f03b04f596c59e6d3a9dcd0d@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks deech! We can try to have someone look at this soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 05:20:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 05:20:52 -0000 Subject: [GHC] #14822: -XQuantifiedConstraints: Turn term-level entailments (:-) into constraints (=>) Message-ID: <051.11128ae44d764b8f1b3394d8184f1010@haskell.org> #14822: -XQuantifiedConstraints: Turn term-level entailments (:-) into constraints (=>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints, wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code works fine: {{{#!hs {-# Language TypeOperators, RankNTypes, KindSignatures, GADTs, DataKinds, MultiParamTypeClasses, FlexibleInstances, ConstraintKinds, ScopedTypeVariables #-} import Data.Kind -- 'constraints' machinery data Dict c where Dict :: c => Dict c newtype a :- b = Sub (a => Dict b) -- entailment -- 'singletons' machinery data SBool :: Bool -> Type where SFalse :: SBool 'False STrue :: SBool 'True class SBoolI (bool::Bool) where sbool :: SBool bool instance SBoolI 'False where sbool = SFalse instance SBoolI 'True where sbool = STrue -- VVV Example VVV class Funny (b::Bool) (b'::Bool) instance Funny 'False b' instance Funny 'True 'True instance Funny 'True 'False proof :: forall b b'. (SBoolI b, SBoolI b') :- Funny b b' proof = Sub (case (sbool :: SBool b, sbool :: SBool b') of (SFalse, _) -> Dict (STrue, SFalse) -> Dict (STrue, STrue) -> Dict) -- ^^^ Example ^^^ }}} What I'm interested in is the entailment: Singletons for `b` and `b'` entail `Funny b b'`. This is witnessed by `proof`. Given that we have a branch for `-XQuantifiedConstraints`, it is tantalizing to convert this into an implication constraint `(SBoolI b, SBoolI b') => Funny b b'`. Is such a thing sensible (wrt coherence) and if so is it at all possible to do this on WIPT2893? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 11:28:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 11:28:27 -0000 Subject: [GHC] #14822: -XQuantifiedConstraints: Turn term-level entailments (:-) into constraints (=>) In-Reply-To: <051.11128ae44d764b8f1b3394d8184f1010@haskell.org> References: <051.11128ae44d764b8f1b3394d8184f1010@haskell.org> Message-ID: <066.378e189473ec521965b1d97d11e2f549@haskell.org> #14822: -XQuantifiedConstraints: Turn term-level entailments (:-) into constraints (=>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kcsongor): What would the conditions of generating such an implication constraint be? To me it seems like this would make use of the fact that the kind `Bool` is closed, and in theory, a constraint `forall (b :: Bool). C b` could be discharged by having an instance for `C 'True` and `C 'False`. Or in terms of implication constraints, that `forall (b :: Bool). C b => D b` could be built from the individual constituents. If my understanding is correct as written above, then I don't think it would make sense. When I see a quantified implication constraint, like `forall a. C a => D a`, I expect it to be parametric in `a`, which means that the solution of that constraint should be a function that uses the dictionary for `C a` to build the dictionary for `D a`, regardless of what `a` is instantiated to. (This expectation is grounded in the open world assumption.) For what it's worth, I think the question can be reformulated as whether the constraint `(forall a b. Funny a b)` should be solved based on your provided instances (to which I would answer no). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 12:15:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 12:15:56 -0000 Subject: [GHC] #14823: Test profiling/should_run/scc001 fails on Circle CI Message-ID: <045.0b0f4063ccfb05bae50903cdc06ece01@haskell.org> #14823: Test profiling/should_run/scc001 fails on Circle CI -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The test profiling/should_run/scc001 fails on CI: {{{#!hs module Main (main) where main :: IO () main = do print $ f True print $ g 3 print $ h 'a' f :: a -> a f x = x g :: Int -> Int g x = x h :: Char -> Char Just h = Just id }}} And it outputs: {{{ True 3 ghc-stage2: ghc-iserv terminated (-11) }}} instead of {{{ True 3 'a' }}} I guess I'll mark it as an expected failure for now in my PR. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 12:17:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 12:17:55 -0000 Subject: [GHC] #14819: GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling In-Reply-To: <046.3cff902adb709d7e7df64a2fe7e8f873@haskell.org> References: <046.3cff902adb709d7e7df64a2fe7e8f873@haskell.org> Message-ID: <061.7a21c46c08f0431488972abfefd8fc2b@haskell.org> #14819: GHC 8.2 does not accept British {-# LANGUAGE GeneralisedNewtypeDeriving #-} spelling -------------------------------------+------------------------------------- Reporter: clinton | Owner: (none) Type: bug | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4422 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D4372 => Phab:D4422 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 13:37:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 13:37:06 -0000 Subject: [GHC] #14820: MultiFunctionalDependencies In-Reply-To: <044.0fcd53c17d342a3cdec4f68c004621d2@haskell.org> References: <044.0fcd53c17d342a3cdec4f68c004621d2@haskell.org> Message-ID: <059.c6a9540350aa8eb3643ebe5567e42dc6@haskell.org> #14820: MultiFunctionalDependencies -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by zaoqi): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 13:39:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 13:39:34 -0000 Subject: [GHC] #14824: automatically select instance Message-ID: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There is {{{#!hs class C a b where m :: [a] -> b instance C x0 x0 instance C x1 x2 instance C x0 x3 }}} x0 x1 x2 x3 is Types. FunctionalDependencies can't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 13:39:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 13:39:57 -0000 Subject: [GHC] #14824: automatically select instance In-Reply-To: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> References: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> Message-ID: <059.7569953d992712ff787ff6c57f884f36@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by zaoqi: Old description: > There is > {{{#!hs > class C a b where m :: [a] -> b > instance C x0 x0 > instance C x1 x2 > instance C x0 x3 > }}} > x0 x1 x2 x3 is Types. > FunctionalDependencies can't work. New description: There is {{{#!hs class C a b where m :: [a] -> b instance C x0 x0 instance C x1 x2 instance C x0 x3 }}} x0 x1 x2 x3 are Types. FunctionalDependencies can't work. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 13:47:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 13:47:09 -0000 Subject: [GHC] #14823: Test profiling/should_run/scc001 fails on Circle CI In-Reply-To: <045.0b0f4063ccfb05bae50903cdc06ece01@haskell.org> References: <045.0b0f4063ccfb05bae50903cdc06ece01@haskell.org> Message-ID: <060.39ce9971ddc237a2d53d704efe80b75b@haskell.org> #14823: Test profiling/should_run/scc001 fails on Circle CI -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14705 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #14705 Comment: Duplicate of #14705. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 13:48:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 13:48:10 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.8d2196efa7c2130586dccfc01b8c6589@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): Yes, IMO there is enough motivation to have evidence as `Natural`. We are talking about type level Nats, not Ints. The fact that term value `Natural`s are second-grade citizens in GHC atm is unfortunate. If we are able to constant fold other numeric types, we should be able to do that for `Natural` too. See https://phabricator.haskell.org/D3024 discussion. I'm in great favour of adding `Natural` literal into core. It was untrivial and I didn't pursue that back then, but again IMO it's the right thing to do. Pushing even further, I'd propose to introduce `{-# LANGUAGE NaturalLiterals #-}`, so `2` is desugared to `2 :: FromNatural a => a` where `class fromNatural :: FromNatural a where Natural -> a` (use `Num` or better `FromInteger` if `NegativeLiterals` is enabled and literal is in fact negative). Putting that behind the language extension doesn't break old code (which needs `Num a => a`). Side-question: how constant folding works when cross-compiling, when `Int` is of different bit-widths on host and target? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 15:58:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 15:58:07 -0000 Subject: [GHC] #14825: Access violation on Windows is not propagated to the OS Message-ID: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> #14825: Access violation on Windows is not propagated to the OS -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.2.2 System | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We're using Haskell in production environment. Some times we get exceptions, like this: "Access violation in generated code when reading 0000000000000000" and nothing more. This is extremely hard and time consuming to debug where this exception came from. There is no information about at which address was the exception thrown. The correct way on Windows is such exceptions to be propagated to the operating system. This way we will attach a debugger to the process and it'll get and visualize where the exception happened. Currently GHC runtime is catching the exception, skip its source information and present that uninformative message to the user. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 16:03:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 16:03:15 -0000 Subject: [GHC] #14825: Access violation on Windows is not propagated to the OS In-Reply-To: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> References: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> Message-ID: <060.33e8fa7ce53d9d322d7d4b20a02182e0@haskell.org> #14825: Access violation on Windows is not propagated to the OS -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: Phyx- (added) Comment: I believe Phyx- was working on having proper Windows stack traces whenever access violations are reported. Is this correct, Phyx-? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 16:39:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 16:39:34 -0000 Subject: [GHC] #12397: Support for PDB debug information generation In-Reply-To: <045.7bf08882b414350a48568f9ca1e85e23@haskell.org> References: <045.7bf08882b414350a48568f9ca1e85e23@haskell.org> Message-ID: <060.a118473166d1c35ad77acf00fffef92b@haskell.org> #12397: Support for PDB debug information generation -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Debugging) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): As a temporary workaround I found a tool for convertion of DWARF to PDB which seems to work good: https://github.com/rainers/cv2pdb -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 16:50:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 16:50:09 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.51229f23a0d4277f0db3d8eb3c5569d7@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): phab:D4423 #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * differential: => phab:D4423 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 19:39:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 19:39:49 -0000 Subject: [GHC] #14826: Flatten data types extending other data types in STG Message-ID: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> #14826: Flatten data types extending other data types in STG -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.5 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 idea was triggered by https://mail.haskell.org/pipermail/haskell- cafe/2018-February/128570.html although it does not solve that particular case. Hence I don’t know if there is any practical use for it, but I wanted to jot it down. Consider a data type {{{ data Result = Ok !Foo | NotOK Error }}} where `Foo` is a concrete algebraic data type with $n$ constructors. Then the following transformation should be safe: * Do not generate an info table for `Ok` * Give the `NotOK` the constructor number $n+1$. * Replace calls to `Ok` with `id` * Replace {{{ case r as b of Of f -> E[b,f] | NotOk e -> E[b,e] }}} with {{{ case r as b of DEFAULT -> E[b,b] | NotOk e -> E[b,e] }}} This effectively makes every constructor or `Foo` a constructor of `Ok`, and eliminates the pointer indirection introduced by `Foo`. Checking if a `Result` is `Ok` is now a simple check of the pointer tag (if `Foo` and `Result` do not have too many constructors). Note that `Result` could have additional constructors, but only one can be eliminated. This one constructor needs to * have one argument * be strict in that argument * that argument must be an algebraic data type (even after this flattening) does not have `NotOk` as a constructor. We currently cannot do this in `Core`, but we could if our safe coercions were directed. Do you think you have a case where this could give a performance boost? Maybe some parser library? You can try this now using pattern synonyms and `unsafeCoerce`. If you think there is something to be gained here, then we can consider implementing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 19:47:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 19:47:40 -0000 Subject: [GHC] #14826: Flatten data types extending other data types in STG In-Reply-To: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> References: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> Message-ID: <061.f401996459e407e1733a18c26cdb3e6b@haskell.org> #14826: Flatten data types extending other data types in STG -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: 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): This might be useful to be able to do {{{ data IntSet = NonEmpty !NonEmptyIntSet | Tip data NonEmptyIntSet = Bin … | Leaf … }}} and get more expressive types than the current {{{ data IntSet = Bin … | Leaf … | Tip }}} without having to pay a performance penalty for it. Or even {{{ data [a] = Nil | NonEmpty !(NEList a) data (NEList a) = Cons a [a] }}} (no, I am not proposing to change the `Prelude` :-)) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 19:54:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 19:54:40 -0000 Subject: [GHC] #14826: Flatten data types extending other data types in STG In-Reply-To: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> References: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> Message-ID: <061.bcee7e688305f7a28c216fde603d77f6@haskell.org> #14826: Flatten data types extending other data types in STG -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): As I understand your proposal, this will re-use info pointers. Is that right? If so, is that a requirement? I imagine we could encode something more general by lifting any data constructor consisting purely of an unboxed sum of arity n to n distinct constructor tags. That way, we can drop the 'only once' requirement. Well, I guess this still involves non-`id` coercions... Still, we could encode the 'only once' thing, where we re-use constructor tags, as a special case to get erasable coercions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 20:10:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 20:10:14 -0000 Subject: [GHC] #5889: -fno-prof-count-entries leads to linking errors In-Reply-To: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> References: <043.c51b50cea9fd3755f487a8490fe8400e@haskell.org> Message-ID: <058.a6fa1086dce0afd7d990a4a5a1249245@haskell.org> #5889: -fno-prof-count-entries leads to linking errors -------------------------------------+------------------------------------- Reporter: akio | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | profiling/should_compile/T5889 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4325 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 583e392a83c17e8baf45bc6ee5b998afae190a44. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 20:10:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 20:10:44 -0000 Subject: [GHC] #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? In-Reply-To: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> References: <050.b01b3d3c472df373e991905eeea1c1f9@haskell.org> Message-ID: <065.755c88c75d7edf424fd256697ab7d577@haskell.org> #14728: Is (GeneralizedNewtypeDeriving + associated type classes) completely bogus? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: deriving, Resolution: fixed | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4402 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 0f78f18129d24f17154ae7dca84937fddd1f8b0c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 20:16:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 20:16:07 -0000 Subject: [GHC] #14826: Flatten data types extending other data types in STG In-Reply-To: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> References: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> Message-ID: <061.d6f3a311c7cd09d695fb979384cdccc6@haskell.org> #14826: Flatten data types extending other data types in STG -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: 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): One might be able to state this in terms of unboxed sums, yes. > That way, we can drop the 'only once' requirement. Well, I guess this still involves non-id coercions... You mean the requirement that only one `Foo` can be flattened into a `Result`? Yes, if you do this with multiple ones you either get non-id coercions (which party defeat the purpose). Or, of all types are defined in the same module, you can maybe to a smart constructor tag allocation scheme where `Foo` gets tags 1…3, `Bar` gets tags 4…6, and `data FooBar = Foo !Foo | Bar !Bar` can now be flattened simply to a pointer to a `Foo` or a `Bar` value. But let’s focus on the simple case first that does not require a global constructor pointer allocation pass :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 20:36:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 20:36:54 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.e363a2cb8208145db2f5a834e472c850@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4419 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D4419 * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 20:49:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 20:49:01 -0000 Subject: [GHC] #14812: Dot-Notation for Flipped Function Application In-Reply-To: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> References: <044.eb0821c9b28a12fc8a1c34a93b71d5bb@haskell.org> Message-ID: <059.6845a1f77c97171db6f91baca38e1c2b@haskell.org> #14812: Dot-Notation for Flipped Function Application -------------------------------------+------------------------------------- Reporter: tepan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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): There's plenty of historical discussion about this; wiki link in comment:11 is a good starting point. Personally, I think that something like this would be very attractive for writing pipelines of computation. One particularly attractive possibility is using type inference to drive auto-complete and drop-down menus of possibilities. IDEs for OO languages use this to tremendous effect. There's an old paper [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.146.5411 The power is in the dot] which I have not reviewed recently but remember enjoying some years ago. Definitely a GHC-proposal suggestion though. It would surely be controversial. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 20:53:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 20:53:50 -0000 Subject: [GHC] #14170: 8.2.1 regression: GHC fails to simplify `natVal` In-Reply-To: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> References: <048.f68d481a7069080ef2825e023292b3f7@haskell.org> Message-ID: <063.e328f4022f4b2de4e7e821ba81bc77d4@haskell.org> #14170: 8.2.1 regression: GHC fails to simplify `natVal` -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Bodigrim Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'm in great favour of adding Natural literal into core. It was untrivial and I didn't pursue that back then, As comment:2 says, it's not trivial in the sense of "only 3 lines of code", but it is trivial (or at least easy) in the sense of "just follow the pattern of `Integer`". I often find myself liking things that are simple and explicable even if they do a bit more duplication than we'd ideally like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 21:17:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 21:17:34 -0000 Subject: [GHC] #14825: Access violation on Windows is not propagated to the OS In-Reply-To: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> References: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> Message-ID: <060.840df3efb8413f7c7ae38f9c61f4a6c7@haskell.org> #14825: Access violation on Windows is not propagated to the OS -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #13911 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate * related: => #13911 Comment: Hi, I'm closing this as a dupe. Couple of things however: > The correct way on Windows is such exceptions to be propagated to the operating system. No it's not. An application is perfectly fine handling it's own exceptions. That's why the OS makes a distinction between `Unhandled` and `Handled` exceptions. > This way we will attach a debugger to the process and it'll get and visualize where the exception happened. This is also not accurate, first chance exceptions are always handled before all user exception handlers. GHC uses `VEH` handlers up to 8.4 and from then on `VCH`. The documentation clearly states `Vectored handlers are called in the order that they were added, after the debugger gets a first chance notification, but before the system begins unwinding the stack.` (see https://msdn.microsoft.com/en- us/library/windows/desktop/ms681420(v=vs.85).aspx) If a debugger is attached, it will *always* get the first chance to handle exceptions! If it wants to. For instance {{{ module Main where import Foreign main :: IO () main = do x <- peek nullPtr print (x :: Int) }}} compiling and attaching a debugger {{{ Tamar at Rage ~/ghc2> ghc noexception.hs -fforce-recomp [1 of 1] Compiling Main ( noexception.hs, noexception.o ) Linking noexception.exe ... Tamar at Rage ~/ghc2> gdb --ex r --args noexception.exe GNU gdb (GDB) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-msys". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Traceback (most recent call last): File "", line 3, in ImportError: No module named libstdcxx.v6.printers /etc/gdbinit:6: Error in sourced command file: Error while executing Python code. Reading symbols from noexception.exe...done. Starting program: /home/Tamar/ghc2/noexception.exe [New Thread 47004.0x7284] [New Thread 47004.0xb4ac] [New Thread 47004.0x5580] [New Thread 47004.0x9d40] [New Thread 47004.0x1b38] Thread 1 received signal SIGSEGV, Segmentation fault. 0x0000000000402879 in c6BK_info () (gdb) }}} as you can see the debugger clearly breaks. {{{ Tamar at Rage~/ghc2> ./noexception.exe Segmentation fault/access violation in generated code }}} without the debugger the exception handler runs. > Currently GHC runtime is catching the exception, skip its source information and present that uninformative message to the user. The reason the error is uninformative is because the location of your segfault occurred in a location for which there is no source information. The Haskell compiler can only emit DWARF at best so debugging is just more difficult on Windows. When running in ghci GHC 8.4 and newer will attempt to reconstruct a stack. It will also allow you to opt out of exception handling all together. For older (and compatible with newer) GHCs you can reasonably easily opt- out using FFI: {{{ module Main where import Foreign foreign import ccall "__unregister_hs_exception_handler" disableExceptionHandler :: IO () main :: IO () main = do disableExceptionHandler x <- peek nullPtr print (x :: Int) }}} and you clearly get a second chance exception now {{{ Tamar at Rage ~/ghc2> ./noexception.exe fish: “./noexception.exe” terminated by signal SIGSEGV (Address boundary error) }}} This isn't supported, but it's an easy way to disable the handling on older compilers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 22:20:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 22:20:25 -0000 Subject: [GHC] #11791: Remove the `isInlinePragma prag` test In-Reply-To: <046.e1b8da45884d1bb5e6fabdc8ea65e302@haskell.org> References: <046.e1b8da45884d1bb5e6fabdc8ea65e302@haskell.org> Message-ID: <061.f7670eb2c44fe0a094830f4e206c04a4@haskell.org> #11791: Remove the `isInlinePragma prag` test -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11781, #5928 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sjakobi: Old description: > This is a spin off of tickjet:11781#comment:9, where simonpjs writes: > > > What is more mysterious to me is why the unfolding for > `$fApplicativeIO_$c*>` doesn't have `bindIO`, and then `bindIO` inlined > into it, which would allow a cascade of further improvements, which > would, I think, produce essentially the same code as `thenIO`. > > > > The offending corner is this > > {{{ > > active_unfolding_gentle id > > = isInlinePragma prag -- WHY?? > > && isEarlyActive (inlinePragmaActivation prag) > > }}} > > So I tried removing the `isInlinePragma prag` test, and indeed the code > becomes identical. > > > > Conclusion: > > * I'd love to make the above change to `active_unfolding_gentle` and > see if any other performance numbers budge. I doubt that anything will > change a lot -- it really only affects whether optimisation happens > before or after inlining -- but it should improve compiler performance a > bit for that very reason. This could be a separate ticket > > > > Incidentally, see #5928 which is somewhat related. > > This ticket tracks that idea. New description: This is a spin off of ticket:11781#comment:9, where simonpj writes: > What is more mysterious to me is why the unfolding for `$fApplicativeIO_$c*>` doesn't have `bindIO`, and then `bindIO` inlined into it, which would allow a cascade of further improvements, which would, I think, produce essentially the same code as `thenIO`. > > The offending corner is this > {{{ > active_unfolding_gentle id > = isInlinePragma prag -- WHY?? > && isEarlyActive (inlinePragmaActivation prag) > }}} > So I tried removing the `isInlinePragma prag` test, and indeed the code becomes identical. > > Conclusion: > * I'd love to make the above change to `active_unfolding_gentle` and see if any other performance numbers budge. I doubt that anything will change a lot -- it really only affects whether optimisation happens before or after inlining -- but it should improve compiler performance a bit for that very reason. This could be a separate ticket > > Incidentally, see #5928 which is somewhat related. This ticket tracks that idea. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 22:31:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 22:31:51 -0000 Subject: [GHC] #11791: Remove the `isInlinePragma prag` test In-Reply-To: <046.e1b8da45884d1bb5e6fabdc8ea65e302@haskell.org> References: <046.e1b8da45884d1bb5e6fabdc8ea65e302@haskell.org> Message-ID: <061.ee79f5d034f9a76684347862cb139708@haskell.org> #11791: Remove the `isInlinePragma prag` test -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11781, #5928 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * status: new => closed * resolution: => fixed Comment: The offending bit of code was removed in 2effe18ab51d66474724d38b20e49cc1b8738f60. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 22:36:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 22:36:28 -0000 Subject: [GHC] #13362: GHC first generation of GC to be as large as largest cache size by default In-Reply-To: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> References: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> Message-ID: <060.5e2166949aca7689bb95f61a86dc3df8@haskell.org> #13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: numa cache gc | newcomers 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 sjakobi): * cc: sjakobi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 22:40:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 22:40:19 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point Message-ID: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://www.reddit.com/r/haskell/comments/7yh8ar/i_wrote_a_program_that_runs_about_10_times_faster/ This discussion] revolved around a program that runs 10x faster under ghci. One way to solve this is to remove a superfluous inline pragma which allows the following transformation to happen: {{{ letrec { f a = case e of { p1 -> f a'; p2 -> (# l, r #); }} in case f e2 of { (# l, r #) -> e3; } }}} into {{{ joinrec { f a = case e of { p1 -> jump f a'; p2 -> e3; }} in jump f e2 }}} More generally a recursive let binding that is called exactly once from the outside. If all recursive calls are tail calls and the outside one isn't then we could safely replace the call with the binding and end up with join points. In this case it means a 10x speedup so it might be worth doing generally. {{{ letrec { fi = ei; } in ... (fj e) ... => ... (joinrec { fi = ei; } in fj e) ... }}} [https://gist.github.com/AndreasPK/8e6f0cbf253f0930f4cda81e685ac136 Self contained example] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 23:10:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 23:10:47 -0000 Subject: [GHC] #14668: Ordering of declarations can cause typechecking to fail In-Reply-To: <050.d042aa520b7fcde791e49a2b284676e9@haskell.org> References: <050.d042aa520b7fcde791e49a2b284676e9@haskell.org> Message-ID: <065.64b8f75f708faa7a3919ca2547a18381@haskell.org> #14668: Ordering of declarations can cause typechecking to fail -------------------------------------+------------------------------------- Reporter: heptahedron | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > What is even worse, this bug prevents us from refactoring the code to separate module That's odd. The original report is about ordering declarations within a single module. Can you give a repro case for how refactoring your code into separate modules makes things fail? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 23:16:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 23:16:26 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.86e6c04f293ad811abe4c6735c8438cd@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ersetzen: Old description: > [https://www.reddit.com/r/haskell/comments/7yh8ar/i_wrote_a_program_that_runs_about_10_times_faster/ > This discussion] revolved around a program that runs 10x faster under > ghci. > > One way to solve this is to remove a superfluous inline pragma which > allows the following transformation to happen: > > {{{ > letrec { > f a = case e of { > p1 -> f a'; > p2 -> (# l, r #); > }} in case f e2 of { (# l, r #) -> e3; } > }}} > > into > > {{{ > joinrec { > f a = case e of { > p1 -> jump f a'; > p2 -> e3; > }} in jump f e2 > }}} > > More generally a recursive let binding that is called exactly once from > the outside. If all recursive calls are tail calls and the outside one > isn't then we could safely replace the call with the binding and end up > with join points. In this case it means a 10x speedup so it might be > worth doing generally. > > {{{ > letrec { fi = ei; } in ... (fj e) ... => ... (joinrec { fi = ei; } in fj > e) ... > }}} > > [https://gist.github.com/AndreasPK/8e6f0cbf253f0930f4cda81e685ac136 Self > contained example] New description: [https://www.reddit.com/r/haskell/comments/7yh8ar/i_wrote_a_program_that_runs_about_10_times_faster/ This discussion] revolved around a program that runs 10x faster under ghci. One way to solve this is to remove a superfluous inline pragma which allows the following transformation to happen: {{{ letrec { f a = case e of { p1 -> f a'; p2 -> (# l, r #); }} in case f e2 of { (# l, r #) -> e3; } }}} into {{{ joinrec { f a = case e of { p1 -> jump f a'; p2 -> e3; }} in jump f e2 }}} More generally a recursive let binding that is called exactly once from the outside. If all recursive calls are tail calls and the outside one isn't then we could safely replace the call with the binding and end up with join points. In this case it means a 10x speedup so it might be worth doing generally. {{{ letrec { fi = ei; } in ... (fj e) ... => ... (joinrec { fi = ei; } in jump fj e) ... }}} [https://gist.github.com/AndreasPK/8e6f0cbf253f0930f4cda81e685ac136 Self contained example] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 23:41:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 23:41:39 -0000 Subject: [GHC] #602: Warning Suppression In-Reply-To: <047.d851345fc677a304d933040775d25d45@haskell.org> References: <047.d851345fc677a304d933040775d25d45@haskell.org> Message-ID: <062.3483f2ed8a1caf7b919ec97b9bfb3b84@haskell.org> #602: Warning Suppression -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: None Resolution: None | Keywords: warnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | Design/LocalWarningPragmas | -------------------------------------+------------------------------------- Comment (by simonpj): Same request made in #14805. It looks like a very reasonable request to me; but (especially since GHC has to move code around when doing strongly-connected component analysis of type and value bindings) not entirely straightforward to implement. Needs someone to propose a concrete design and implementation path. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 19 23:55:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Feb 2018 23:55:15 -0000 Subject: [GHC] #14788: `error` in GHC internals can disappear by rerunning ghc again In-Reply-To: <042.990361d1cd49e5f7500314a2cb466fff@haskell.org> References: <042.990361d1cd49e5f7500314a2cb466fff@haskell.org> Message-ID: <057.61ba3b906c21c005e799ed0cb404437f@haskell.org> #14788: `error` in GHC internals can disappear by rerunning ghc again -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14533 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I suggest that ghc either deepseq the string to be written to the .o file before calling writeFile or equivalent, That imposes a cost on every compilation. Maybe instead remove any `.o` file if a panic occurs? That would impose costs only on the panic path. This would entail noting what files are "in flight", so that the exception handler can delete them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 00:08:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 00:08:10 -0000 Subject: [GHC] #14420: Data families should not instantiate to non-Type kinds In-Reply-To: <047.a64d114cfae11861b31f70375118e394@haskell.org> References: <047.a64d114cfae11861b31f70375118e394@haskell.org> Message-ID: <062.b6748c4e2fb7d7722d4b4b7c42747f8c@haskell.org> #14420: Data families should not instantiate to non-Type kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): According to Adam, this bug somehow imperils #7259. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 00:08:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 00:08:31 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.202d18169b46979501c7b75c365ebe2a@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > This is currently imperilled by #14420. How, exactly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 00:21:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 00:21:16 -0000 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> Message-ID: <066.7e5bfb6b782b7bcbfca532aec98a9e0b@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not sure which comment you are replying to; and I fear I don't understand what "something like this" is. The big trouble with recursive modules is that: either you need a programmer written signature file (i.e. `.hs-boot`) or you have to compile all the modules in the SCC at once. I don't see any other path. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 00:21:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 00:21:56 -0000 Subject: [GHC] #7259: Eta expansion of products in System FC In-Reply-To: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> References: <046.eb91fb12bdf35396d79679c78f7a6c38@haskell.org> Message-ID: <061.fb0dd8e0bd9c8e0e6d3dca78f73d8b5f@haskell.org> #7259: Eta expansion of products in System FC -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kcsongor): Replying to [comment:24 simonpj]: > > This is currently imperilled by #14420. > > How, exactly? #14420 means that one can define a distinguishable member of any kind, bringing back `Any` {{{ data family Any :: k }}} Isn't this what caused the original soundness issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 00:27:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 00:27:01 -0000 Subject: [GHC] #14544: doCorePass has at least one missing case In-Reply-To: <049.4d90cc3cc6b5380801189db1b57310d5@haskell.org> References: <049.4d90cc3cc6b5380801189db1b57310d5@haskell.org> Message-ID: <064.cbe1fb4330dfee37403bdeefd6903b07@haskell.org> #14544: doCorePass has at least one missing case -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): There are more missing cases: `CoreDesugar`, `CoreDesugarOpt`, `CoreTidy`, `CorePrep`, and – depending on CPP – `CoreDoPluginPass`. Deleting the `CoreOccurAnal` constructor would be easy, but the other ones are actually in use. A first step might be to expand the catch-all to make sure that additional constructors aren't forgotten in the same way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 00:47:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 00:47:39 -0000 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> Message-ID: <066.e6a0b32925c7092404ec1fec75957490@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bfrk): I have gradually changed my opinion on this some over the years. I no longer think that writing explicit interface files is too much of a burden. Indeed it can have great advantages to do so, but I would prefer a proper integration into Haskell the language. The current situation is not ideal: (1) hs-boot is an obscure name for an interface definition (2) it is an implementation defined feature, outside of the language (3) it is unclear to me how it interacts with the use of export lists; ideally I would want to be able to use interface definition files as an alternative to export lists (4) it should not be necessary to repeat in the .hs file anything that is already fully defined in the interface definition file (incomplete definitions are exempted) (5) it should be possible to place the interface definition in a distinguished "header" part of the .hs, so that it need not be in a separate file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 01:05:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 01:05:18 -0000 Subject: [GHC] #11382: Optimize Data.Char In-Reply-To: <046.07b85d059cbd81601867717299b83062@haskell.org> References: <046.07b85d059cbd81601867717299b83062@haskell.org> Message-ID: <061.383ea6a7b47c9e60d8adc5fa27bf4cd5@haskell.org> #11382: Optimize Data.Char -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9638, #1473 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * related: #9638 => #9638, #1473 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 02:07:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 02:07:34 -0000 Subject: [GHC] #14828: panic! when using :print on some functions with class constraints? Message-ID: <042.277052228000c219ea7b7bc26108babf@haskell.org> #14828: panic! when using :print on some functions with class constraints? -------------------------------------+------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These are the problematic ones I've found: {{{ > :t foldl foldl :: Foldable t => (b -> a -> b) -> b -> t a -> b > :print foldl ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1H7[rt] :: TYPE t_a1H6[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t fmap fmap :: Functor f => (a -> b) -> f a -> f b > :print fmap ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1Hu[rt] :: TYPE t_a1Ht[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t return return :: Monad m => a -> m a > :print return ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1Wt[rt] :: TYPE t_a1Ws[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :t pure pure :: Applicative f => a -> f a > :print pure ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1WP[rt] :: TYPE t_a1WO[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} These that don't have constraints are fine: {{{ > :print id id = (_t1::a -> a) > :print map map = (_t2::(a1 -> b) -> [a1] -> [b]) > :print const const = (_t3::a2 -> b1 -> a2) }}} This value and function created in the session are fine: {{{ > let x :: Monad m => m (); x = return () Prelude| > :p x x = (_t5::Monad m1 => m1 ()) > let f :: Monad m => Int -> m Int; f n = return (n + 1) Prelude| > :p f f = (_t6::Monad m2 => Int -> m2 Int) }}} mempty and mappend imported from Data.Monoid are fine: {{{ > :m + Data.Monoid > :p mempty mempty = (_t7::Monoid a4 => a4) > :p mappend mappend = (_t8::Monoid a4 => a4 -> a4 -> a4) }}} foldl' and foldr imported from Data.List are not fine: {{{ > :m + Data.List > :p foldl' ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a6Qy[rt] :: TYPE t_a6Qx[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :p Data.List.foldr ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t2_a6RG[rt] :: TYPE t1_a6RF[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} but `all` and `init` from that same module are fine: {{{ > :p Data.List.all all = (_t13::Foldable t1 => (a22 -> Bool) -> t1 a22 -> Bool) > :p Data.List.init init = (_t14::[a29] -> [a29]) }}} So, in a given module, among functions with class constraints, some have the error and others don't. I haven't found a value that's not a function with the error, and I haven't found a function with no class constraints exhibit the error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 02:40:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 02:40:50 -0000 Subject: [GHC] #11777: RTS source code issues In-Reply-To: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> References: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> Message-ID: <061.2cb79a3ddcb7522f69be0689b1dc32d2@haskell.org> #11777: RTS source code issues -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4426, Wiki Page: | Phab:D4427, Phab:D4428 -------------------------------------+------------------------------------- Changes (by sjakobi): * owner: (none) => sjakobi * differential: => Phab:D4426, Phab:D4427, Phab:D4428 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 02:54:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 02:54:28 -0000 Subject: [GHC] #14069: RTS linker maps code as writable In-Reply-To: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> References: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> Message-ID: <061.3d72856f608aa4481c132304c08dac29@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * cc: sjakobi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 03:32:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 03:32:58 -0000 Subject: [GHC] #14828: panic! when using :print on some functions with class constraints? In-Reply-To: <042.277052228000c219ea7b7bc26108babf@haskell.org> References: <042.277052228000c219ea7b7bc26108babf@haskell.org> Message-ID: <057.00fdbf506c94e7d15227ace8e061d0ed@haskell.org> #14828: panic! when using :print on some functions with class constraints? -------------------------------------+------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => debugger -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 04:02:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 04:02:39 -0000 Subject: [GHC] #14312: Head does not build on Windows with the default make config. In-Reply-To: <047.086b87bb9b3dcf2f7a921149fa31eda2@haskell.org> References: <047.086b87bb9b3dcf2f7a921149fa31eda2@haskell.org> Message-ID: <062.292944490b00be33479e5559214958fa@haskell.org> #14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4080 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"eb2daa2b6a83412382aa0fcda598f8b3d40fde2c/ghc" eb2daa2b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb2daa2b6a83412382aa0fcda598f8b3d40fde2c" Change how includes for input file directory works GHC Used to only allow for one include mode, namely `-I`. The problem with `-I` includes is that it supercedes all other includes, including the system include paths. This is not a problem for paths requested by the user, but it is a problem for the ones we implicitly derive and add. In particular we add the source directory of the input file to the include path. This is problematic because it causes any file with the name of a system include, to inadvertently loop as the wrong file gets included. Since this is an implicitly include, and as far as I can tell, only done so local includes are found (as the sources given to GCC reside in a temp folder) then switch from `-I` to `-iquote`. This requires a submodule update for haddock Test Plan: ./validate Reviewers: austin, bgamari, hvr Reviewed By: bgamari Subscribers: carter, rwbarton, thomie GHC Trac Issues: #14312 Differential Revision: https://phabricator.haskell.org/D4080 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 04:31:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 04:31:00 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.ee46cdfbd4e8e456850dac829b7f83fc@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): This is a duplicate of #14068, isn’t it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 04:34:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 04:34:36 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.1dafdeb9e137158e3c6a634e8d4c63be@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Can you check if my branch at (`wip/14068`) fixes the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 04:41:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 04:41:16 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.22f5c6daa513dda7d34597fa43a3d904@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): nomeata, I finally came up with a standalone test case that exhibits the same (apparent) peculiarity. I don't really understand what you're asking, so I'm hoping this will help. {{{#!hs {-# language UnboxedTuples #-} module Fish where import Data.Array.ST import Control.Monad.ST.Strict import Control.Monad blink :: (a -> b) -> a -> (# b #) blink g a = (# g a #) test :: Int -> a -> (a -> a -> a) -> STArray s Int a -> ST s (STArray s Int a) test k a f m = insertModifyingArr k (blink (f a)) m {-# NOINLINE test #-} insertModifyingArr :: Int -> (a -> (# a #)) -> STArray s Int a -> ST s (STArray s Int a) insertModifyingArr i0 f arr0 = do rng <- range <$> getBounds arr0 go i0 rng arr0 where go i [] arr = pure arr go i (k : ks) arr | i == k = do old <- readArray arr i case f old of (# new #) -> writeArray arr i new return arr | otherwise = go i ks arr }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 04:47:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 04:47:05 -0000 Subject: [GHC] #14312: Head does not build on Windows with the default make config. In-Reply-To: <047.086b87bb9b3dcf2f7a921149fa31eda2@haskell.org> References: <047.086b87bb9b3dcf2f7a921149fa31eda2@haskell.org> Message-ID: <062.5afe7a0c97e9ad1ea006fc3010099fd8@haskell.org> #14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Build System | Version: 8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4080 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Thanks Tamar! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 04:52:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 04:52:40 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.8e6b79e4f842de09808a74bc9e64bff5@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4419 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"fe98cd7538ce18dec260b50ca756d06929ae0b3b/ghc" fe98cd75/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fe98cd7538ce18dec260b50ca756d06929ae0b3b" Combine the CoreAlts with the most common RHS Unless there already is a DEFAULT alternative, look for the most common RHS and create a new DEFAULT alt. Previously, only the very first RHS was considered. Test Plan: make test TEST="T7360 T14684" Reviewers: bgamari Subscribers: AndreasK, mpickering, rwbarton, thomie, carter GHC Trac Issues: #14684 Differential Revision: https://phabricator.haskell.org/D4419 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 04:52:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 04:52:40 -0000 Subject: [GHC] #14282: tagToEnum# . dataToTag# not optimized away In-Reply-To: <045.5438ce0b3dc299cc3f08e924d6abe37c@haskell.org> References: <045.5438ce0b3dc299cc3f08e924d6abe37c@haskell.org> Message-ID: <060.39eb2ed7a51f957fc6a0e7a4a3d6cc2d@haskell.org> #14282: tagToEnum# . dataToTag# not optimized away -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4375 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1d90f66095de9844c925211e5fb52b5c4d3f0674/ghc" 1d90f66/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1d90f66095de9844c925211e5fb52b5c4d3f0674" Document missing dataToTag# . tagToEnum# rule Explain why we don't have a rule to optimize `dataToTag# (tagToEnum# x)` to `x`. [skip ci] Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14282 Differential Revision: https://phabricator.haskell.org/D4375 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 04:53:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 04:53:29 -0000 Subject: [GHC] #14282: tagToEnum# . dataToTag# not optimized away In-Reply-To: <045.5438ce0b3dc299cc3f08e924d6abe37c@haskell.org> References: <045.5438ce0b3dc299cc3f08e924d6abe37c@haskell.org> Message-ID: <060.fe59f3af2ea76869f00fd67d061fe548@haskell.org> #14282: tagToEnum# . dataToTag# not optimized away -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: datacon-tags Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4375 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"517c194095064c123b18b779c96c0866e0b3a6d9/ghc" 517c1940/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="517c194095064c123b18b779c96c0866e0b3a6d9" Document missing dataToTag# . tagToEnum# rule Explain why we don't have a rule to optimize `dataToTag# (tagToEnum# x)` to `x`. [skip ci] Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14282 Differential Revision: https://phabricator.haskell.org/D4375 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 04:57:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 04:57:46 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.198f8ff0eeea85c0af51db66c884e39d@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): It works if you don't export `insertModifyingArr`. Then it gets inlined into `test`, and CallArity, when looking at the binding of `g_s9E` in your original snippet, sees all the uses, sees that they are called at most once, and is happy to eta-expand it! But without inlining `insertModifyingArr`, this is beyond the reach of Call Arity, because it is not a higher-order analysis. Now, why does the demand analyser (which is higher-order, i.e. knows how functions call their arguments) not fix this? Because the demand analyser does not see that `insertModifyingArr` calls its argument only once, because the call is in a recursive loop. Sebastian Graf (@sgraf812) has thoughts on combining the analyses to give us the best of both worlds, maybe he can comment. For now, does {{{ import GHC.Magic blink :: (a -> b) -> a -> (# b #) blink g = oneShot $ \a -> (# g a #) }}} do what you want? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 05:13:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 05:13:46 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.fa91d1022111c90599976f6347ec4697@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Your workaround does work. Inlining `insertModifying` (in the real-life case) is probably a bad idea. Your workaround does work. An alternative workaround does too: {{{#!hs test k a f m = insertModifyingArr k (oneShot $ blink (f a)) m }}} I'm glad to hear someone's been thinking about this issue; I'm much less glad that I've spent so much time coming up with a test case for something that's already known! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 05:16:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 05:16:18 -0000 Subject: [GHC] #14823: Test profiling/should_run/scc001 fails on Circle CI In-Reply-To: <045.0b0f4063ccfb05bae50903cdc06ece01@haskell.org> References: <045.0b0f4063ccfb05bae50903cdc06ece01@haskell.org> Message-ID: <060.a2f697d968873b53db2107af281c54da@haskell.org> #14823: Test profiling/should_run/scc001 fails on Circle CI -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14705 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 05:27:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 05:27:31 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.421626828bad67a3631014e615c366c7@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.6.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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"81a5e05d376c075a38e55bc124ea6226c1f3bef7/ghc" 81a5e05/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="81a5e05d376c075a38e55bc124ea6226c1f3bef7" circleci: Skip performance tests Once we finally get the automation for #12758 we can re-enable these. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 05:31:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 05:31:20 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.5e4c508e33904c0a590f332b19749ec9@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > I'm much less glad that I've spent so much time coming up with a test case for something that's already known! Sorry about that – at least we have a good test case now for when someone pick this up again! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 08:48:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 08:48:21 -0000 Subject: [GHC] #13422: INLINE CONLIKE sometimes fails to inline In-Reply-To: <045.24512f73acb84c676c1a559d500d9bab@haskell.org> References: <045.24512f73acb84c676c1a559d500d9bab@haskell.org> Message-ID: <060.a001e0ecc2dabf0b2a4e24ec49ef4502@haskell.org> #13422: INLINE CONLIKE sometimes fails to inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I think this ticket can be closed. This ticket was about an improvement to the idea described in #7206, and comment:4 fixes this. I've rebased the cheap-build branch (not pushed to GHC's git repo as force pushes are not allowed, see it here: https://github.com/osa1/ghc/tree/cheap-build), applied idea in comment:4, and verified that it works on `Int`, `Word` and `Char` enumerations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 09:02:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 09:02:18 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.cf5f88106d03186e848ef7ed9bb9055a@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763, #13422 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I rebased the `cheap-build` branch, applied the idea in #13422 to `Word` and `Char` enumerations (`Int` was already implemented), verified that it works as expected, and run nofib again. The result is the same; only allocation difference is in `cacheprof`. Runtimes differ, but when I compared STG outputs I see that they're identical even though runtime differs a few percent. So they're really just noise. I suspect runtime results in comment:13 are also of this nature. I was thinking that this optimization can be done with little user intervention by adding an `INLINE` pragma, but surprisingly it doesn't work. In the example from #13422: {{{ foo :: Int -> Int foo n = s + p where nums = [1..n] s = sum nums p = product nums }}} adding `INLINE` to nums (in original GHC, without `cheap-build` patch) does not make it fuse. However if I manually inline it (substitute `[1..n]` for `nums`) it fuses as expected. Not sure if this is a bug or not, but it's certainly surprising to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 09:41:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 09:41:44 -0000 Subject: [GHC] #14784: RTS header files can't be used with a C++ compiler In-Reply-To: <046.915be18a946df960093f8bf95e37faf5@haskell.org> References: <046.915be18a946df960093f8bf95e37faf5@haskell.org> Message-ID: <061.6f83b9c3c98831097b8e8a5f37c2492d@haskell.org> #14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: (none) => hvr * priority: normal => highest * milestone: => 8.4.1 Comment: This is a regression and will break some existing uses of the RTS, so we should get it fixed before the release. Assigning to @hvr as the author of Phab:D2045 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 10:00:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 10:00:22 -0000 Subject: [GHC] #13809: TH-reified type family and data family instances have a paucity of kinds (was: TH-reified type familly and data family instances have a paucity of kinds) In-Reply-To: <050.0c3063c06a387a87a3b53a78ba487043@haskell.org> References: <050.0c3063c06a387a87a3b53a78ba487043@haskell.org> Message-ID: <065.dab72005cef60ae5a7a90fe81965a9ce@haskell.org> #13809: TH-reified type family and data family instances have a paucity of kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8953, #14268 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 10:09:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 10:09:38 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.f7830fc1395ccf721dd3e6a9a25f20af@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Hey, it seems I'm lucky I subscribed to ghc-ticket just yesterday :) I investigated a little. So, it turns out that Demand Analysis doesn't recognize `insertModifyingArr`s argument `f` to be called once (has usage `C(U(U)`). That's really weird, actually the analysis should be able to figure that out. The fact that `-ddump-stranal` doesn't mention `f` in the demand type as a free variable to `go` makes me feel like there is some conservative approximation at play here. And in fact, I believe that's how fix-pointing works for functions in DmdAnal: Completely forget about free variables and assume the most pessimistic result. You can circumvent that if you make `f` an argument to `go` (reverse static arg transform, essentially): {{{ insertModifyingArr :: Int -> (a -> (# a #)) -> STArray s Int a -> ST s (STArray s Int a) insertModifyingArr i0 f arr0 = do rng <- range <$> getBounds arr0 go f i0 rng arr0 where go f i [] arr = pure arr go f i (k : ks) arr | i == k = do old <- readArray arr i case f old of (# new #) -> writeArray arr i new return arr | otherwise = go f i ks arr }}} This makes DmdAnal propagate the usage information to the top-level: The demand signature for `inserModifyingArr` mentions `f` with usage `1*C1(U(U))`, which in theory should be enough information for the simplifier to eta-expand the `blink` expression. And sure enough, it does (somewhere inside `test`: {{{ Fish.insertModifyingArr_$spoly_go @ a_a3IX @ s_a3IY w_s4pP ww6_s4s2 ww8_s4s5 ww3_s4q2 ww4_s4q3 (GHC.Enum.eftInt ww6_s4s2 ww8_s4s5) k_a15T (\ (a2_a15S [OS=OneShot] :: a_a3IX) -> (# f_a15V a1_a15U a2_a15S #)) }}} The interactions between free vars and static args are a little counter- intuitive, I suppose... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 10:30:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 10:30:38 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.273febe2ff2e08b043539cb9dd742ccf@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Seeing the problem so clearly spelled out, I'm pretty sure this can be solved by loopification. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 10:37:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 10:37:52 -0000 Subject: [GHC] #14784: RTS header files can't be used with a C++ compiler In-Reply-To: <046.915be18a946df960093f8bf95e37faf5@haskell.org> References: <046.915be18a946df960093f8bf95e37faf5@haskell.org> Message-ID: <061.6903cebc657cca0821b54f38e206bce9@haskell.org> #14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Ok, so, the check at that place is to fail early, in case C compiler is thrown at the RTS header files while *not* being in C99 mode (due to misconfiguration or whatever), rather than run into less obvious compile errors lateron. If we can establish the minimum version of ISO C++ which supports all C99 features we rely on, we can tweak the CPP check to something like e.g. {{{#!c #if !((__cplusplus >= 201103L) || (__STDC_VERSION__ >= 199901L)) # error __STDC_VERSION__ does not advertise C99 or later, nor C++11 or later #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 11:05:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 11:05:14 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.1ebcf9901ec4d1bbb701cf40b4a48da9@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): phab:D4423 #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm afraid I'm still not happy. The offending case is this. Before, we have: {{{ T14779.conMkFixed = src T14779.mkConstr (src T14779.tyFixed) (src GHC.CString.unpackCString# "MkFixed"#) ((src GHC.Types.[]) @ GHC.Base.String) (src T14779.Prefix) }}} The simplifier inlines `mkConstr`, let-binding its arguments like this {{{ conMkFixed = let str_s2UM :: Addr# str_s2UM = src "MkFixed"# str_a2jk :: String str_a2jk = src unpackCString# str_s2UM in ...str_a2jk... }}} and then the simplifier floats those two bindings outward. Ben/Bartosz's patch messes with `prepareRhs` in a slightly delicate way, to remove the tick on the string, but I think the bug is earlier. '''I believe we should never have a tick wrapped around a literal string'''. That's certainly what Phab:D3925 seems to say. If that is true (is it?) then that invariant is already broken in the above intermediate form. We should instead have {{{ conMkFixed = let str_s2UM :: Addr# str_s2UM = "MkFixed"# str_a2jk :: String str_a2jk = src unpackCString# str_s2UM in ...str_a2jk... }}} Let's first establish whether we ever want a tick wrapped around a literal string. If we don't, let's adopt Phab:D3925, and make the smart constructor `mkTick` guarantee it. (Unfortunately `CoreUtils.mkTick` is a jolly complicated function and I don't understand it.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 11:21:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 11:21:32 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.53d159f269dc41e7416da7609630e7fa@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): phab:D4423 #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): > I believe we should never have a tick wrapped around a literal string. I think it's fine for these src ticks to appear anywhere - they're supposed to have no impact on simplifier behaviour, they only result in some annotations being added to the generated code in the backend. So the simplifier should look through src ticks. In fact it's probably useful to have src ticks wrapped around these literal strings, because then we can tell where the string came from in gdb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 11:30:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 11:30:57 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.80427d5240b1e9ca9b30442d69e5e85f@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great example. Can someone explain to me why GHCi is faster? And what it has to do with INLINE pragmas? Looking only at the Description, yes loopification should do a good job here. We'd get this {{{ letrec f a = case e of p1 -> f a' p2 -> (# l, r #) in case f e2 of (# l, r #) -> e3 ==> (loopify) let f a = joinrec jf a = case e of p1 -> jump jf a' p2 -> (# l, r #) in jump jf a in case f e2 of (# l, r #) -> e3 ==> (inline `f`) case (let a = e2 in joinrec jf a = case e of p1 -> jump jf a' p2 -> (# l, r #) in jump jf a) of (# l, r #) -> e3 ==> (move the outer case inwards, into the RHS of the joinrec) let a = e2 in joinrec jf a = case e of p1 -> jump jf a' p2 -> case (# l, r #) of (# l, r #) -> e3 in jump jf a ==> (case of known constructor; and inline e2) joinrec jf a = case e of p1 -> jump jf a' p2 -> e3 in jump jf e2 }}} as desired. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 11:31:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 11:31:31 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.414d62e023701f2c1ef52917611e3a8a@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * related: #13966 #14067 => #13966 #14067 #14827 Comment: See also #14827. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 11:39:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 11:39:22 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.2b13f316af9504d98dede798689f41ed@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4419 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's invisible in the message above, but I think this commit is only on branch `wip/T14684`. Is that what you intended? Or did you mean to commit to HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 13:03:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 13:03:46 -0000 Subject: [GHC] #14825: Access violation on Windows is not propagated to the OS In-Reply-To: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> References: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> Message-ID: <060.e466ee462e7b170bd88b55963f0d94de@haskell.org> #14825: Access violation on Windows is not propagated to the OS -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #13911 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Thank you first for the thorough answer! > The reason the error is uninformative is because the location of your segfault occurred in a location for which there is no source information. Is it possible to give some stack trace in such situation instead just "Segmentation fault/access violation in generated code"? I mean even if exact throwing place is not known, but only partial stack trace information. Or you mean that in GHC 8.4 partial stack information will be possible? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 13:28:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 13:28:57 -0000 Subject: [GHC] #14825: Access violation on Windows is not propagated to the OS In-Reply-To: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> References: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> Message-ID: <060.b35cf2d4b25bac5d767f7a0c1ed8ffae@haskell.org> #14825: Access violation on Windows is not propagated to the OS -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #13911 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Replying to [comment:3 varosi]: > > Is it possible to give some stack trace in such situation instead just "Segmentation fault/access violation in generated code"? I mean even if exact throwing place is not known, but only partial stack trace information. Or you mean that in GHC 8.4 partial stack information will be possible? yup, GHC 8.4 will give an attempt, see https://phabricator.haskell.org/D3913 If you're running the code in GHCi I have information from the runtime's symbol table to help out, but when running compiled I don't have this. Eventually (when I get some time) I want to add the ability to use STABS information if available. That should help a bit. Also the stack tracer in GHC 8.4 cannot unwind between Haskell and C stacks. Since I don't know where I am when the segfault occurs I don't know which way to unwind (should be possible though). So for now I assume it's C code. GHC 8.4 also supports creating crash dumps https://phabricator.haskell.org/D3912 So you can just attach a debugger later and inspect the dump manually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 13:46:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 13:46:41 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.b8c5dd403ea757ec838aecca23c944e2@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763, #13422 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > The result is the same; only allocation difference is in `cacheprof` Ignore `cacheprof` until https://ghc.haskell.org/trac/ghc/ticket/8611 is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 13:49:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 13:49:22 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.734e2381bce5252cdb0ab67094153866@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > You can circumvent that if you make f an argument to go (reverse static arg transform, essentially): That’s smart! By making it an argument, you essentially tell GHC to apply inductive reasoning, and then the Demand Analyzer finds out that `f` is used at most once! Cool. And I presume if the recursion were non-linear, it would also do the right thing… So – can we just include the free variables in the strictness signature during fixpointing and get that optimization without the code transformation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 14:09:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 14:09:29 -0000 Subject: [GHC] #11427: superclasses aren't considered because context is no smaller than the instance head In-Reply-To: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> References: <045.5bbd322743d829f91b935ee5364b27b3@haskell.org> Message-ID: <060.b97546980715b760e67fdda13fa06754@haskell.org> #11427: superclasses aren't considered because context is no smaller than the instance head -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 14:17:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 14:17:01 -0000 Subject: [GHC] #14829: Linking error with ANN pragma Message-ID: <049.b341381f87ebab5864bf2afae206c047@haskell.org> #14829: Linking error with ANN pragma -------------------------------------+------------------------------------- Reporter: ehubinette | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There seems to be an issue with the ANN pragma, with fatal compilation errors. To reproduce, setup two modules as such: {{{#!hs module Test where import Weights (Weight(..)) {-# ANN mainTest (Weight 2) #-} mainTest :: IO () mainTest = return () }}} {{{#!hs {-# LANGUAGE DeriveDataTypeable #-} module Weights (Weight(..)) where import Data.Data (Data(..)) newtype Weight = Weight Integer deriving Data }}} Compiling with GHC version `8.2.2` yields: {{{ λ ghc Test.hs [2 of 2] Compiling Test ( Test.hs, Test.o ) Test.hs:5:1: fatal: cannot find object file ‘./Weights.dyn_o’ while linking an interpreted expression }}} The issue persists with `-dynamic-too`: {{{ λ ghc -dynamic-too Test.hs [2 of 2] Compiling Test ( Test.hs, Test.o ) Test.hs:5:1: fatal: cannot find object file ‘./Weights.dyn_o’ while linking an interpreted expression }}} ...but disappears with `-dynamic`: {{{ λ ghc -dynamic Test.hs [1 of 2] Compiling Weights ( Weights.hs, Weights.o ) [2 of 2] Compiling Test ( Test.hs, Test.o ) }}} Sidenote: with GHC version `8.5.20180219`, the issue disappears with `-dynamic-too` ''or'' `-dynamic`: {{{ λ ../../ghc/inplace/bin/ghc-stage2 -dynamic-too Test.hs [1 of 2] Compiling Weights ( Weights.hs, Weights.o ) [2 of 2] Compiling Test ( Test.hs, Test.o ) }}} Remove the ANN pragma, and the compiler behaves just fine with both GHC versions. Please tell me if I can provide more information. Cheers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 14:38:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 14:38:06 -0000 Subject: [GHC] #14829: Linking error with ANN pragma In-Reply-To: <049.b341381f87ebab5864bf2afae206c047@haskell.org> References: <049.b341381f87ebab5864bf2afae206c047@haskell.org> Message-ID: <064.06b4eda291209a83973965036663423b@haskell.org> #14829: Linking error with ANN pragma -------------------------------------+------------------------------------- Reporter: ehubinette | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ehubinette: Old description: > There seems to be an issue with the ANN pragma, with fatal compilation > errors. > > To reproduce, setup two modules as such: > > {{{#!hs > module Test where > > import Weights (Weight(..)) > > {-# ANN mainTest (Weight 2) #-} > mainTest :: IO () > mainTest = return () > }}} > > {{{#!hs > {-# LANGUAGE DeriveDataTypeable #-} > module Weights (Weight(..)) where > > import Data.Data (Data(..)) > > newtype Weight = Weight Integer deriving Data > }}} > > > Compiling with GHC version `8.2.2` yields: > > {{{ > λ ghc Test.hs > [2 of 2] Compiling Test ( Test.hs, Test.o ) > Test.hs:5:1: fatal: > cannot find object file ‘./Weights.dyn_o’ > while linking an interpreted expression > }}} > > The issue persists with `-dynamic-too`: > > {{{ > λ ghc -dynamic-too Test.hs > [2 of 2] Compiling Test ( Test.hs, Test.o ) > Test.hs:5:1: fatal: > cannot find object file ‘./Weights.dyn_o’ > while linking an interpreted expression > }}} > > ...but disappears with `-dynamic`: > > {{{ > λ ghc -dynamic Test.hs > [1 of 2] Compiling Weights ( Weights.hs, Weights.o ) > [2 of 2] Compiling Test ( Test.hs, Test.o ) > }}} > > Sidenote: with GHC version `8.5.20180219`, the issue disappears with > `-dynamic-too` ''or'' `-dynamic`: > > {{{ > λ ../../ghc/inplace/bin/ghc-stage2 -dynamic-too Test.hs > [1 of 2] Compiling Weights ( Weights.hs, Weights.o ) > [2 of 2] Compiling Test ( Test.hs, Test.o ) > }}} > > Remove the ANN pragma, and the compiler behaves just fine with both GHC > versions. Please tell me if I can provide more information. Cheers. New description: There seems to be an issue with the ANN pragma, with fatal compilation errors. To reproduce, setup two modules as such: {{{#!hs module Test where import Weights (Weight(..)) {-# ANN mainTest (Weight 2) #-} mainTest :: IO () mainTest = return () }}} {{{#!hs {-# LANGUAGE DeriveDataTypeable #-} module Weights (Weight(..)) where import Data.Data (Data(..)) newtype Weight = Weight Integer deriving Data }}} Compiling with GHC version `8.2.2` yields: {{{ λ ghc Test.hs [1 of 2] Compiling Weights ( Weights.hs, Weights.o ) [2 of 2] Compiling Test ( Test.hs, Test.o ) Test.hs:5:1: fatal: cannot find object file ‘./Weights.dyn_o’ while linking an interpreted expression }}} The issue disappears with `-dynamic` or `-dynamic-too`: {{{ λ ghc -dynamic Test.hs [1 of 2] Compiling Weights ( Weights.hs, Weights.o ) [2 of 2] Compiling Test ( Test.hs, Test.o ) }}} Issue persist in HEAD, GHC version `8.5.20180219`, but again disappears with `-dynamic-too` ''or'' `-dynamic`: {{{ λ ../../ghc/inplace/bin/ghc-stage2 -dynamic-too Test.hs [1 of 2] Compiling Weights ( Weights.hs, Weights.o ) [2 of 2] Compiling Test ( Test.hs, Test.o ) }}} Remove the ANN pragma, and the compiler behaves just fine with both GHC versions. Please tell me if I can provide more information. Cheers. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 14:43:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 14:43:03 -0000 Subject: [GHC] #14825: Access violation on Windows is not propagated to the OS In-Reply-To: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> References: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> Message-ID: <060.e9ccd22929d67f5c2cdd55f7594af751@haskell.org> #14825: Access violation on Windows is not propagated to the OS -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #13911 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): That said, the exception handler in pre `8.4` is a bit *too* aggressive in that it catches things it shouldn't. like C++ exceptions. That's also fixed in `8.6`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 14:49:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 14:49:12 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.b5ebdebe42e6b75a5a38a0b0669f2c1a@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): phab:D4423 #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think it's fine for these src ticks to appear anywhere As the Note in comment:2 says, our current story is {{{ Note [CoreSyn top-level string literals] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... It is important to note that top-level primitive string literals cannot be wrapped in Ticks, as is otherwise done with lifted bindings. CoreToStg expects to see just a plain (Lit (MachStr ...)) expression on the RHS of primitive string bindings; anything else and things break. CoreLint checks this invariant. }}} We could change this invariant, by allowing some (or maybe any) ticks around a top-level string literal. That's fine too! We can change the story, presumably by changing the invariant, and changing what `CoreToSTG` does somehow. But what change to `CoreToSTG`? Presumably by uconditionally discarding any ticks wrapped around a top-level literal string. But if we do that, how will GDB ever see that info? I'm ok with either way; but I'd like us to be clear. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 14:50:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 14:50:29 -0000 Subject: [GHC] #14829: Linking error with ANN pragma In-Reply-To: <049.b341381f87ebab5864bf2afae206c047@haskell.org> References: <049.b341381f87ebab5864bf2afae206c047@haskell.org> Message-ID: <064.cc766101ccc040ce93874d983fade8db@haskell.org> #14829: Linking error with ANN pragma -------------------------------------+------------------------------------- Reporter: ehubinette | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ehubinette): After some discussion on the IRC, it might be logical that the ANN payload is dynamically loaded and interpreted. If this is indeed so, I'm pretty sure it's not mentioned anywhere in the documentation, which at least makes the error message highly confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 14:57:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 14:57:05 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.b88d23b297abf106c3c17064c2f08894@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have done a bit of characterisation of the issue since I fear we simply don't have time at this point to come up with a proper solution for 17.10. ||= Distribution =||= binutils version =||= glibc version =||= Affected =|| || Ubuntu Wily (15.10) || || || || || Ubuntu Xenial (16.04) || 2.26 || 2.23 || Yes || || Ubuntu Zesty (17.04) || 2.28 || 2.24 || No || || Debian Jessie (9.0) || 2.28 || 2.24 || No || || Ubuntu Artful (17.10) || 2.29 || 2.26 || No || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 15:19:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 15:19:47 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.40d718cac4ae972e5c62c8a0efb77ba5@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | codeGen/should_fail/T13233 Blocked By: | Blocking: Related Tickets: #14123, #14573 | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: highest => high * milestone: 8.4.1 => 8.6.1 Comment: Let's revisit this for 8.6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 15:20:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 15:20:56 -0000 Subject: [GHC] #14062: Pure syntax transformation affects performance. In-Reply-To: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> References: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> Message-ID: <061.729887569151cb6d52e5ecec8306ab98@haskell.org> #14062: Pure syntax transformation affects performance. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) 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 simonpj): danilo2, can you still reproduce this with 8.4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 15:21:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 15:21:32 -0000 Subject: [GHC] #14825: Access violation on Windows is not propagated to the OS In-Reply-To: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> References: <045.c5862dae061ab95dda6d6a91edc049a2@haskell.org> Message-ID: <060.53ae2ac567e85c2c2d5854417bceed3c@haskell.org> #14825: Access violation on Windows is not propagated to the OS -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #13911 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Great work! Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 15:43:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 15:43:09 -0000 Subject: [GHC] #13422: INLINE CONLIKE sometimes fails to inline In-Reply-To: <045.24512f73acb84c676c1a559d500d9bab@haskell.org> References: <045.24512f73acb84c676c1a559d500d9bab@haskell.org> Message-ID: <060.213b7f42b56725ccda1e5794af469059@haskell.org> #13422: INLINE CONLIKE sometimes fails to inline -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Lovely. Thanks Omer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 15:44:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 15:44:15 -0000 Subject: [GHC] #13930: Cabal configure regresses in space/time In-Reply-To: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> References: <046.5b2c9cbc56e2d7d878c20dcde39f4651@haskell.org> Message-ID: <061.07eadaa7cfc4ec95df6151d33e6aa12e@haskell.org> #13930: Cabal configure regresses in space/time -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.2 Component: Compiler | Version: 8.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13982 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: It seems that Omer was really unable to reproduce this; odd. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 15:50:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 15:50:03 -0000 Subject: [GHC] #14684: combineIdenticalAlts is only partially implemented In-Reply-To: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> References: <049.66bb6a9ebb8aeb6bc16c5fd3f9c006db@haskell.org> Message-ID: <064.d02b80fcfb16862b13e7a031a40de2db@haskell.org> #14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4419 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): Replying to [comment:8 simonpj]: > It's invisible in the message above, but I think this commit is only on branch `wip/T14684`. Is that what you intended? Or did you mean to commit to HEAD? We agreed that the new most-common-RHS code should be moved into `-O2` before it can land in `master`. BTW, regarding [comment:2 your comment above]: > Fortunately, we now have `TrieMap.CoreMap`, an efficient finite map whose keys are `CoreExprs`. Using this I think we can efficiently ask (as we iterate oover the alternatives) "have I seen this RHS in an earlier alternative?". More advanced: find the RHS that occurs most often. Take care that in the common case the RHSs are (a) large and (b) different, then the test does not exhaustively traverse the RHSs; just looks far enough to establish they are different. In the common case you describe, my code will still insert every alternative into the `CoreMap`. I haven't been able to find a less expensive way to establish that the alternatives are all different, but I'd love to hear about any ideas! I have also found `CSE.combineAlts`: {{{ {- Note [Combine case alternatives] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ combineAlts is just a more heavyweight version of the use of combineIdenticalAlts in SimplUtils.prepareAlts. The basic idea is to transform DEFAULT -> e1 K x -> e1 W y z -> e2 ===> DEFAULT -> e1 W y z -> e2 In the simplifier we use cheapEqExpr, because it is called a lot. But here in CSE we use the full eqExpr. After all, two alternatives usually differ near the root, so it probably isn't expensive to compare the full alternative. It seems like the same kind of thing that CSE is supposed to be doing, which is why I put it here. }}} Should `combineAlts` get the same optimization as `combineIdenticalAlts`? Might `combineAlts` even be the ''better'' place to apply the optimization? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 16:05:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 16:05:59 -0000 Subject: [GHC] #14752: Unboxed sums documentation looks wrong In-Reply-To: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> References: <045.c56dd978dba53290cedb4cb39bf3aee9@haskell.org> Message-ID: <060.d6037de898c0f0099d95ec3587237a8b@haskell.org> #14752: Unboxed sums documentation looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Documentation | Version: 8.2.2 Resolution: fixed | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4379 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.4.2 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 16:10:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 16:10:14 -0000 Subject: [GHC] #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance In-Reply-To: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> References: <049.ca8362a13fe0c4bbae46be8c70aa7119@haskell.org> Message-ID: <064.caa0d52d625290acf327dec4aa8fe60c@haskell.org> #14434: GHC 8.2.1 picks wrong instances with -O in a presence of an OVERLAPPABLE instance -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | typecheck/should_compile/T14434 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.2.3 => 8.4.1 Comment: There won't be a 8.2.3 at this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 16:14:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 16:14:28 -0000 Subject: [GHC] #11285: Split objects makes static linking really slow In-Reply-To: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> References: <045.da344af65e5aa0991513da9c032d7b2a@haskell.org> Message-ID: <060.fde3d7df324344985b4b5f7fb2d5d4aa@haskell.org> #11285: Split objects makes static linking really slow -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.11 (Linking) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix Comment: Given that (a) split objects will soon be ripped out and replaced with split sections (likely for 8.6, see #13939) , and (b) we now use `ld.gold` when possible (#13541) I think this can be safely closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 16:27:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 16:27:34 -0000 Subject: [GHC] #14001: Inlining does not work between modules In-Reply-To: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> References: <046.edd18961427735df8fa75fe7e6af749f@haskell.org> Message-ID: <061.9c8561029e08355b7020c18aa40b3818@haskell.org> #14001: Inlining does not work between modules -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Regarding comment:10: In general GHC can only evaluate things which it can prove will eventually be forced by the program. Consequently if you have, {{{#!hs (.) :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) h = f . g }}} The performance characteristics of `h` will naturally depend upon the strictness characteristics of `f` and `g`. If both are strict in their first argument then it would be safe to first force `h`'s argument, as you do in your strict composition operator. However, if either are lazy then changing the strictness of `(.)` will change the semantics of the program, potentially resulting in an incorrectly bottom program. > Thus I believe we should consider this bug and should expect from GHC to automatically optimize usages of `(.)` in strict code. Perhaps, but what do you consider to be "strict code"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 16:28:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 16:28:11 -0000 Subject: [GHC] #14830: Use test instead of cmp for comparison against zero. Message-ID: <047.ca37bf7e6f971d0d97b5218e90d6b786@haskell.org> #14830: Use test instead of cmp for comparison against zero. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: (NCG) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For comparisons `test r, r` and `cmp r, $0` are interchangeable at least on x86. However using test leads to slightly smaller code. (Saves a byte per comparison). A good starting point is stmtToInstrs in compiler/nativeGen/X86/CodeGen starting with how CmmCondBranch is compiled to Instructions. From there it should be not too hard to track down the required changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 16:29:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 16:29:16 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.309f4f9d264371fc230ee708eda3d7a9@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I should mention that there are a few crashes which I've seen in the past that may be related. Specifically, #14291 and #14705. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 16:37:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 16:37:41 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.08cc377941ea1cf3344a55b9ae45d07a@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:8 nomeata]: > So – can we just include the free variables in the strictness signature during fixpointing and get that optimization without the code transformation? Well, actually I had expected DmdAnal to just work here. Not sure why `f` doesn't end up in `go`s signature, I suspected this has something to do with this `Lazy and unleashable free variables` hack, but I'm not so sure anymore. I'll investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 16:42:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 16:42:16 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.257ef3006a024d698ea9153323ddd30e@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 17:02:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 17:02:00 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.09e2ca5ddaf32947c8ac6399c2748f8b@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ersetzen): Oh, you are right, this totally falls under loopification. Curiously enough wip/T14068 doesn't solve this, though. I think it gets stuck at the `inline f step`. Here an excerpt of the [https://gist.github.com/Tarmean/5d423b454dd75f8db11505eb28841ad1 simplifier dump]. I was always under the impression that non-recursive let bound variables that are used exactly once (which is the case here) are inlined unconditionally but that doesn't happen here. [https://gist.github.com/Tarmean/6edf2153806434e688d1fd77964248ed Here is a slightly more inlined version]. Removing `{-# INLINE indices #-}` allows buildTable to be inlined which removes the call. Looking at the cmm, scan saves and restors 96 bytes of data when calling buildTable so that might be a large part of the performance drop? Side note: Neither the loopification branch and ghc head run faster with ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 17:46:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 17:46:57 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.2f3e8932d466cd13e7268ba25d2dab72@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): OK, this is due to the call to [https://github.com/ghc/ghc/blob/81a5e05d376c075a38e55bc124ea6226c1f3bef7/compiler/stranal/DmdAnal.hs#L659 reuseEnv here] (that function effectively duplicates every demand, so `1*C1(U(U)) -> C(U(U))`) with the explanation in `Aggregated demand for cardinality`, the gist of which is that we have to treat free variables of let-bound thunks differently in usage analysis than we would like to for strictness analysis. I think this should only be relevant for thunks, e.g. we should first `splitFVs is_thunk rhs_fv` and only then `reuseEnv` the `lazy_fv`. I'll give that a shot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 18:00:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 18:00:02 -0000 Subject: [GHC] #13154: Standalone-derived anyclass instances aren't as permissive as empty instances In-Reply-To: <050.313c7572181a73220f1b076de5274da4@haskell.org> References: <050.313c7572181a73220f1b076de5274da4@haskell.org> Message-ID: <065.8b3a30e886f8b17676ebb74ca8e42330@haskell.org> #13154: Standalone-derived anyclass instances aren't as permissive as empty instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: deriving 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:D4337, Wiki Page: | Phab:D4370 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"f4336593a390e6317ac2852d8defb54bfa633d3e/ghc" f4336593/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f4336593a390e6317ac2852d8defb54bfa633d3e" Slight refactor of stock deriving internals Summary: Before, the `hasStockDeriving` function, which determines how derived bindings should be generated for stock classes, was awkwardly separated from the `checkSideConditions` function, which checks invariants of the same classes that `hasStockDeriving` does. As a result, there was a fair deal of hoopla needed to actually use `hasStockDeriving`. But this hoopla really isn't required—we should be using `hasStockDeriving` from within `checkSideConditions`, since they're looking up information about the same classes! By doing this, we can eliminate some kludgy code in the form of `mk_eqn_stock'`, which had an unreachable `pprPanic` that was stinking up the place. Reviewers: bgamari, dfeuer Reviewed By: bgamari Subscribers: dfeuer, rwbarton, thomie, carter GHC Trac Issues: #13154 Differential Revision: https://phabricator.haskell.org/D4370 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 18:30:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 18:30:07 -0000 Subject: [GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array# In-Reply-To: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> References: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> Message-ID: <064.51eb844ff1e53943f16b1324856afcf1@haskell.org> #14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by bgamari): This would probably make for a good [[https://github.com/ghc-proposals /ghc-proposals|proposal]] since it will affect a relatively large number of users. That being said, given that `UnliftedArray#` is a strict generalization of `ArrayArray#` I expect it won't be *that* hard to expose the existing `ArrayArray#` interface built on top of `UnliftedArray#`. The only annoying issue is that users often import `GHC.Prim` directly, which has no Haskell module associated with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 19:23:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 19:23:24 -0000 Subject: [GHC] #14829: Linking error with ANN pragma In-Reply-To: <049.b341381f87ebab5864bf2afae206c047@haskell.org> References: <049.b341381f87ebab5864bf2afae206c047@haskell.org> Message-ID: <064.8bc15decb595cb80b2368da4b75068a9@haskell.org> #14829: Linking error with ANN pragma -------------------------------------+------------------------------------- Reporter: ehubinette | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tritlo): * cc: Tritlo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 19:59:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 19:59:26 -0000 Subject: [GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array# In-Reply-To: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> References: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> Message-ID: <064.d9554c3feb7774435dd42811a1c76db6@haskell.org> #14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by andrewthad): If `UnliftedNewtypes`, described in https://github.com/ghc-proposals/ghc- proposals/pull/98, is accepted, it will be trivial to reimplement `ArrayArray#`, and its related functions: {{{ newtype ArrayArray# = ArrayArray# (UnliftedArray# ByteArray#) }}} It's not important to use `ByteArray#` here. You could use any unlifted type since you're just going to unsafe coerce it when you pull in out or put it in. I guess these operators would need to go in `GHC.Exts` or something like that, which would probably still break some people's code since we all love to import `GHC.Prim` so much, but at least it provides a good backwards-compatibility option. I'll wait to see if `UnliftedNewtypes` is accepted. If so, I'll write this up as a proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 21:26:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 21:26:28 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.4129ec9e8e64521dfaced7e7b6b1bd42@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 21:42:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 21:42:18 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.ee8d8efeb5297d98f59d6811d5f08c90@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.6.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): Phab:D3758 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D3758 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 22:53:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 22:53:10 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.3e9027d332e9932b6db51f84be121059@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm too swamped to follow up why `f` doesn't get inlined on the branch, but I know that Joachim is planning to get back to loopification. > Side note: Neither the loopification branch and ghc head run faster with ghci. The Description says that ghci is 20x faster (in 8.2.2). So in HEAD do we have the 20x fast performance in both cases (ie good), or do we have the 1x performance in both cases (ie bad)? I still don't understand why GHCi wins so big in any version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 20 23:15:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Feb 2018 23:15:53 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.6c91cba38de6611ac9757174417e55df@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomers 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 sjakobi): * cc: sjakobi (added) Comment: Replying to [comment:2 Mathnerd314]: > Can we instead have primops which take both an offset measured in bytes and an offset measured in terms of the type? > {{{#!hs > indexTYPEArray# :: ByteArray# -> Int# {-byte offset-} -> Int# {-type offset-} -> TYPE# > readTYPEArray# :: MutableByteArray# s -> Int# {-byte offset-} -> Int# {-type offset-} -> State# s -> (#State# s, TYPE##) > writeTYPEArray# :: MutableByteArray# s -> Int# {-byte offset-} -> Int# {-type offset-} -> TYPE# -> State# s -> State# s > > indexTYPEOffAddr# :: Addr# -> Int# {-byte offset-} -> Int# {-type offset-} -> TYPE > readTYPEOffAddr# :: Addr# -> Int# {-byte offset-} -> Int# {-type offset-} -> State# s -> (#State# s, TYPE ##) > writeTYPEOffAddr# :: Addr# -> Int# {-byte offset-} -> Int# {-type offset-} -> TYPE -> State# s -> State# s > }}} I like these types. > All of these go through the `mkBasicIndexed{Read,Write}` functions, which take both a byte offset and a type offset, so it seems reasonable to expose that. I currently don't see how this can be done. These functions require a byte offset with type `ByteOff` (`Int`) but we only have a `CmmExpr`. It seems to me that the new primops will require quite a bit of new plumbing down to `CmmRegOff`. Am I missing something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 00:05:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 00:05:33 -0000 Subject: [GHC] #14733: Won't use (forall xx. f xx) with -XQuantifiedConstraints In-Reply-To: <051.d6dd7c53fb2316d2a32445d192b9d697@haskell.org> References: <051.d6dd7c53fb2316d2a32445d192b9d697@haskell.org> Message-ID: <066.6c67a5af595890acba9c820615293091@haskell.org> #14733: Won't use (forall xx. f xx) with -XQuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have fixed this (on branch `wip/TT2893`); and updated the proposal to reflect it Would you like to try now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 00:07:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 00:07:41 -0000 Subject: [GHC] #9123: Need for higher kinded roles In-Reply-To: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> References: <046.743e1f5edf878b0ae2d2d6b5081e6a33@haskell.org> Message-ID: <061.8edae71e33c283a7841db41aefb9b39d@haskell.org> #9123: Need for higher kinded roles -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Keywords: Roles, Resolution: | QuantifiedConstraints Operating System: 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 I agree. I'll work on adding superclasses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 00:12:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 00:12:40 -0000 Subject: [GHC] #14609: Per-instance UndecidableInstances In-Reply-To: <048.249a939a6e76cafabb0ae79267f4d3cf@haskell.org> References: <048.249a939a6e76cafabb0ae79267f4d3cf@haskell.org> Message-ID: <063.f640332b61392ab75d69a11f333378e7@haskell.org> #14609: Per-instance UndecidableInstances -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.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): Per family decl, I think -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 01:48:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 01:48:21 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.67a3c71c01a5b058ead159bebdbf8c6d@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ersetzen): Turns out there was an issue that's really easy to miss with liberate-case turned on: {{{ useSite :: Int -> Int useSite i = 10 * (delayedInline i) delayedInline :: Int -> Int delayedInline i = inline i {-# INLINE [1] delayedInline #-} inline :: Int -> Int inline nlen = loop 0 where shouldFloat i | i > 100 = i | otherwise = shouldFloat (i+1) loop i | i > 5 = 0 | otherwise = loop (i + skip) where !skip = shouldFloat nlen {-# INLINE inline #-} }}} First inline is optimized as expected and shouldFloat is floated out. Then delayedInline is inlined with the original code and in that copy shouldFloat remains in loop: {{{ -- RHS size: {terms: 24, types: 9, coercions: 0, joins: 1/1} inline inline = \ nlen_a1u2 -> case nlen_a1u2 of { I# ww_s31T -> case $wshouldFloat_s31Y ww_s31T of ww_s31X { __DEFAULT -> joinrec { $wloop_s328 $wloop_s328 ww_s326 = case tagToEnum# (># ww_s326 5#) of { False -> jump $wloop_s328 (+# ww_s326 ww_s31X); True -> lvl_s2ZH }; } in jump $wloop_s328 0# } } -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} delayedInline delayedInline = inline -- RHS size: {terms: 37, types: 14, coercions: 0, joins: 2/3} useSite useSite = \ w_s32l -> case w_s32l of { I# ww_s32o -> joinrec { $wloop_s32k $wloop_s32k ww_s32i = let { lvl_s33v lvl_s33v = tagToEnum# (># ww_s32i 5#) } in joinrec { $wshouldFloat_s32e $wshouldFloat_s32e ww_s32c = case tagToEnum# (># ww_s32c 100#) of { False -> jump $wshouldFloat_s32e (+# ww_s32c 1#); True -> case lvl_s33v of { False -> jump $wloop_s32k (+# ww_s32i ww_s32c); True -> lvl_s2ZH } }; } in jump $wshouldFloat_s32e ww_s32o; } in jump $wloop_s32k 0# } }}} Branch and Head ghci run with 1x performance for me i.e. bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 03:04:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 03:04:02 -0000 Subject: [GHC] #14826: Flatten data types extending other data types in STG In-Reply-To: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> References: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> Message-ID: <061.3cb3ae5e04472813c00a29c0047bf3be@haskell.org> #14826: Flatten data types extending other data types in STG -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: 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): A real-life example where people use horrible unsafe tricks to achieve essentially this: https://github.com/gregorycollins/hashtables/blob/fd385db6c81e157e2922e74664384980a651160e/src/Data/HashTable/Internal/UnsafeTricks.hs#L72 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 05:00:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 05:00:47 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.e61b14e07549d82d6a9779410231dfbf@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Just had a brief look, just to remind myself of the issues here, and compared the Core of `x2n1`. With `-O`, I see loopification happening (yay!) and no allocation changes (expected). But with `-O -fspec-constr`, I see the big increase that is also reported by perf.haskell.org. It might just be an unwanted side effect of me trying preventing inlining of loopification, and might go away when I release this break – but then other things happen. Well, I should test that hypothesis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 05:33:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 05:33:31 -0000 Subject: [GHC] #14098: Incorrect pattern match warning on nested GADTs In-Reply-To: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> References: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> Message-ID: <062.3c9b1916435abdfd573c1be4882ed6cf@haskell.org> #14098: Incorrect pattern match warning on nested GADTs -------------------------------------+------------------------------------- Reporter: jmgrosen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11984 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK. I now have a better understand of what is going wrong. It all has to do with coercion patterns. In source syntax, we have: {{{#!hs f :: T f a -> App f a -> () f C (App TBool) = ... }}} When desugared to Core, this turns into (roughly): {{{#!hs f :: T f a -> App f a -> () f @f @a (C co1 co2) (App @a1 co3 (TBool |> co1)) = () }}} Where `a1` is an existentially quantified type variable bound by `App`. When checking for pattern-match coverage, it turns out we desugar the coercion pattern `TBool |> co1` into a guard! So the clause ends up looking something like: {{{#!hs f C (App pmvar123) | TBool <- pmvar123 |> co1 = () }}} Note that the type of `pmvar123` is `f a1`—this will be important later. Now, we proceed with coverage-checking the guard as usual. When we come to the ConVar case for `App`, we end up creating a fresh variable `a2` to represent its existentially quantified type variable, as described in the GADTs Meet Their Match paper. However, when we check the guard, it's going to use `a1` instead of `a2`, since that's the type variable mentioned in the type of `pmvar123`, not `a2`! As a result, we generate some equality constraints mentioning `a1` and some mentioning `a2`, but they end up being disjoint in the end (that is, we never generate an `a1 ~ a2`), so GHC believes the overall constraint set is satisfiable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 06:19:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 06:19:06 -0000 Subject: [GHC] #14824: automatically select instance In-Reply-To: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> References: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> Message-ID: <059.cecefc97d130c524d83ea577074b76d2@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 AntC): I'm afraid we'll need a bit of elaboration to know what this means. What do you expect to see? Your instance declarations do not give implementations for method `m`. There are no `FunctionalDependencies` so all of those instances are valid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 06:40:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 06:40:33 -0000 Subject: [GHC] #14536: Ghc panics while building stage2 with -dstg-lint In-Reply-To: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> References: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> Message-ID: <058.5059e3b7475e8111221ff679f27fe92d@haskell.org> #14536: Ghc panics while building stage2 with -dstg-lint -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4242 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => closed * resolution: => fixed Comment: Fixed via #14787. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 06:41:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 06:41:06 -0000 Subject: [GHC] #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o In-Reply-To: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> References: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> Message-ID: <058.32c6942d552b6646c3c740a3d4064f3c@haskell.org> #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => fixed Comment: Fixed via #14787. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 06:41:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 06:41:35 -0000 Subject: [GHC] #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o In-Reply-To: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> References: <043.cd9c2f13d20866525a2d25a84f929b95@haskell.org> Message-ID: <058.99845682e53866a839be0dacdd561892@haskell.org> #14541: Stg lint failure while building ghc-stage2: compiler/stage2/build/Hoopl/Block.o -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14787 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #14787 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 06:41:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 06:41:47 -0000 Subject: [GHC] #14536: Ghc panics while building stage2 with -dstg-lint In-Reply-To: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> References: <043.07052cd8274441bc63c2d750cdfb2370@haskell.org> Message-ID: <058.5794897045cbcd4004e4cbd6113d8cbd@haskell.org> #14536: Ghc panics while building stage2 with -dstg-lint -------------------------------------+------------------------------------- Reporter: duog | Owner: duog Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: stg-lint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14787 | Differential Rev(s): Phab:D4242 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #14787 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 06:47:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 06:47:54 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.675b10d16680f8c53e440cbc9ecd1778@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"a032ff77210736df45cf49820c882f40dc10230e/ghc" a032ff7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a032ff77210736df45cf49820c882f40dc10230e" Add references to #6087 [skip ci] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 06:48:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 06:48:38 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.7743260c4ac530b3aaf52c676cb271eb@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): We decided to put this on hold at the meeting. Just a small update: the case in comment:27 seems to be a limitation with the current demand analyser. It sometimes introduces reboxing that can't be eliminated by the simplifier. Example: {{{ {-# NOINLINE check #-} check :: Int -> Bool check !n = True f_ :: Int -> Int f_ n = if check n then n else n * f_ (n - 1) }}} even after simplifications we rebox the argument: {{{ Rec { -- RHS size: {terms: 17, types: 3, coercions: 0, joins: 0/0} $wf_ $wf_ = \ ww_s28U -> case check (I# ww_s28U) of { False -> case $wf_ (-# ww_s28U 1#) of ww1_s28Y { __DEFAULT -> *# ww_s28U ww1_s28Y }; True -> ww_s28U } end Rec } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 06:54:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 06:54:12 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.1dd391f1b38ff35fbda83a6a05ee29a2@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763, #13422 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I pushed my branch to `wip/cheap-build-osa1` in GHC's git repo as well. Also attached the nofib output. As to why `nums` is not inlined in comment:24, I see this in `-ddump- inlinings` output: {{{ Considering inlining: nums_aSY arg infos [] interesting continuation RuleArgCtxt some_benefit False is exp: False is work-free: False guidance ALWAYS_IF(arity=0,unsat_ok=False,boring_ok=False) ANSWER = NO }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 06:55:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 06:55:00 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.66c54dc6a087a264e5559ce2d6e9139e@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763, #13422 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * Attachment "cheap_build_nofib" added. nofib reuslts with `wip/cheap-build-osa1` branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 09:38:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 09:38:19 -0000 Subject: [GHC] #14826: Flatten data types extending other data types in STG In-Reply-To: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> References: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> Message-ID: <061.4d19ce369e102513bcbf216d74d0e420@haskell.org> #14826: Flatten data types extending other data types in STG -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: 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. Consider what happens today with the Haskell source {{{ data T = MkT {-# UNPACK #-} !Int Bool f (MkT n b) = MkT (n+1) b }}} We get the following Core {{{ data T = MkT Int# Bool $WMkT :: Int -> Bool -> T $WMkT n = case n of I# n# -> MkT n# b f x = case x of MkT n# b -> let n = I# n# in $WMkT (n+1) b }}} That is * The "real" Core data constructor `MkT` has an `Int#` field. * The wrapper `$WMkT` is an ordinary function that unboxes the field and calls the "real" data constructor * Pattern matching is desugared to rebox the field You could do the same thing here. With your example source {{{ data Foo = A Int | B Bool | C data Result = Ok !Foo | NotOK Error f :: Result -> Int f (Ok x) = wimwam x True x f (NotOk _) = 0 }}} you might desugar to {{{ data Result = Ok_A Int | OK_B Bool | OK_C C | NotOK Error f r = join j x = wimwam x True x in case r of OK_A n -> jump j (A n) OK_B b -> jump j (B b) OK_C -> jump j C NOtOK _ -> 0 }}} Note that I am NOT re-using the data constructor for `Foo` (which would be tricky and confusing). I'm simply generating new ones. ----------------- I think this would be do-able. It uses basically the same concepts as now, but generalises a bit. I wonder if we could leverage pattern synonyms rather than have more built-in stuff. -------------- A concern: it could blow up {{{ data T = MkT !(Maybe Int) !(Maybe Int) }}} Do we generate four constructors? In general a multiplicative number? You suggest just one field, but it'd be a shame of your perf went down the tubes because you added an innocuous field. And actually two or more is fine, provide only one expands to a multiplicity: {{{ data T = MkT !Char !(Maybe Int) Bool }}} is absolutely ok, desugaring to {{{ data T = MkT_Just Char# Int Bool | MkT_Nothing Char# Bool -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 09:45:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 09:45:30 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.f915e84f3e805d3265be2c9bce924908@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Correct. Another example might be {{{ f :: Int -> [Int] f 0 = [] f n = n : f (n-1) }}} It's strict all right, but we need the boxed 'n' for the result. "Boxity" analysis might try to figure out when the boxed version is needed, and pass that too. At one stage I had that but it seemed unprincipled. Bottom line so far: late demand analysis can be a win, but only rarely so; and it can be a loss. It's a pity -- I'd like to make it part of -O2. But we probably have higher priorities for now. ''Can you add the nofib numbers in a comment, please, for posterity?'' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 09:48:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 09:48:24 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.16f5da7dc8acc9474452f32e8bda9594@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763, #13422 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Bottom line seems to be: * Nofib results are no better, but no worse * Some examples/tickets (which specifically?) really do improve. Conclusion: let's do it. Ensuring that a Note gives a clear explanation, and points to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 09:52:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 09:52:13 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.67193e425a7736321ff1a80edd16d53e@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): (the text below is also attached as file "analyse") {{{ NoFib Results -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- CS 0.0% 0.0% 0.156 0.156 0.0% CSD 0.0% 0.0% -19.8% -19.8% 0.0% FS 0.0% 0.0% -7.0% -7.0% 0.0% S 0.0% 0.0% -11.6% -11.6% 0.0% VS 0.0% 0.0% -5.5% -5.6% 0.0% VSD 0.0% 0.0% 0.009 0.009 0.0% VSM 0.0% 0.0% -14.3% -14.3% 0.0% anna +0.2% +0.0% 0.056 0.056 0.0% ansi 0.0% 0.0% 0.000 0.000 0.0% atom +0.0% 0.0% 0.136 0.136 0.0% awards +0.0% 0.0% 0.000 0.000 0.0% banner +0.0% 0.0% 0.000 0.000 0.0% bernouilli -0.0% 0.0% 0.095 0.095 0.0% binary-trees +0.0% 0.0% -8.5% -8.5% 0.0% boyer +0.0% -0.0% 0.024 0.024 0.0% boyer2 0.0% -2.1% 0.006 0.006 0.0% bspt +0.1% +0.2% 0.006 0.006 +50.0% cacheprof +0.2% -0.0% 0.191 0.191 -1.8% calendar +0.1% +0.0% 0.001 0.001 0.0% cichelli -0.0% 0.0% 0.042 0.042 -2.7% circsim +0.1% +0.2% -2.6% -2.6% -2.8% clausify +0.1% +0.0% 0.020 0.021 0.0% comp_lab_zift -0.0% -0.3% 0.097 0.097 -11.1% compress 0.0% 0.0% 0.076 0.076 0.0% compress2 +0.1% -0.0% 0.078 0.078 0.0% constraints +0.1% +0.6% +0.4% +0.3% -0.8% cryptarithm1 0.0% 0.0% -0.9% -0.7% 0.0% cryptarithm2 +0.0% 0.0% 0.005 0.005 0.0% cse +0.0% +0.2% 0.001 0.001 0.0% digits-of-e1 0.0% 0.0% +2.0% +2.0% 0.0% digits-of-e2 -0.1% +0.0% -3.2% -3.2% 0.0% eliza +0.0% -0.0% 0.001 0.001 0.0% event +0.1% +0.0% 0.075 0.075 0.0% exact-reals +0.2% 0.0% +1.2% +1.2% 0.0% exp3_8 0.0% 0.0% 0.125 0.125 0.0% expert +0.1% +0.1% 0.000 0.001 0.0% fannkuch-redux 0.0% 0.0% -6.1% -6.1% 0.0% fasta +0.0% 0.0% +54.1% +53.9% 0.0% fem +0.0% -0.0% 0.015 0.015 0.0% fft +0.0% +0.0% 0.024 0.024 0.0% fft2 +0.0% 0.0% 0.045 0.045 0.0% fibheaps +0.0% 0.0% 0.016 0.016 0.0% fish 0.0% 0.0% 0.006 0.006 0.0% fluid +0.2% +0.3% 0.005 0.005 0.0% fulsom +0.1% 0.0% 0.136 0.136 0.0% gamteb -0.1% -0.1% 0.022 0.022 0.0% gcd 0.0% 0.0% 0.025 0.025 0.0% gen_regexps -0.0% 0.0% 0.000 0.000 0.0% genfft -0.0% -0.2% 0.019 0.019 0.0% gg +0.1% +0.0% 0.008 0.008 0.0% grep +0.0% 0.0% 0.000 0.000 0.0% hidden -0.0% -0.2% 0.193 0.193 0.0% hpg +0.0% 0.0% 0.068 0.068 0.0% ida +0.1% +0.4% 0.048 0.048 0.0% infer +0.0% 0.0% 0.033 0.033 0.0% integer 0.0% 0.0% -1.0% -1.0% 0.0% integrate 0.0% 0.0% 0.060 0.060 0.0% k-nucleotide -0.0% 0.0% -10.6% -10.8% 0.0% kahan 0.0% 0.0% 0.172 0.172 0.0% knights 0.0% 0.0% 0.004 0.004 0.0% lambda 0.0% 0.0% -1.4% -1.4% 0.0% last-piece -0.1% -1.2% -3.5% -3.6% 0.0% lcss +0.0% 0.0% +0.3% +0.4% 0.0% life -0.0% 0.0% 0.124 0.124 0.0% lift +0.0% 0.0% 0.001 0.001 0.0% linear +0.1% 0.0% +7.2% +7.2% 0.0% listcompr +0.0% -0.0% 0.051 0.051 0.0% listcopy +0.0% -0.0% 0.052 0.052 0.0% maillist +0.1% +0.0% 0.034 0.034 +2.7% mandel 0.0% 0.0% 0.033 0.033 0.0% mandel2 +0.0% -11.3% 0.004 0.004 0.0% mate -0.2% +5.0% -17.9% -17.9% 0.0% minimax 0.0% 0.0% 0.002 0.002 0.0% mkhprog 0.0% 0.0% 0.001 0.001 0.0% multiplier +0.0% -0.0% 0.052 0.052 0.0% n-body -0.0% -0.1% -1.9% -1.9% 0.0% nucleic2 -0.3% +1.5% 0.035 0.035 0.0% para +0.2% +1.3% 0.148 0.148 0.0% paraffins +0.0% 0.0% 0.065 0.065 0.0% parser +0.0% 0.0% 0.017 0.017 0.0% parstof +0.2% 0.0% 0.004 0.004 0.0% pic -0.0% -1.0% 0.005 0.005 0.0% pidigits +0.0% 0.0% -3.2% -3.2% 0.0% power +0.3% 0.0% 0.190 0.191 0.0% pretty 0.0% 0.0% 0.000 0.000 0.0% primes +0.0% 0.0% 0.041 0.041 0.0% primetest -0.0% -0.2% 0.061 0.061 0.0% prolog +0.0% -0.0% 0.001 0.001 0.0% puzzle +0.2% 0.0% 0.068 0.068 0.0% queens 0.0% 0.0% 0.012 0.012 0.0% reptile +0.1% +0.0% 0.007 0.007 0.0% reverse-complem 0.0% 0.0% 0.078 0.078 0.0% rewrite +0.1% -0.0% 0.011 0.011 0.0% rfib 0.0% 0.0% 0.009 0.009 0.0% rsa +0.0% -0.0% 0.017 0.017 0.0% scc 0.0% 0.0% 0.000 0.000 0.0% sched +0.1% -0.0% 0.013 0.013 0.0% scs -0.3% +0.0% -1.5% -1.5% 0.0% simple -0.1% -0.7% 0.109 0.109 0.0% solid +0.1% -0.1% 0.063 0.063 0.0% sorting +0.0% 0.0% 0.002 0.002 0.0% spectral-norm 0.0% 0.0% -0.1% -0.1% 0.0% sphere +0.0% 0.0% 0.026 0.026 0.0% symalg +0.0% 0.0% 0.007 0.007 0.0% tak 0.0% 0.0% 0.006 0.006 0.0% transform -0.0% -0.8% 0.165 0.165 0.0% treejoin 0.0% 0.0% 0.077 0.077 0.0% typecheck +0.1% -0.0% 0.131 0.131 0.0% veritas +0.0% 0.0% 0.001 0.001 0.0% wang +0.1% -0.0% 0.053 0.053 0.0% wave4main +0.0% 0.0% 0.125 0.125 0.0% wheel-sieve1 0.0% 0.0% -0.2% -0.2% 0.0% wheel-sieve2 +0.0% 0.0% 0.116 0.116 0.0% x2n1 +0.0% 0.0% 0.003 0.003 0.0% -------------------------------------------------------------------------------- Min -0.3% -11.3% -19.8% -19.8% -11.1% Max +0.3% +5.0% +54.1% +53.9% +50.0% Geometric Mean +0.0% -0.1% -2.8% -2.8% +0.2% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 10:03:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 10:03:25 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.0fb377354813854905fa9f53bbf7a571@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. But that code does not look too bad to me. Yes `shouldFloat` is not floated, but it's just a loop, so floating would not really change its performance. The badness is perhaps, that `lvl_s33v :: Bool` is allocated (as a thunk) on every iteration of `wloop`. Can you show the 20x faster code? Perhaps by removing the pragmas or something? Incidentally, Joachim's exitification pass (in HEAD and 8.4) will remove the inefficient thunk for `lvl_s33v`. Does it go 20x faster? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 10:04:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 10:04:46 -0000 Subject: [GHC] #12442: Pure unifier usually doesn't need to unify kinds In-Reply-To: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> References: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> Message-ID: <062.10f33bb42887d66eb2a64844819ef7fb@haskell.org> #12442: Pure unifier usually doesn't need to unify kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T12442 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2433 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Re-opening so Richard can attend to comment:5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 10:04:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 10:04:56 -0000 Subject: [GHC] #12442: Pure unifier usually doesn't need to unify kinds In-Reply-To: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> References: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> Message-ID: <062.5e23b408a91c3eb59e2423ea388a8600@haskell.org> #12442: Pure unifier usually doesn't need to unify kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T12442 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2433 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 10:22:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 10:22:58 -0000 Subject: [GHC] #14831: QuantifiedConstraints: Odd superclass constraint Message-ID: <051.631b3f4dec55319ae6028526fc90fcb8@haskell.org> #14831: QuantifiedConstraints: Odd superclass constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code works {{{#!hs {-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances #-} import Data.Semigroup newtype Free cls a = Free () instance (forall xx. cls xx => Semigroup xx) => Semigroup (Free cls a) where (<>) = undefined stimes = undefined sconcat = undefined -- instance (forall xx. cls xx => Semigroup xx) => Monoid (Free cls a) where -- mempty = undefined }}} but uncomment the `Monoid` instance and we get {{{ $ ghci -ignore-dot-ghci /tmp/I.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/I.hs, interpreted ) /tmp/I.hs:12:10: error: • Could not deduce: cls (Free cls a) arising from the superclasses of an instance declaration from the context: forall xx. cls xx => Semigroup xx bound by the instance declaration at /tmp/I.hs:12:10-67 • In the instance declaration for ‘Monoid (Free cls a)’ | 12 | instance (forall xx. cls xx => Semigroup xx) => Monoid (Free cls a) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, no modules loaded. Prelude> }}} Is this correct behavior? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 10:27:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 10:27:45 -0000 Subject: [GHC] #14831: QuantifiedConstraints: Odd superclass constraint In-Reply-To: <051.631b3f4dec55319ae6028526fc90fcb8@haskell.org> References: <051.631b3f4dec55319ae6028526fc90fcb8@haskell.org> Message-ID: <066.19d895cbd3bc7c50794fcbb78eabf12d@haskell.org> #14831: QuantifiedConstraints: Odd superclass constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): Based off recent changes (ticket:14733#comment:9), I think this worked before -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 10:34:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 10:34:01 -0000 Subject: [GHC] #14734: QuantifiedConstraints conflated with impredicative polymorphism? In-Reply-To: <051.b13ce9a287df15f46f4472a3cecc22de@haskell.org> References: <051.b13ce9a287df15f46f4472a3cecc22de@haskell.org> Message-ID: <066.7f42447ba1bfc0797b8ef1b235869ecc@haskell.org> #14734: QuantifiedConstraints conflated with impredicative polymorphism? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: invalid | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): It feels different, there is no way to get around regular impredicativity with type synonyms but in this case we can get around it with the `Limit` class synonym. Hypothetically if GHC were to generate an internal class synonym for impredicative constraints what would go wrong? I'm not aware of differences between `forall xx. f xx` and `Limit f`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 10:36:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 10:36:42 -0000 Subject: [GHC] #14824: automatically select instance In-Reply-To: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> References: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> Message-ID: <059.c27be0876b46c2efea6a110942962e65@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 zaoqi): Replying to [comment:2 AntC]: > I'm afraid we'll need a bit of elaboration to know what this means. > > What do you expect to see? Your instance declarations do not give implementations for method `m`. > > There are no `FunctionalDependencies` so all of those instances are valid. If I write `b -> a` in that, `Type inference` can't work. I can't write `a -> b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 10:37:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 10:37:45 -0000 Subject: [GHC] #14824: automatically select instance In-Reply-To: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> References: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> Message-ID: <059.4abc64e79977dc7199f12bd88bb514ac@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 zaoqi): Replying to [comment:3 zaoqi]: > Replying to [comment:2 AntC]: > > I'm afraid we'll need a bit of elaboration to know what this means. > > > > What do you expect to see? Your instance declarations do not give implementations for method `m`. > > > > There are no `FunctionalDependencies` so all of those instances are valid. > If I write `b -> a` in that, `Type inference` can't work correctly. > > I can't write `a -> b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 10:38:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 10:38:44 -0000 Subject: [GHC] #14733: Won't use (forall xx. f xx) with -XQuantifiedConstraints In-Reply-To: <051.d6dd7c53fb2316d2a32445d192b9d697@haskell.org> References: <051.d6dd7c53fb2316d2a32445d192b9d697@haskell.org> Message-ID: <066.459e68a869c50b64c2b01ca6385f5714@haskell.org> #14733: Won't use (forall xx. f xx) with -XQuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): Thank you! I played with it yesterday and it works great with a few kinks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 10:46:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 10:46:48 -0000 Subject: [GHC] #14831: QuantifiedConstraints: Odd superclass constraint In-Reply-To: <051.631b3f4dec55319ae6028526fc90fcb8@haskell.org> References: <051.631b3f4dec55319ae6028526fc90fcb8@haskell.org> Message-ID: <066.33963d8e268cc256fbafca08523b7f39@haskell.org> #14831: QuantifiedConstraints: Odd superclass constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): Similarly {{{#!hs newtype Free :: (Type -> Constraint) -> (Type -> Type) where Free :: () -> Free cls a instance (forall xx. cls xx => Semigroup xx) => Semigroup (Free cls a) where (<>) = undefined }}} fails because of the default methods `sconcat` and `stimes` {{{#!hs class Semigroup a where (<>) :: a -> a -> a sconcat :: NonEmpty a -> a stimes :: Integral b => b -> a -> a }}} {{{ GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( I.hs, interpreted ) I.hs:10:10: error: • Could not deduce: cls (Free cls a) arising from a use of ‘GHC.Base.$dmsconcat’ from the context: forall xx. cls xx => Semigroup xx bound by the instance declaration at I.hs:10:10-70 • In the expression: GHC.Base.$dmsconcat @(Free cls a) In an equation for ‘sconcat’: sconcat = GHC.Base.$dmsconcat @(Free cls a) In the instance declaration for ‘Semigroup (Free cls a)’ • Relevant bindings include sconcat :: GHC.Base.NonEmpty (Free cls a) -> Free cls a (bound at I.hs:10:10) | 10 | instance (forall xx. cls xx => Semigroup xx) => Semigroup (Free cls a) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I.hs:10:10: error: • Could not deduce: cls (Free cls a) arising from a use of ‘GHC.Base.$dmstimes’ from the context: forall xx. cls xx => Semigroup xx bound by the instance declaration at I.hs:10:10-70 or from: Integral b bound by the type signature for: stimes :: forall b. Integral b => b -> Free cls a -> Free cls a at I.hs:10:10-70 • In the expression: GHC.Base.$dmstimes @(Free cls a) In an equation for ‘stimes’: stimes = GHC.Base.$dmstimes @(Free cls a) In the instance declaration for ‘Semigroup (Free cls a)’ • Relevant bindings include stimes :: b -> Free cls a -> Free cls a (bound at I.hs:10:10) | 10 | instance (forall xx. cls xx => Semigroup xx) => Semigroup (Free cls a) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 10:59:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 10:59:02 -0000 Subject: [GHC] #14832: QuantifiedConstraints: Strengthening context causes failure Message-ID: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> #14832: QuantifiedConstraints: Strengthening context causes failure -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With Simon's latest changes (ticket:14733#comment:9) this works: {{{#!hs {-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs #-} import Control.Category import Data.Kind import Data.Coerce data With cls a b where With :: cls a b => With cls a b type Coercion = With Coercible type Refl rel = (forall xx. rel xx xx :: Constraint) type Trans rel = (forall xx yy zz. (rel xx yy, rel yy zz) => rel xx zz :: Constraint) instance Refl rel => Category (With rel) where id = With (.) = undefined }}} But strengthening the context with `Trans rel`: {{{#!hs instance (Refl rel, Trans rel) => Category (With rel) where }}} causes it to fail {{{ GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( J.hs, interpreted ) J.hs:15:10: error: • Could not deduce: rel xx zz from the context: (Refl rel, Trans rel) bound by an instance declaration: forall k (rel :: k -> k -> Constraint). (Refl rel, Trans rel) => Category (With rel) at J.hs:15:10-53 or from: (rel xx yy, rel yy zz) bound by a quantified context at J.hs:15:10-53 • In the ambiguity check for an instance declaration To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the instance declaration for ‘Category (With rel)’ | 15 | instance (Refl rel, Trans rel) => Category (With rel) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ J.hs:15:10: error: • Could not deduce: rel xx xx from the context: (Refl rel, Trans rel) bound by an instance declaration: forall k (rel :: k -> k -> Constraint). (Refl rel, Trans rel) => Category (With rel) at J.hs:15:10-53 • In the ambiguity check for an instance declaration To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the instance declaration for ‘Category (With rel)’ | 15 | instance (Refl rel, Trans rel) => Category (With rel) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 11:00:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 11:00:27 -0000 Subject: [GHC] #14832: QuantifiedConstraints: Strengthening context causes failure In-Reply-To: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> References: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> Message-ID: <066.4e476a7326d691d0c5b9186188583ea5@haskell.org> #14832: QuantifiedConstraints: Strengthening context causes failure -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): The same happens if we add {{{#!hs instance (Refl rel, forall xx. xx) => Category (With rel) where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 11:04:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 11:04:47 -0000 Subject: [GHC] #14734: QuantifiedConstraints conflated with impredicative polymorphism? In-Reply-To: <051.b13ce9a287df15f46f4472a3cecc22de@haskell.org> References: <051.b13ce9a287df15f46f4472a3cecc22de@haskell.org> Message-ID: <066.79ab0e9882e62c956f52ddf94a84e058@haskell.org> #14734: QuantifiedConstraints conflated with impredicative polymorphism? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: invalid | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): It would be nice to directly write `type a :- b = Dict (a => b)` rather than {{{#!hs class (a => b) => Implies a b instance (a => b) => Implies a b type a :- b = Dict (Implies a b) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 11:09:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 11:09:51 -0000 Subject: [GHC] #14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)? Message-ID: <051.a778d1e6d6328a1b4ad713bf62d01c81@haskell.org> #14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs #-} import Data.Kind data Dict c where Dict :: c => Dict c class (a => b) => Implies a b instance (a => b) => Implies a b type a :- b = Dict (Implies a b) iota :: (Implies () a) :- a iota = Dict }}} GHC claims that it can't deduce `(() :: Constraint)` :) {{{ GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/H.hs, interpreted ) /tmp/H.hs:14:8: error: • Could not deduce () :: Constraint arising from a use of ‘Dict’ from the context: Implies () :: Constraint a bound by a quantified context at /tmp/H.hs:1:1 Possible fix: add () :: Constraint to the context of the type signature for: iota :: forall (a :: Constraint). Implies () :: Constraint a :- a • In the expression: Dict In an equation for ‘iota’: iota = Dict | 14 | iota = Dict | ^^^^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 11:26:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 11:26:38 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.5e078acdd5a0753124be4c2ced48cdc6@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kcsongor): * cc: kcsongor (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 11:30:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 11:30:49 -0000 Subject: [GHC] #14733: Won't use (forall xx. f xx) with -XQuantifiedConstraints In-Reply-To: <051.d6dd7c53fb2316d2a32445d192b9d697@haskell.org> References: <051.d6dd7c53fb2316d2a32445d192b9d697@haskell.org> Message-ID: <066.5f0ea536f321c60dbac17d7a5a0f9b67@haskell.org> #14733: Won't use (forall xx. f xx) with -XQuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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): Great! Keep identifying the kinks; it's extremely helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 11:33:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 11:33:26 -0000 Subject: [GHC] #14831: QuantifiedConstraints: Odd superclass constraint In-Reply-To: <051.631b3f4dec55319ae6028526fc90fcb8@haskell.org> References: <051.631b3f4dec55319ae6028526fc90fcb8@haskell.org> Message-ID: <066.0ea08964f3417020349fd2ceca1eab59@haskell.org> #14831: QuantifiedConstraints: Odd superclass constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): Looks like a bug -- will investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 11:40:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 11:40:38 -0000 Subject: [GHC] #14832: QuantifiedConstraints: Strengthening context causes failure In-Reply-To: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> References: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> Message-ID: <066.d9531ba258d91544f6f532e0eadc6fa1@haskell.org> #14832: QuantifiedConstraints: Strengthening context causes failure -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): GHC is very careful about picking instances. See http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #overlapping-instances, esp the bit about "all instances that unify". The constraint `rel xx xx` matches both `(Refl rel)` and `(Trans rel)`; but the (head of) the former is an instance of the (head of) the latter so it should win. At least with overlapping instances on. (There's no way to add an OVERLAPPING pragama to an individual quantified constraint -- yet anyway.) The constraint `rel xx zz` could (if `zz` was further instantiated) match`(Refl rel)`, so GHC refains from picking it. `IncoherentInstnaces` might help. In short, right now I'm being very conservative about ambiguity. Once we pick the "wrong" path there is no way back -- GHC does no backtracking. I'm inclined to park this one until we have the basics nailed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 12:05:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 12:05:11 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.8dabad8a630d9d66040c82c9024a562d@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 12:30:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 12:30:55 -0000 Subject: [GHC] #14564: CAF isn't floated In-Reply-To: <050.1af4937b5006defb6915274137e1c026@haskell.org> References: <050.1af4937b5006defb6915274137e1c026@haskell.org> Message-ID: <065.700bb5e56f11e1a5a5701d43ed17a26d@haskell.org> #14564: CAF isn't floated -------------------------------------+------------------------------------- Reporter: neil.mayhew | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14519 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 12:35:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 12:35:29 -0000 Subject: [GHC] #14564: CAF isn't floated In-Reply-To: <050.1af4937b5006defb6915274137e1c026@haskell.org> References: <050.1af4937b5006defb6915274137e1c026@haskell.org> Message-ID: <065.f14a70724a819b8d9211287492db67d9@haskell.org> #14564: CAF isn't floated -------------------------------------+------------------------------------- Reporter: neil.mayhew | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14519 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Possibly related (I didn't have time to fully dive into it): ''reddit - I wrote a program that runs about 10 times faster interpreted than compiled. Anybody know what's going on here?'' - https://www.reddit.com/r/haskell/comments/7yh8ar/i_wrote_a_program_that_runs_about_10_times_faster/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 13:09:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 13:09:06 -0000 Subject: [GHC] #14824: automatically select instance In-Reply-To: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> References: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> Message-ID: <059.0e4e594f072e88848e3521e173718ead@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 AntC): Perhaps (I'm just guessing) when you say > x0 x1 x2 x3 are Types. You mean not those are Types, but those are type ''variables''? Are you getting error messages? What are they? What flag settings do you have? (Have you set `OverlappingInstances`?) When you say > I can't write `a -> b`. ''Where'' can't you write that? Please give the full code; and the error messages. So far I can't see any "new feature" you're requesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 13:41:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 13:41:17 -0000 Subject: [GHC] #14824: automatically select instance In-Reply-To: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> References: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> Message-ID: <059.af9bbea55fd52922bdd457a6012e6d2d@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by zaoqi: Old description: > There is > {{{#!hs > class C a b where m :: [a] -> b > instance C x0 x0 > instance C x1 x2 > instance C x0 x3 > }}} > x0 x1 x2 x3 are Types. > FunctionalDependencies can't work. New description: There is {{{#!hs class C a b where m :: [a] -> b instance C X0 X0 instance C X1 X2 instance C X0 X3 }}} FunctionalDependencies can't work. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 13:42:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 13:42:36 -0000 Subject: [GHC] #13773: Types are not normalized in instance declarations In-Reply-To: <047.b99d4e95d0428b43aa3236e584c6e7ac@haskell.org> References: <047.b99d4e95d0428b43aa3236e584c6e7ac@haskell.org> Message-ID: <062.a94682e67dd908e947e433501df06eb7@haskell.org> #13773: Types are not normalized in instance declarations -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chshersh): I actually encountered complex use case and find this issue annoying. I'm working on library for type-safe time-units which are represented using type level rational numbers. See example here: * https://github.com/serokell/o-clock/blob/dd5026264c667feee49e2b70396a170c87470c05/src/Time/Units.hs#L89-L99 And here what I need to write in order to implement nice and pretty show instance for those time units: * https://github.com/serokell/o-clock/blob/dd5026264c667feee49e2b70396a170c87470c05/src/Time/Units.hs#L123-L136 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 13:45:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 13:45:55 -0000 Subject: [GHC] #14824: automatically select instance In-Reply-To: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> References: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> Message-ID: <059.f96ece02816c0b26491c1e1c5d4391d7@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by zaoqi: Old description: > There is > {{{#!hs > class C a b where m :: [a] -> b > instance C X0 X0 > instance C X1 X2 > instance C X0 X3 > }}} > FunctionalDependencies can't work. New description: There is {{{#!hs {-# LANGUAGE OverlappingInstances, MultiParamTypeClasses #-} data X0 = X0 deriving Show data X1 = X1 deriving Show data X2 = X2 deriving Show data X3 = X3 deriving Show class C a b where m :: [a] -> b instance C X0 X0 where m _ = X0 instance C X1 X2 where m _ = X2 instance C X0 X3 where m _ = X3 }}} X0 X1 X2 X3 is 4 types in real program. FunctionalDependencies can't work. {{{ *Main> m [X1] :6:1: error: • Ambiguous type variable ‘a0’ arising from a use of ‘print’ prevents the constraint ‘(Show a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ instance [overlap ok] [safe] Show X0 -- Defined at a.hs:2:23 ...plus 26 others ...plus 11 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In a stmt of an interactive GHCi command: print it }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 13:47:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 13:47:07 -0000 Subject: [GHC] #14824: automatically select instance In-Reply-To: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> References: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> Message-ID: <059.0041db5dc3dcef681b06c79f308afbb1@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 zaoqi): Replying to [comment:5 AntC]: > Perhaps (I'm just guessing) when you say > > > x0 x1 x2 x3 are Types. > > You mean not those are Types, but those are type ''variables''? > > Are you getting error messages? What are they? What flag settings do you have? (Have you set `OverlappingInstances`?) > > When you say > > > I can't write `a -> b`. > > ''Where'' can't you write that? Please give the full code; and the error messages. > > So far I can't see any "new feature" you're requesting. I edited. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 13:53:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 13:53:38 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.a9dacb1799e6542f13e7eefda8f04d1b@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ok, I think I have a bit more info on this, and a better workaround. For me the crash happened here: {{{ (gdb) disassemble 0x0000000040792900,0x0000000040792910 Dump of assembler code from 0x40792900 to 0x40792910: 0x0000000040792900: mov 0x10(%rbp),%rax 0x0000000040792904: mov %rbx,%rcx 0x0000000040792907: and $0x7,%ecx => 0x000000004079290a: jmpq *0x403ff568(,%rcx,8) }}} and the memory at 0x403ff568 looks bogus. By using `+RTS -Dl` and digging through the logs, correlating this with `objdump --reloc HSbase-4.11.0.0.o`, I got that this relocation is: {{{ 00000000004228cd R_X86_64_32S .rodata-0x0000000000451cd8 }}} which is utterly bogus: we should never have a negative offset into a section. The original object file, before it was squashed into `HSbase-4.11.0.0.o` has this: {{{ 0000000000000b3d R_X86_64_32S .rodata..LneLq }}} which is a sensible relocation to the unique section name `.rodata..LneLq`. Looks like something has gone wrong when we squashed the object files together to make `HSBase-4.11.0.0.o`. Indeed, if I take the command line to squash the object files and replace `ld.gold` with `ld`, then I get this relocation: {{{ 00000000004228cd R_X86_64_32S .rodata+0x000000000000e158 }}} which is much more sensible. And after doing that, the crashing program now works. So this suggests that the workaround should be to avoid using `ld.gold` for squashing objects together, I'll make a diff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 14:13:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 14:13:01 -0000 Subject: [GHC] #14826: Flatten data types extending other data types in STG In-Reply-To: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> References: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> Message-ID: <061.73bf76e35d584212edad163959896950@haskell.org> #14826: Flatten data types extending other data types in STG -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: 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): > Note that I am NOT re-using the data constructor for Foo (which would be tricky and confusing). Why not? In fact, with your desguaring, and #13861, we’d get that: {{{ data Result = Ok_A Int | OK_B Bool | OK_C C | NotOK Error f r = join j x = wimwam x True x in case r as b of OK_A n -> jump j b OK_B b -> jump j b OK_C -> jump j b NOtOK _ -> 0 }}} > I wonder if we could leverage pattern synonyms rather than have more built-in stuff. Yes, your encoding is all doable with pattern synonyms already: {{{ data Foo = A Int | B Bool | C -- we want: data Result = Ok !Foo | NotOK Error data Result = Ok_A Int | OK_B Bool | OK_C | NotOK Error pattern Ok :: Foo -> Result pattern Ok f <- ((\case Ok_A i -> Just (A i); OK_B b -> Just (B b); OK_C -> Just C; _ -> Nothing) -> Just f) where Ok = \case A i -> Ok_A i; B b -> OK_B b; C -> OK_C }}} or, if people feel bold (and until #13861 does this automatically) {{{ pattern Ok :: Foo -> Result pattern Ok f <- ((\case NotOK _ -> Nothing; foo -> Just (unsafeCoerce foo)) -> Just f) where Ok = unsafeCoerce }}} So since this is somewhat nicely possible, it makes sense for people to play around with either of these encodings using pattern synonyms, and let us know if they notice any gains. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 14:14:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 14:14:49 -0000 Subject: [GHC] #14098: Incorrect pattern match warning on nested GADTs In-Reply-To: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> References: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> Message-ID: <062.6c5a4437131ef56155b7ab131f39be3e@haskell.org> #14098: Incorrect pattern match warning on nested GADTs -------------------------------------+------------------------------------- Reporter: jmgrosen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11984 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To hammer home the fact that guards are the culprit, note that this problem also erroneously generates a warning: {{{#!hs {-# Language GADTs #-} {-# OPTIONS_GHC -Wall #-} data App f a where App :: f a -> App f (Maybe a) data Ty a where TBool :: Ty Bool TInt :: Ty Int data T f a where C :: T Ty (Maybe Bool) f :: T f a -> App f a -> () f C (App x) | TBool <- x = () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 14:37:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 14:37:53 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.9715f62270c475f7a51d9d21f826cbf2@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): After a bit of Googling around and chasing references I end up at this bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=22266 submitted by none other than Ben Gamari :) Which leads to #14291, which is almost certainly the same bug as this one. So there are a little collection of tickets here: * #14675 (This bug) narrowed down to ld.gold generating a bogus HSfoo.o * #14291, also narrowed down to ld.gold producing a bogus HSfoo.o * #14328, tracking the upstream bug in ld.gold -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 14:39:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 14:39:09 -0000 Subject: [GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array# In-Reply-To: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> References: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> Message-ID: <064.6a2e66dcc9caa72dd5854c4338f1d792@haskell.org> #14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by bgamari): For what it's worth, I wouldn't be opposed to breaking users of `GHC.Prim`; this module really is an internal implementation detail of the compiler and I think we would be unduly tying our hands by guaranteeing compatibility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 14:39:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 14:39:31 -0000 Subject: [GHC] #14328: ld.gold -r brokenness breaks SplitSections=YES builds In-Reply-To: <046.4964a55f6e0726ca18cbbd2bccaf25b7@haskell.org> References: <046.4964a55f6e0726ca18cbbd2bccaf25b7@haskell.org> Message-ID: <061.960e768a62a1479cee707191979b3f9f@haskell.org> #14328: ld.gold -r brokenness breaks SplitSections=YES builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14291 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): This looks like the final fix: https://sourceware.org/git/gitweb.cgi?p =binutils-gdb.git;a=commit;h=033bfb739b525703bfe23f151d09e9beee3a2afe -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 14:39:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 14:39:51 -0000 Subject: [GHC] #14328: ld.gold -r brokenness breaks SplitSections=YES builds In-Reply-To: <046.4964a55f6e0726ca18cbbd2bccaf25b7@haskell.org> References: <046.4964a55f6e0726ca18cbbd2bccaf25b7@haskell.org> Message-ID: <061.d85ab6511d7c8a10137a279eb2d0c20f@haskell.org> #14328: ld.gold -r brokenness breaks SplitSections=YES builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14291, 14675 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * blocking: 14291 => 14291, 14675 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 14:48:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 14:48:57 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.e5e5cb76c2d5a8e8d4a0b27d69adbe31@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D4431 * blockedby: 14328 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 14:50:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 14:50:19 -0000 Subject: [GHC] #14328: ld.gold -r brokenness breaks SplitSections=YES builds In-Reply-To: <046.4964a55f6e0726ca18cbbd2bccaf25b7@haskell.org> References: <046.4964a55f6e0726ca18cbbd2bccaf25b7@haskell.org> Message-ID: <061.d2f50513dbc9b72d2781e2198bfbc039@haskell.org> #14328: ld.gold -r brokenness breaks SplitSections=YES builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14291 Related Tickets: | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D4431 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 14:50:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 14:50:25 -0000 Subject: [GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array# In-Reply-To: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> References: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> Message-ID: <064.6e5706c252f201e8c69d29edd1f98edd@haskell.org> #14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by andrewthad): Agreed. I think that requiring people to import `GHC.Exts` instead of `GHC.Prim` is acceptable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 14:50:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 14:50:53 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp way when split sections is enabled In-Reply-To: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> References: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> Message-ID: <061.3210b4c7e42308cdc9c90036046d8346@haskell.org> #14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14328 | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D4431 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 14:52:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 14:52:24 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.fc324aa9326cd57082618baeeef7ffe6@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmmm, indeed comment:22 does suggest that this is another manifestation of #14291. Thanks for that, simonmar! I do wish we had a proper autoconf check for the `ld.gold` brokenness, but oh well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 15:00:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 15:00:37 -0000 Subject: [GHC] #14834: Executable have problems with DWARF debug information Message-ID: <045.869f13e723668fe5f6114e93abdf8ce6@haskell.org> #14834: Executable have problems with DWARF debug information -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Debugging) | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We're compiling production code with GHC 8.2.2 under Windows 10 (i.e. Mingw64). A crash occured during one of our FFI bindings and we wanted to use latest GHC debugging functionallity to find the problem faster. We used a tool cv2pdb to convert DWARF information into PDB, but we hit a crash with the tool - [https://github.com/rainers/cv2pdb/issues/23] In response, the tool author brought us back a output of a problem in objdump tool over our executable: {{{ c:\tmp\cv\crash>C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe -W crash.exe >objdump C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: Encoded value extends past end of section C:\l\d\GDC-2.068\bin\x86_64-unknown-linux-gnu-objdump.exe: Warning: There is a hole [0x682a - 0x6867] in .debug_loc section. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 15:16:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 15:16:29 -0000 Subject: [GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler. In-Reply-To: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> References: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> Message-ID: <062.f5185e8488574fa426b26119a7b306c4@haskell.org> #14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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:D4316 Wiki Page: | Phab:D4324 Phab:D4327 -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 15:40:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 15:40:30 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.38654f6d91a125e75d21e035ffed8c68@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Here is some data about `x2n1`: {{{ master loopification flags 1017640 1017688 -O 1017640 1017688 -O -fliberate-case 378248 378296 -O -fspec-constr 378248 698264 -O -fspec-constr -fliberate-case (== -O2) }}} So liberate case + loopification breaks parts of spec-constr… -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 15:56:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 15:56:11 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.cb0d7e2920e39d4192f845c463d05d4f@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Is it possible that this happens (using the examle from the top of `SpecConstr`)? Before: {{{ Rec { drop n xs = case xs of [] -> [] (y:ys) -> case n of I# n# -> case n# of 0 -> [] _ -> drop (I# (n# -# 1#)) xs } }}} here SpecConstr kicks, creating a rule and specializing, yielding the nice {{{ Rec { $sdrop n# xs = case xs of [] -> [] (y:ys) -> case n# of 0 -> [] _ -> $sdrop (n# -# 1#) xs } RULE drop (I# n) xs = $sdrop n xs }}} But with loopification, we start with {{{ drop n xs = joinrec j n xs = case xs of [] -> [] (y:ys) -> case n of I# n# -> case n# of 0 -> [] _ -> call j (I# (n# -# 1#)) xs in j n xs }}} (yay!), and now we liberate case can do its work, and we get (I think) {{{ drop n xs = case xs of [] -> [] (y:ys) -> case n of I# n# -> joinrec j n xs = case xs of [] -> [] (y:ys) -> case n# of 0 -> [] _ -> call j (I# (n# -# 1#)) xs in j n (y:ys) }}} but now spec-constr no longer kicks! It’s comments say (abbreviated): > So we look for a self-recursive function AND at a recursive call, > one or more parameters is an explicit constructor application AND > that same parameter is scrutinised by a case somewhere in the RHS > of the function This used to be true for the original, recursive `drop`, but not for the loopified: `drop` is not recursive, `j` does not scrutinize the parameter. So we don’t create a specialization for `drop`, causing extra allocations when there are calls to `drop (I$ n)` somewhere. Now in some cases this might be ok, namely when we can inline `drop` (which is no longer recursive). But `drop` contains this big `joinrec`, so it’s too big to be inlined? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 16:07:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 16:07:28 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.f00637863214afeb8bebee602fb1e4f5@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > now we liberate case can do its work Are you sure? I don't think liberate case applies here, though I have not tried it out. > ow spec-constr no longer kicks! Why not? It should apply to the recursive function j. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 16:10:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 16:10:54 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.bd37f8bcb5e690870c2ddc28492b06d0@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): I am trying it out right now… will report back. > Are you sure? I don't think liberate case applies here, though I have not tried it out. Hmm, you are right, this example does not work. `n` is not a free variable variable of the recursive function. I will try to construct a better example (or find out what really happens with `x2n1`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 16:15:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 16:15:47 -0000 Subject: [GHC] #14564: CAF isn't floated In-Reply-To: <050.1af4937b5006defb6915274137e1c026@haskell.org> References: <050.1af4937b5006defb6915274137e1c026@haskell.org> Message-ID: <065.49612f8e06fa7e50071c0c76bd585b8b@haskell.org> #14564: CAF isn't floated -------------------------------------+------------------------------------- Reporter: neil.mayhew | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14519 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This Reddit post is the subject of #14827 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 16:17:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 16:17:50 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.2b1ba2c4d40ea2bd818c44805756bfa7@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ersetzen): [https://gist.github.com/Tarmean/f97a6463aaad8069416cc6810e8ba4e5 Here are both versions and the corresponding dump-simpl output] (only the last line is changed). I had to rewrite it somewhat because the original created a 10k line core function. This version created ~450 lines of core when I compiled it with {{{-O2 -ddump-simpl -ddump-stg -dsuppress-uniques -dsuppress-all -fno- liberate-case -ddump-to-file -fforce-recomp -fno-spec-constr -ticky -ticky-LNE}}}, which admittedly is a bit of a mouthful. I think ticky output first is probably simplest? Without inline pragma: {{{ ************************************************** Entries Alloc Alloc'd Non-void Arguments STG Name -------------------------------------------------------------------------------- 15847 380328 0 0 lvl2{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in s4DX 302632 24210560 0 0 lvl5{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in s4ER 63931922 0 0 1 i $wcandidateMatch{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in s4ER 135874515 0 0 0 $j{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in s4ER 136224692 0 0 1 i $wscan{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (fun) in s4Eu 21810147 36418408 0 3 iwi $wbuildTable{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in s4E5 63392 0 0 2 SC snoc'{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (fun) 366024 0 0 1 L checkAll{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in s4DX 142632 4057088 0 1 L go1{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (fun) in s4DR 16029 1014272 0 1 L go{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (fun) in rj 182 0 0 2 LS go1{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in rj 1 16 0 1 L longestCommonSubstring{v} (fun) 4 96 0 0 main1{v} (fun) 1 0 0 0 main4{v} (fun) 1 0 0 0 main{v} (fun) ************************************************** }}} With inline pragma: {{{ ************************************************** Entries Alloc Alloc'd Non-void Arguments STG Name -------------------------------------------------------------------------------- 15847 380328 0 0 lvl2{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in s4Ho 302632 24210560 0 0 lvl3{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in s4Ih 63931922 0 0 1 i $wcandidateMatch{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in s4Ih 135874515 0 0 0 $j{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in s4Ih 8551263604 0 0 3 iwi $wbuildTable{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (fun) in s4Hw 136224692 0 0 1 i $wscan{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (fun) in s4Hw 63392 0 0 2 SC snoc'{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (fun) 366024 47624072 0 1 L checkAll{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in s4Ho 142632 4057088 0 1 L go1{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (fun) in s4Hi 16029 1014272 0 1 L go{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (fun) in rj 182 0 0 2 LS go1{v} (Profile-0.1.0.0-95VECWVHYo03uC96ITYgBw:Lib) (LNE) in rj 1 16 0 1 L longestCommonSubstring{v} (fun) 4 96 0 0 main1{v} (fun) 1 0 0 0 main4{v} (fun) 1 0 0 0 main{v} (fun) ************************************************** }}} Removing the inline pragma moves the result allocation from $wscan to $wbuildTable and we don't have to allocate the $wbuildTable closure since it's a join point. More drastically, the $wbuildTable entries go down from 8551263604 to 21810147! Perf also shows that in the INLINE version the shiftLeft in $wbuildTable is the hottest instruction by quite some margin. [https://gist.github.com/Tarmean/0afe4d3a515c7d47cc526698180d1578 Finally a diff between the two dump-simpl outputs]. Notably all values that are floated out are unlifted so this doesn't save any heap allocations. Of those only {{{ lvl4 = +# dt2 1# }}} and the $wbuildTable result are used multiple times. Sorry that this got a bit long. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 17:03:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 17:03:20 -0000 Subject: [GHC] #14328: ld.gold -r brokenness breaks SplitSections=YES builds In-Reply-To: <046.4964a55f6e0726ca18cbbd2bccaf25b7@haskell.org> References: <046.4964a55f6e0726ca18cbbd2bccaf25b7@haskell.org> Message-ID: <061.ad8860e7de53887551061d53c6592892@haskell.org> #14328: ld.gold -r brokenness breaks SplitSections=YES builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14291 Related Tickets: | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"0a3629af36e89de73b7012c726fd533c4c5460fb/ghc" 0a3629af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0a3629af36e89de73b7012c726fd533c4c5460fb" Don't use ld.gold when building libraries for GHCi Summary: ld.gold is buggy when using -r and a linker script. See upstream bug https://sourceware.org/bugzilla/show_bug.cgi?id=22266 This has been causing various brokenness for the GHC runtime linker, where we load these broken object files. Test Plan: Test program from #14675 Reviewers: bgamari, RyanGlScott, alpmestan, hvr, erikd Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #14328, #14675, #14291 Differential Revision: https://phabricator.haskell.org/D4431 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 17:03:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 17:03:20 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp way when split sections is enabled In-Reply-To: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> References: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> Message-ID: <061.70e771ae936bee78ee93bcf473c9cce0@haskell.org> #14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14328 | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"0a3629af36e89de73b7012c726fd533c4c5460fb/ghc" 0a3629af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0a3629af36e89de73b7012c726fd533c4c5460fb" Don't use ld.gold when building libraries for GHCi Summary: ld.gold is buggy when using -r and a linker script. See upstream bug https://sourceware.org/bugzilla/show_bug.cgi?id=22266 This has been causing various brokenness for the GHC runtime linker, where we load these broken object files. Test Plan: Test program from #14675 Reviewers: bgamari, RyanGlScott, alpmestan, hvr, erikd Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #14328, #14675, #14291 Differential Revision: https://phabricator.haskell.org/D4431 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 17:03:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 17:03:20 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.c76ed0cd9eca6a05622974bb0e732061@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"0a3629af36e89de73b7012c726fd533c4c5460fb/ghc" 0a3629af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0a3629af36e89de73b7012c726fd533c4c5460fb" Don't use ld.gold when building libraries for GHCi Summary: ld.gold is buggy when using -r and a linker script. See upstream bug https://sourceware.org/bugzilla/show_bug.cgi?id=22266 This has been causing various brokenness for the GHC runtime linker, where we load these broken object files. Test Plan: Test program from #14675 Reviewers: bgamari, RyanGlScott, alpmestan, hvr, erikd Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #14328, #14675, #14291 Differential Revision: https://phabricator.haskell.org/D4431 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 17:04:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 17:04:00 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.9cc4b839ec633bf4753f8ef7014170ed@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: merge Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 17:04:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 17:04:57 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp way when split sections is enabled In-Reply-To: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> References: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> Message-ID: <061.3e80b9eaefebf3d5cecf4d1f64740f3c@haskell.org> #14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14328 | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 17:12:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 17:12:55 -0000 Subject: [GHC] #14824: automatically select instance In-Reply-To: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> References: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> Message-ID: <059.7f6900817a7382267e4065f5fac2a5c2@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 AntC): Thank you zaoqi. The ticket is now very different to your first post. GHC is behaving as I would expect. It doesn't know which instance of `C` to select for the invocation of `m`. That's because it doesn't know the type of the result for `m [X1]`. You could go: {{{ *Main> m [X1] :: X2 }}} And get result `X2`, because GHC can select `instance C X1 X2`. That's similar to `read "5" :: Int` vs `read "5" :: Float` to disambiguate number formats. GHC does not automatically select an instance just because it seems to be the only one that fits: maybe there is another instance declared in another module that fits just as well. I could tell you about `FunctionalDependencies` combined with `OverlappingInstances` and `UndecidableInstances`. But first consider whether Closed `TypeFamilies` will provide a better approach. I can't see any fault. I can't see any "new feature" needed. Please do not use Trac tickets for help requests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 17:36:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 17:36:50 -0000 Subject: [GHC] #13773: Types are not normalized in instance declarations In-Reply-To: <047.b99d4e95d0428b43aa3236e584c6e7ac@haskell.org> References: <047.b99d4e95d0428b43aa3236e584c6e7ac@haskell.org> Message-ID: <062.42e6fbf290c3794bbad30bcaff4a5658@haskell.org> #13773: Types are not normalized in instance declarations -------------------------------------+------------------------------------- Reporter: augustss | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Someone make a proposal, then! :) (My resistance to this has softened somewhat over time, for what that's worth.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 17:39:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 17:39:56 -0000 Subject: [GHC] #14835: QuantifiedConstraints: Can't deduce "(a, b)" from "a" and "b" Message-ID: <051.57aa3dd69186275a0a16899ee990e8c4@haskell.org> #14835: QuantifiedConstraints: Can't deduce "(a, b)" from "a" and "b" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs, LiberalTypeSynonyms, TypeOperators, MultiParamTypeClasses, FlexibleInstances #-} data Dict c where Dict :: c => Dict c infixr |- class (a => b) => (a |- b) instance (a => b) => (a |- b) type a :- b = Dict (a |- b) class ((a, b) => c) => Curried a b c instance ((a, b) => c) => Curried a b c curryC :: forall a b c. ((a, b) |- c) :- (a |- b |- c) curryC = Dict }}} This fails with {{{ GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Test.hs, interpreted ) /tmp/Test.hs:16:10: error: • Could not deduce (a, b) arising from a use of ‘Dict’ from the context: (a, b) |- c bound by a quantified context at /tmp/Test.hs:1:1 or from: a bound by a quantified context at /tmp/Test.hs:1:1 or from: b bound by a quantified context at /tmp/Test.hs:1:1 Possible fix: add (a, b) to the context of the type signature for: curryC :: forall (a :: Constraint) (b :: Constraint) (c :: Constraint). ((a, b) |- c) :- (a |- (b |- c)) • In the expression: Dict In an equation for ‘curryC’: curryC = Dict | 16 | curryC = Dict | ^^^^ Failed, no modules loaded. }}} but it works by changing the type of `curryC`: {{{#!hs curryC :: forall a b c. Curried a b c :- (a |- b |- c) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 17:49:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 17:49:47 -0000 Subject: [GHC] #14832: QuantifiedConstraints: Adding to the context causes failure (was: QuantifiedConstraints: Strengthening context causes failure) In-Reply-To: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> References: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> Message-ID: <066.681a05ae3533fad2926d4c86cf4b99a2@haskell.org> #14832: QuantifiedConstraints: Adding to the context causes failure -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 18:04:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 18:04:50 -0000 Subject: [GHC] #14832: QuantifiedConstraints: Adding to the context causes failure In-Reply-To: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> References: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> Message-ID: <066.734394eda5f07040caa7717650cc28d9@haskell.org> #14832: QuantifiedConstraints: Adding to the context causes failure -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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:2 simonpj]: > I'm inclined to park this one until we have the basics nailed. That's fine, this isn't (doesn't seem to be) a show stopper. In this case I can encode these properties as a type class (`(:-)`-enriched categories) {{{#!hs type ConstraintCat ob = ob -> ob -> Constraint class ConstraintCategory (cat::ConstraintCat ob) where cid :: () :- cat a a comp :: (cat a b, cat b c) :- cat a c instance CCategory cat => Category (With cat) where id :: forall a. With cat a a id = case cid :: () :- cat a a of Dict -> With (.) :: forall b c a. With cat b c -> With cat a b -> With cat a c With . With = case ccomp :: (cat a b, cat b c) :- cat a c of Dict -> With }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 18:12:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 18:12:45 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.95ff3eee4c8592791db96fd8928993f6@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > I am trying it out right now… will report back. Ok, it is independent of liberate case, but otherwise the result is as I described: Without loopification we get a specialization for `drop`, with loopification we do not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 18:29:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 18:29:13 -0000 Subject: [GHC] #14836: GHC fails to infer implied superclass constraint Message-ID: <047.4454dcfd9885f0bad0681f0078238bc0@haskell.org> #14836: GHC fails to infer implied superclass constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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 should compile, but does not. {{{ {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} module Bug where class (Monad m) => RequiresMonad m where class (Monad m) => ImpliesMonad m where instance (ImpliesMonad m) => RequiresMonad m where }}} The basic idea is that I put the constraint `ImpliesMonad m` on the `RequiresMonad` instance, which does in fact imply `Monad m`. However, GHC complains: {{{ • Could not deduce (Monad m) arising from the superclasses of an instance declaration from the context: ImpliesMonad m bound by the instance declaration at Bug.hs:9:10-44 Possible fix: add (Monad m) to the context of the instance declaration • In the instance declaration for ‘RequiresMonad m’ }}} Of course, GHC is perfectly happy if I replace the instance constraint `ImpliesMonad m` with `Monad m`. Possibly related to #10338 or #11948. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 18:43:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 18:43:27 -0000 Subject: [GHC] #14836: GHC fails to infer implied superclass constraint In-Reply-To: <047.4454dcfd9885f0bad0681f0078238bc0@haskell.org> References: <047.4454dcfd9885f0bad0681f0078238bc0@haskell.org> Message-ID: <062.a539153afb397ed4240cd5ee24a8dac3@haskell.org> #14836: GHC fails to infer implied superclass constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Oddly, if I involve `MultiParamTypeClasses`, I can make this work in some cases, but GHC refuses others: {{{ {-# LANGUAGE FlexibleContexts, FlexibleInstances, MultiParamTypeClasses, UndecidableInstances #-} module Bug where import Control.Monad.Reader import Control.Monad.IO.Class class (Monad m) => Message msg m where class (Monad m) => ImpliesMonad m where data Foo --instance (ImpliesMonad m) => Message Foo m where -- compiles --instance (MonadIO m) => Message Foo m where -- compiles --instance (MonadReader Bool m) => Message Foo m where -- does NOT compile }}} I've defined three similar instances above. The first two instances are accepted by GHC (as, in my opinion, they should be), but the third instance is reject (`could not deduce (Monad m)`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 18:46:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 18:46:09 -0000 Subject: [GHC] #14836: GHC fails to infer implied superclass constraint In-Reply-To: <047.4454dcfd9885f0bad0681f0078238bc0@haskell.org> References: <047.4454dcfd9885f0bad0681f0078238bc0@haskell.org> Message-ID: <062.dd54cef083a85344051ba7f92dc532fe@haskell.org> #14836: GHC fails to infer implied superclass constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14417 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14417 Comment: This is expected behavior. From the [https://downloads.haskell.org/~ghc/8.0.1/docs/html/users_guide/8.0.1-notes.html#language GHC 8.0.1 release notes]: > The compiler is now a bit more conservative in solving constraints previously provided by superclasses (see Trac #11762). For instance, consider this program,: > > {{{#!hs > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE UndecidableInstances #-} > > class Super a > class (Super a) => Left a > class (Super a) => Right a > instance (Left a) => Right a -- this is now an error > }}} > > GHC now rejects this instance, claiming it cannot deduce the `Super a` superclass constraint of the `Right` typeclass. This stands in contrast to previous releases, which would accept this declaration, using the `Super a` constraint implied by the `Left a` constraint. To fix this simply add the needed superclass constraint explicitly, > > {{{#!hs > instance (Left a, Super a) => Right a > }}} In other words, it's a limitation that was imposed after the introduction of `UndecidableSuperClasses`. So from GHC's perspective, the correct thing to do here is to use this instance declaration instead: {{{#!hs instance (Monad m) => RequiresMonad m where }}} Closing as a duplicate of #14417. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 18:49:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 18:49:51 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.0b1d857cfbe123cf1765635a7e8c57c9@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): OK, that didn't work, but for reasons I didn't expect. If we apply that change, suddenly some bindings get *worse* *strictness* annotations, although it should only make for *less conservative* (possibly unsound) *usage* annotations, as `reuseEnv` will only affect usage information. It turns out that this is due to the interaction between the lazy fv hack and the fix-pointing algorithm. An example is adapted from T876: {{{ foo :: Int -> Int foo n = sum [ length [i..n] | i <- [1..n] ] main = print (foo 100) }}} The variant that does get rid of the call to `reuseEnv` altogether will produce something like this code: {{{ foo = \ (n_aYV [Dmd=] :: Int) -> joinrec { go_a2c3 [Occ=LoopBreaker] :: [Int] -> Int -> Int [LclId[JoinId(2)], Arity=2, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [30 20] 137 0}] go_a2c3 (ds_a2c4 [Dmd=] :: [Int]) (eta_B1 [Dmd=] :: Int) = case ds_a2c4 of { [] -> eta_B1; : y_a2c9 [Dmd=] ys_a2ca -> jump go_a2c3 ys_a2ca (case eta_B1 of { GHC.Types.I# x_a3ii [Dmd=] -> case y_a2c9 of { GHC.Types.I# x_a3jq [Dmd=] -> case n_aYV of { GHC.Types.I# y_a3jz [Dmd=] -> case GHC.List.$wlenAcc @ Int (GHC.Enum.eftInt x_a3jq y_a3jz) 0# of ww2_a4JP [Dmd=] { __DEFAULT -> GHC.Types.I# (GHC.Prim.+# x_a3ii ww2_a4JP) } } } }) }; } in jump go_a2c3 (case n_aYV of { GHC.Types.I# y_a3jz [Dmd=] -> GHC.Enum.eftInt 1# y_a3jz }) lvl_s4Jd }}} Note that `go` is clearly strict in `n` (that's what HEAD finds out), but this variant is too conservative. Some printfs revealed that's due to abortion of fix-pointing. This is a log for the `lazy_fv`s and the `sig_fv` envs: {{{ dmdAnalRhsLetDown go_a2c3 [] [] dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ] dmdAnalRhsLetDown go_a2c3 [aYV :-> ] [] dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ] dmdAnalRhsLetDown go_a2c3 [aYV :-> ] [] dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ] dmdAnalRhsLetDown go_a2c3 [aYV :-> ] [] dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ] dmdAnalRhsLetDown go_a2c3 [aYV :-> ] [] dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ] dmdAnalRhsLetDown go_a2c3 [] [aYV :-> ] dmdAnalRhsLetDown foo [] [] }}} It flip flops between putting `n`s demand into the `sig_fv` and the `lazy_fv`. That's decided by `isWeakDmd`, which amounts to checking if the demand is equivalent to `` and will thus no longer change during fix- pointing. After the initial iteration, we find that `n` is called once and gets tagged onto the strictness signature. The second iteration sees that `n` is called an additional time, demand ``. This means it no longer has an interesting demand and goes into `lazy_fv`. But here's the culprit: The fix-pointer only compares the strictness signature for changes! It will start a third iteration, completely forget about any `lazy_fv` and flop back to the state of the first iteration. There's two ways out: 1. Also check `lazy_fvs` for changes. This is the thing we wanted to avoid in the first place. Also this is LetUp in disguise, which purposefully isn't equipped to deal with recursive bindings. 2. Don't check `lazy_fvs`. These are outer bindings only, so they don't actually need to play a role in fix-pointing. Also everything in `lazy_fvs` is already top-ish, so it suffices to check if a variable in a prior signature is now part of `lazy_fvs` and exclude them from the check. I'll try 2. tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 20:07:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 20:07:07 -0000 Subject: [GHC] #14837: Semigroup and Monoid instances for ST Message-ID: <049.7070815cfee9f2dc66e62515fc16d658@haskell.org> #14837: Semigroup and Monoid instances for ST -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Keywords: base | 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 `base-4.9`, a `Monoid` instance for `IO` was introduced. I would like to propose adding a similar instance for `ST`. This should be even less controversial since there is only one meaningful `Monoid` instance for `ST` (it lacks the exception-catching facilities of `IO`). The behavior of the `Semigroup` and `Monoid` instances would need to match this: {{{ instance Monoid a => Monoid (ST s a) where mappend = liftA2 mappend mempty = pure mempty }}} This would let me use `fold` and `foldMap` over `ST` computations, which would occasionally be useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 20:27:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 20:27:11 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.390aca9afd89dc83880a99135291a95b@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: sjakobi Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4433 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * cc: sjakobi (removed) * owner: (none) => sjakobi * differential: => Phab:D4433 Comment: I have implemented a first primop which was much less code than I had expected. Please review the attached Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 20:33:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 20:33:55 -0000 Subject: [GHC] #14098: Incorrect pattern match warning on nested GADTs In-Reply-To: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> References: <047.9af3deedeaeda4254147ac374e749c5f@haskell.org> Message-ID: <062.c809c366f31bd9c39a94bb38a25e77d3@haskell.org> #14098: Incorrect pattern match warning on nested GADTs -------------------------------------+------------------------------------- Reporter: jmgrosen | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11984 | Differential Rev(s): Phab:D4434 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4434 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 20:34:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 20:34:07 -0000 Subject: [GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy In-Reply-To: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> References: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> Message-ID: <062.fe197aca8e9ca035e563da759aaff3b2@haskell.org> #11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14098 | Differential Rev(s): Phab:D4434 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4434 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 20:34:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 20:34:24 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.b694be4b3cd7a189ea90243736335ee5@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: sjakobi Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vagarenko): > Can we instead have primops which take both an offset measured in bytes and an offset measured in terms of the type? > {{{#!hs > indexTYPEArray# :: ByteArray# -> Int# {-byte offset-} -> Int# {-type offset-} -> TYPE# > readTYPEArray# :: MutableByteArray# s -> Int# {-byte offset-} -> Int# {-type offset-} -> State# s -> (#State# s, TYPE##) > writeTYPEArray# :: MutableByteArray# s -> Int# {-byte offset-} -> Int# {-type offset-} -> TYPE# -> State# s -> State# s > > indexTYPEOffAddr# :: Addr# -> Int# {-byte offset-} -> Int# {-type offset-} -> TYPE > readTYPEOffAddr# :: Addr# -> Int# {-byte offset-} -> Int# {-type offset-} -> State# s -> (#State# s, TYPE ##) > writeTYPEOffAddr# :: Addr# -> Int# {-byte offset-} -> Int# {-type offset-} -> TYPE -> State# s -> State# s > }}} > > All of these go through the `mkBasicIndexed{Read,Write}` functions, which take both a byte offset and a type offset, so it seems reasonable to expose that. I'm confused. Why do you want this? Isn't `byte offset` here is just `type offset * sizeof type`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 20:36:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 20:36:10 -0000 Subject: [GHC] #14837: Semigroup and Monoid instances for ST In-Reply-To: <049.7070815cfee9f2dc66e62515fc16d658@haskell.org> References: <049.7070815cfee9f2dc66e62515fc16d658@haskell.org> Message-ID: <064.562c6c24b91cf65f68a7134d5e8fc7f0@haskell.org> #14837: Semigroup and Monoid instances for ST -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: base Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14107 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14107 Comment: Already done in 441c52de0621ac68a2248cf691b4de31fba48a34, as it turns out, so these instances will debut in GHC 8.4.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 20:37:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 20:37:33 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe In-Reply-To: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> References: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> Message-ID: <057.179929e28a4b6d8e96ad3f045a3eb18c@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): > we don't have the information we really need, which is "did the object file change". Perhaps we just need to be more clever and store hashes of object files as dependencies when we're using TH @simonmar Exactly. I thought the same, and implemented that a couple days ago as a work-in-progress: https://github.com/ghc/ghc/compare/ghc-8.2.1-release...nh2:ghc-8.2.1 -release-nonrecursive-recompBecause-TH?expand=1 Would be nice if you could have a look, I can then work towards finishing that. In my preliminary experiments, this reduced the occurrance of the `[TH]` reason from 40 modules to 8 in a 150-module project. However, the big problem is still #12935, non-deterministic `.o` files. If they are nondeterministic, they will destroy object file hashing based recompilation avoidance. However, once it works, I think it will be great: With `-O0` I get (nondeterministically) a reduction from 40 modules to 1 module + relink. So I took a shot at that problem as well (making object files deterministic), taking a different approach than what was taken so far (instead of making uniques not appear in outputs, I'm trying to genrate them deterministically). In my small example it works up to a single difference in the final binary, but more work is needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 21:28:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 21:28:07 -0000 Subject: [GHC] #14838: missing "incomplete-patterns" warning for TH-generated functions Message-ID: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.2 Haskell | 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: -------------------------------------+------------------------------------- "incomplete-patterns" warnings are generated for TH-generated case expressions, but not for TH-generated functions, so the behaviour is inconsistent. For example: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Lib where import Language.Haskell.TH qIncompleteCase :: Q [Dec] qIncompleteCase = [d| incompleteCase :: Bool -> () incompleteCase b = case b of True -> () |] qIncompleteFunction :: Q [Dec] qIncompleteFunction =[d| incompleteFunction :: Bool -> () incompleteFunction True = () |] }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Lib $qIncompleteCase $qIncompleteFunction incompleteCase' :: Bool -> () incompleteCase' b = case b of True -> () incompleteFunction' :: Bool -> () incompleteFunction' True = () }}} When compiling the above two files with `-Wall`, GHC 8.2.2 produces an "incomplete-patterns" warning for `qIncompleteCase`, `incompleteCase'`, and `incompleteFunction'`, but not for `qIncompleteFunction`. I would prefer to get a warning for `qIncompleteFunction` as well. My use case is the [https://hackage.haskell.org/package/surjective surjective] package, in which I intentionally generate code which produces warnings in order to warn the user about corresponding issues in their code. I could generate [https://github.com/gelisam/surjective/blob/master/src/Surjective.hs#L158-L162 better error messages] if GHC generated warnings for TH-generated functions as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 21:34:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 21:34:35 -0000 Subject: [GHC] #14837: Semigroup and Monoid instances for ST In-Reply-To: <049.7070815cfee9f2dc66e62515fc16d658@haskell.org> References: <049.7070815cfee9f2dc66e62515fc16d658@haskell.org> Message-ID: <064.8355cb57c0326d237748dde619a0bd7c@haskell.org> #14837: Semigroup and Monoid instances for ST -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: base Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14107 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Yeah! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 21:58:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 21:58:08 -0000 Subject: [GHC] #14831: QuantifiedConstraints: Odd superclass constraint In-Reply-To: <051.631b3f4dec55319ae6028526fc90fcb8@haskell.org> References: <051.631b3f4dec55319ae6028526fc90fcb8@haskell.org> Message-ID: <066.66585dfaecbad31b0f29645bd873e0c4@haskell.org> #14831: QuantifiedConstraints: Odd superclass constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah. Maybe not a bug. Consider {{{ instance (forall xx. cls xx => Semigroup xx) => Monoid (Free cls a) where mempty = undefined }}} We need the superclass {{{ [W] Semigroup (Free cls a) }}} What you were hoping was that GHC would use the instance {{{ instance (forall xx. cls xx => Semigroup xx) => Semigroup (Free cls a) where }}} to reduce the wanted superclass to {{{ [W] (forall xx. cls xx => Semigroup xx) }}} which we can readily solve from the context of the `Monoid` instance. But ALASf, the `Monoid` instace claims to have a way to solve `(Semigroup xx)` for any `xx`. Currently GHC tries the local, quantified constraints ''first'', so from {{{ [W] Semigroup (Free cls a) }}} using the quantified constraint, we get {{{ [W] cls (Free cls a) }}} which we have no way to solve. The quantified constraint does look far too general. I'll declare this not-a-bug for now. I have not looked at comment:2 yet; let's sort this part out first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 22:11:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 22:11:04 -0000 Subject: [GHC] #14734: QuantifiedConstraints conflated with impredicative polymorphism? In-Reply-To: <051.b13ce9a287df15f46f4472a3cecc22de@haskell.org> References: <051.b13ce9a287df15f46f4472a3cecc22de@haskell.org> Message-ID: <066.3bce1d217b177efb746e40b6c699b395@haskell.org> #14734: QuantifiedConstraints conflated with impredicative polymorphism? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: invalid | Keywords: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The difficulty with impredicativity is that, during inference, a unification variable may be unified with a polytype. Thus {{{ f :: forall a. [a] -> [a] xs :: [forall b. b->b] ...(f xs).. }}} Here f really has a type argument, and that type is polymorphic. We really have {{{ ...(f @(forall b b->b) xs)... }}} The hard bit is infeering the implicit, invisible type arguments. But here we are the level of types. With explicit arguments there should be nothing wrong with allowing polytypes. (It's a different matter for the implicit kind arguments, of course.) So... may it'd be OK. I'm just not sure what a principled story is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 22:23:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 22:23:05 -0000 Subject: [GHC] #14544: doCorePass has at least one missing case In-Reply-To: <049.4d90cc3cc6b5380801189db1b57310d5@haskell.org> References: <049.4d90cc3cc6b5380801189db1b57310d5@haskell.org> Message-ID: <064.220559be8a14bc4889cad436d5814add@haskell.org> #14544: doCorePass has at least one missing case -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4435 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * differential: => Phab:D4435 Comment: Replying to [comment:1 sjakobi]: > A first step might be to expand the catch-all to make sure that additional constructors aren't forgotten in the same way. Addressed in the attached Diff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 23:15:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 23:15:51 -0000 Subject: [GHC] #14838: missing "incomplete-patterns" warning for TH-generated functions In-Reply-To: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> References: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> Message-ID: <061.d94b3c014b0dfb6c4f8ec1c45fc80405@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 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): Amazing find. It turns out that this can all be tied back to this line of code (introduced in GHC 8.0, in commit 8a506104d5b5b71d5640afc69c992e0af40f2213): {{{#!hs ; unless (isGenerated origin) $ when (isAnyPmCheckEnabled dflags (DsMatchContext ctxt locn)) $ addTmCsDs (genCaseTmCs1 mb_scr new_vars) $ -- See Note [Type and Term Equality Propagation] checkMatches dflags (DsMatchContext ctxt locn) new_vars matches }}} Specifically, the `unless (isGenerated origin)` part. It turns out that `-Wincomplete-patterns` is completely suppressed for any code that has an `Origin` of `Generated`, and Template Haskell–spliced code happens to fall under that bucket. I see two ways out of this: 1. Go through the code in `Convert` and change every use of `Generated` to `FromSource`. 2. Come up with a separate origin for Template Haskell code (perhaps `FromTH`?). I'm not sure if it's worth the trouble, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 21 23:25:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Feb 2018 23:25:34 -0000 Subject: [GHC] #14838: missing "incomplete-patterns" warning for TH-generated functions In-Reply-To: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> References: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> Message-ID: <061.5bb08b5a7946634bdf2daf7adc9323ca@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 01:31:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 01:31:24 -0000 Subject: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) In-Reply-To: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> References: <051.8a467503f7e6e3ea87602b7d1c1e067f@haskell.org> Message-ID: <066.2f4d76a4c4edc9550150019e65195bd6@haskell.org> #1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by atravers): Replying to [comment:73 simonpj]: > I'm not sure which comment you are replying to; Darn - I assumed the "comment: 72 in reply to: 49" annotation was enough; the comment I was replying to was: > Lots of people would like this fixed; but no one has proposed a precise, worked-out, *design*. The way lies open! Now for the next assumption: > and I fear I don't understand what "something like this" is. Okay, so I was assuming that the machinery for the "--make" option for GHC had some resemblance to computeInOuts in the paper... > The big trouble with recursive modules is that: either you need a programmer written signature file (i.e. `.hs-boot`) or you have to compile all the modules in the SCC at once. I don't see any other path. In 2016, I rebuilt a HBC-based **bubble-gum-and-baling-wire sharp-edges- everywhere** implementation which copes with import-recursion (at least for what sources I've tested it on so far). The biggest catch? == **IT IS SLOW.** ...way too slow for practical use (if it only working with Haskell B. wasn't - in 2018 - impractical enough), hence no download links here or elsewhere. I had been working to improve its performance, with little success. But if you don't mind "going retro" for a while, I should be able to get it working again and send you the sources - just contact me on my GHC-Trac email address. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 08:38:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 08:38:23 -0000 Subject: [GHC] #14838: missing "incomplete-patterns" warning for TH-generated functions In-Reply-To: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> References: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> Message-ID: <061.c36c851c5c217de85600bea6f7225ea5@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Nothing in the commit message explains why we suppress pattern match checks for generated code. Perhaps we shouldn't? I favour (1) until we see why it's a bad idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 09:31:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 09:31:26 -0000 Subject: [GHC] #14705: ghc-iserv sometimes segfaults in profiled way In-Reply-To: <046.be67f06c8a68b32fb302ce316ee26108@haskell.org> References: <046.be67f06c8a68b32fb302ce316ee26108@haskell.org> Message-ID: <061.24f2c4652590f6d9a34db93608ab16d3@haskell.org> #14705: ghc-iserv sometimes segfaults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4437 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: (none) => simonmar * priority: normal => highest * differential: => Phab:D4437 * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 09:34:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 09:34:48 -0000 Subject: [GHC] #14705: ghc-iserv sometimes segfaults in profiled way In-Reply-To: <046.be67f06c8a68b32fb302ce316ee26108@haskell.org> References: <046.be67f06c8a68b32fb302ce316ee26108@haskell.org> Message-ID: <061.49896e6eb8d316695aeebdc547ada4bb@haskell.org> #14705: ghc-iserv sometimes segfaults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4437 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): FYI @bgamari, in the future we need to consider these things to be release-blocking. Running the interpreter with profiling is supposed to work (and we rely on it heavily at FB), but unfortunately we only have a few tests for it. Basically what should have happened here is that CI should have picked up the failing tests on the diff that broke it - so this is an argument for keeping profiling turned on in our new CircleCI setup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 09:47:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 09:47:14 -0000 Subject: [GHC] #14838: missing "incomplete-patterns" warning for TH-generated functions In-Reply-To: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> References: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> Message-ID: <061.202416acc8d7598d0fd2558c78560424@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think the current behaviour of suppressing warnings might be better? If you see a warning arising from spliced code, what should you do about it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 10:05:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 10:05:57 -0000 Subject: [GHC] #14838: missing "incomplete-patterns" warning for TH-generated functions In-Reply-To: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> References: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> Message-ID: <061.178b1cd9633d8ffb07218e25a4df3fe6@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But there shouldn't ''be'' any warnings! And indeed this ticket is all about a warning that the user wanted but wasn't there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 10:17:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 10:17:20 -0000 Subject: [GHC] #11984: Pattern match incompleteness / inaccessibility discrepancy In-Reply-To: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> References: <047.1cf132bd89a1199ee00c683072ed7b2c@haskell.org> Message-ID: <062.ee9c2e334e9975eb1c7d2b49767002af@haskell.org> #11984: Pattern match incompleteness / inaccessibility discrepancy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14098 | Differential Rev(s): Phab:D4434 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks Ryan. You've nailed the problem. I think your fix will work. And your long Note is great. But the particular solution smells wrong. I think the real bug is in the "ConCon" case of `pmcheckHd`, which looks like this {{{ pmcheckHd ( p@(PmCon {pm_con_con = c1, pm_con_args = args1})) ps guards (va@(PmCon {pm_con_con = c2, pm_con_args = args2})) (ValVec vva delta) | c1 /= c2 = return (usimple [ValVec (va:vva) delta]) | otherwise = kcon c1 (pm_con_arg_tys p) (pm_con_tvs p) (pm_con_dicts p) <$> pmcheckI (args1 ++ ps) guards (ValVec (args2 ++ vva) delta) }}} Notice that it ''totally ignores'' the existential `pm_con_tvs` of the two arguments. If the two aren't ''identical'' we'll get failure in precisely the way you diagnosed. I think your fix arranges that they are always identical. But even if we adopt your approach, we should add an ASSERT (with explanation) on the "ConCon" case. More fundamentally, how can we be sure that the assertion holds? I'm not sure. An alternative (and more solid) approach would be to fix the bug in ConCon. How? Well, looking back at the paper, if we have {{{ pmcheckHd ( p@(PmCon {pm_con_con = c1, pm_con_tvs = tvs1, pm_con_args = args1})) ps guards (va@(PmCon {pm_con_con = c2, pm_con_tvs = tvs2, pm_con_args = args2})) (ValVec vva delta) }}} then we want to add equalities to `Delta` that say `tvs1 = tvs2`. And that should be dead easy to do. If a corresponding pair `tv1` and `tv2` are already equal, no need to geneate the equality. Now the `mkOneCOnFull` fix turns into mere optimisation, one that makes it more likely that the equalities will hold. Does that makes sense? I'd be content with the ASSERT; that's the shortest path to a fix. But at least refer to this comment if so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 10:17:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 10:17:47 -0000 Subject: [GHC] #14824: automatically select instance In-Reply-To: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> References: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> Message-ID: <059.1d30bf1aa0f0516b3373382231e8c65b@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 zaoqi): Replying to [comment:9 AntC]: > Thank you zaoqi. The ticket is now very different to your first post. > > GHC is behaving as I would expect. It doesn't know which instance of `C` to select for the invocation of `m`. That's because it doesn't know the type of the result for `m [X1]`. You could go: > > {{{ > *Main> m [X1] :: X2 > }}} > > And get result `X2`, because GHC can select `instance C X1 X2`. > > That's similar to `read "5" :: Int` vs `read "5" :: Float` to disambiguate number formats. > > GHC does not automatically select an instance just because it seems to be the only one that fits: maybe there is another instance declared in another module that fits just as well. > > I could tell you about `FunctionalDependencies` combined with `OverlappingInstances` and `UndecidableInstances`. But first consider whether Closed `TypeFamilies` will provide a better approach. > > I can't see any fault. I can't see any "new feature" needed. Please do not use Trac tickets for help requests. I think they are "new feature" or "bug", I never use Trac tickets for help requests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 10:20:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 10:20:46 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.e00c996235ad261d024cf9236eebd665@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): >Without loopification we get a specialization for drop, with loopification we do not. I wonder why. Are you happy to pursue, or would you like help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 11:05:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 11:05:09 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe In-Reply-To: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> References: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> Message-ID: <057.e2f3accb67df12878d9af8796d8499ec@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Will take a look at the github branch (you wouldn't perhaps consider Phabricator instead? It's much easier to review code there) > So I took a shot at that problem as well (making object files deterministic), taking a different approach than what was taken so far (instead of making uniques not appear in outputs, I'm trying to genrate them deterministically) I'd be surprised if you can do that, we thought pretty hard about whether this was feasible and came to the conclusion that it probably wasn't, due to things like parallel builds, ghc --make needing to have unique supplies for multiple modules, and lazy I/O in the typechecker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 11:05:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 11:05:28 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe In-Reply-To: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> References: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> Message-ID: <057.ff22ab97be244242e9625b1f81c6a39c@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: niteria (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 12:21:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 12:21:29 -0000 Subject: [GHC] #14816: Missed Called Arity opportunity? In-Reply-To: <045.816de325f41605669038c6c4fef6d573@haskell.org> References: <045.816de325f41605669038c6c4fef6d573@haskell.org> Message-ID: <060.d23b34f745f6e967d06b11b5a1d622e6@haskell.org> #14816: Missed Called Arity opportunity? -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I spent some time thinking about how to implement this, but given that `lazy_fvs` plays a largely different role for thunks (unleashes strictness through signatures and stores usage in `lazy_fvs`) vs. non-thunks (puts weak demands into `lazy_fvs`, e.g. `` and `` which won't change anymore during fixpointing), I don't think pursuing this is worth the trouble. I'm afraid we just have to live with free variables getting a second-class treatment compared to parameters for the time being. This is another good argument for eventually splitting the demand analyser into its three sub- analyses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 12:54:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 12:54:43 -0000 Subject: [GHC] #14795: Data type return kinds don't obey the forall-or-nothing rule In-Reply-To: <050.173b7cb4e41b62bd0d9860f7bdb12f92@haskell.org> References: <050.173b7cb4e41b62bd0d9860f7bdb12f92@haskell.org> Message-ID: <065.9b654323fc287f8ac08c06dcd9a9e81e@haskell.org> #14795: Data type return kinds don't obey the forall-or-nothing rule -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType 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. Let's fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 13:11:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 13:11:46 -0000 Subject: [GHC] #3831: SpecConstr should exploit cases where there is exactly one call pattern In-Reply-To: <044.5fe60f4f535f1251caca48895d45a780@haskell.org> References: <044.5fe60f4f535f1251caca48895d45a780@haskell.org> Message-ID: <059.074a6ee2cb0ba5fab7ce8494edbaecef@haskell.org> #3831: SpecConstr should exploit cases where there is exactly one call pattern -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | simplCore/should_compile/T3831 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I'm trying to reproduce what the missed opportunity was here. I ran T3831 and realized that the test is ineffective for detecting a regression of this ticket: The compiler invocation misses a `-O2`. Re: missed tantalising opportunity: I think you are referring to `setAttributes`, specifically to this nesting of join points: {{{ join { $j1 $j1 x1 m1 = case m1 of { Nothing -> (# x1, Nothing #); Just x1 -> case ... x1 of { (# y1, n1 #) -> join { $j2 $j2 x2 m2 = ... -- many more join { $j12 x12 m12 = case m12 of { Nothing -> (# x12, Nothing #); Just f -> (# x12, Just (\a -> ...) #) } } in ... case m2 of { Nothing -> jump $j12 x2 Nothing; Just f -> case ... x2 of { (# x12', m12' #) -> case m12' of { Nothing -> jump $j12 x12' (Just (x6 lvl7)); Just _ -> jump $j12 x12' (Just ...) } } } } in case n1 of { Nothing -> jump $j2 y1 Nothing; Just _ -> jump $j2 y1 (Just ...) } } in }}} I probably have made some errors while simplifying, but the idea is that these join points aren't specialised at all. 1. These are all non-recursive. I was under the impression that we have the inliner for non-recursive bindings to decide if inlining is worthwhile. 2. I don't see how there's only one call-pattern for each join point. There are 3: one Nothing, two Justs. Specialising (branching factor 2) or even inlining (3) these would mean exponential blow-up in code size. So either I'm referring to the wrong fragment of the code (I found no other join points, let alone recursive ones) or things have changed since then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 13:28:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 13:28:37 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.1548fc2914917d1e7cb75f01da6510e6@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: sjakobi Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): Replying to [comment:7 vagarenko]: > I'm confused. Why do you want this? Isn't `byte offset` here is just `type offset * sizeof type`? While I'm not the requester, I think the types that [comment:2 Mathnerd314 proposes] have two advantages: * They relieve the user from doing the byte offset computation. * They are different from the preexisting types for the `indexTYPEArray` functions, thereby making it impossible to confuse the two. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 13:31:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 13:31:29 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.1bbab81cc5c52468cc166ee64b9646e6@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: sjakobi Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vagarenko): Replying to [comment:8 sjakobi]: > Replying to [comment:7 vagarenko]: > > I'm confused. Why do you want this? Isn't `byte offset` here is just `type offset * sizeof type`? > > While I'm not the requester, I think the types that [comment:2 Mathnerd314 proposes] have two advantages: > > * They relieve the user from doing the byte offset computation. Then what does that `Int# {-byte offset-}` parameter mean? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 13:32:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 13:32:53 -0000 Subject: [GHC] #13596: Try disabling inlining of DynFlags combinators In-Reply-To: <046.9accb606fa75f7116120ef5bc82c66b2@haskell.org> References: <046.9accb606fa75f7116120ef5bc82c66b2@haskell.org> Message-ID: <061.7038ecefef5128ddd94895541c09a6ad@haskell.org> #13596: Try disabling inlining of DynFlags combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | 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 tdammers): I tried a plain old stage2 build, comparing GHC HEAD against a version with added `NOINLINE` on `make_ord_flag` and `make_dep_flag`, which seems to reduce compile times only marginally, and overall memory use from 72M to 70M. Anything else that you think might benefit from `NOINLINE`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 13:51:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 13:51:56 -0000 Subject: [GHC] #14705: ghc-iserv sometimes segfaults in profiled way In-Reply-To: <046.be67f06c8a68b32fb302ce316ee26108@haskell.org> References: <046.be67f06c8a68b32fb302ce316ee26108@haskell.org> Message-ID: <061.9663e158c45a044aee24670dac6fed52@haskell.org> #14705: ghc-iserv sometimes segfaults in profiled way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4437 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Duly noted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 14:14:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 14:14:21 -0000 Subject: [GHC] #14839: Bits typeclass law for LSB Message-ID: <049.ae12d72b715673ae15b8ffd0b77836ec@haskell.org> #14839: Bits typeclass law for LSB -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: base | 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 documentation for the `Bits` typeclass claims: > Bits are numbered from 0 with bit 0 being the least significant bit. However, there's no law specified in the typeclass that enforces this. I realized this recently because I've been adding the laws for `Bits` to a library of property tests I maintain: http://hackage.haskell.org/package /quickcheck-classes-0.3.3/docs/Test-QuickCheck-Classes.html#v:bitsLaws In another package of mine, someone requested to add a `Bits` instance for a type but with the MSB considered bit 0. (https://github.com/andrewthad /haskell-ip/issues/29) I thought this would fail to satisfy a law of `Bits`, but it doesn't. So at the least, I was thinking we could add the following laws to `FiniteBits`: {{{ countTrailingZeros (bit 0) = 0 countLeadingZeros (bit 0) = finiteBitSize undefined - 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 14:46:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 14:46:18 -0000 Subject: [GHC] #14840: QuantifiedConstraints: Can't define class alias Message-ID: <051.efc0726cd0630f1f9a6cfd923f4eea44@haskell.org> #14840: QuantifiedConstraints: Can't define class alias -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language TypeInType, MultiParamTypeClasses, TypeFamilies, FlexibleContexts, FunctionalDependencies, AllowAmbiguousTypes, QuantifiedConstraints, GADTs, ConstraintKinds, KindSignatures, RankNTypes, FlexibleInstances, UndecidableInstances, TypeOperators #-} import Data.Kind class Reifies s a | s -> a where reflect :: proxy s -> a newtype Lift :: forall k. (Type -> Constraint) -> Type -> k -> Type where Lift :: a -> Lift cls a s data family Def :: (k -> Constraint) -> (k -> Type) class (forall s a. Reifies s (Def cls a) => cls (Lift cls a s)) => ReifiableConstraint cls instance (forall s a. Reifies s (Def cls a) => cls (Lift cls a s)) => ReifiableConstraint cls }}} gives an error {{{ $ ghci -ignore-dot-ghci Bug.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/Bug.hs, interpreted ) /tmp/Bug.hs:14:10: error: • Could not deduce: cls (Lift cls a s) arising from the superclasses of an instance declaration from the context: forall (s :: k) a. Reifies s (Def cls a) => cls (Lift cls a s) bound by the instance declaration at /tmp/Bug.hs:14:10-93 or from: Reifies s (Def cls a) bound by a quantified context at /tmp/Bug.hs:1:1 • In the instance declaration for ‘ReifiableConstraint cls’ | 14 | instance (forall s a. Reifies s (Def cls a) => cls (Lift cls a s)) => ReifiableConstraint cls | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, no modules loaded. Prelude> }}} This is a rare occasion that the class alias trick fails for me so ~+~yay~+~. But is it intended? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 14:52:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 14:52:03 -0000 Subject: [GHC] #855: Improvements to SpecConstr In-Reply-To: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> References: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> Message-ID: <061.dc0b5bbf38b3a2bc3ac744e86d834bdd@haskell.org> #855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 15:44:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 15:44:09 -0000 Subject: [GHC] #14840: QuantifiedConstraints: Can't define class alias In-Reply-To: <051.efc0726cd0630f1f9a6cfd923f4eea44@haskell.org> References: <051.efc0726cd0630f1f9a6cfd923f4eea44@haskell.org> Message-ID: <066.1dee71a3f3fdeff0aa0c957d1b840d54@haskell.org> #14840: QuantifiedConstraints: Can't define class alias -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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 have a hunch this will not be allow, but encoding sums and existentials doesn't work {{{#!hs class (forall sum. (a => sum) => (b => sum) => sum) => Sum a b instance (forall sum. (a => sum) => (b => sum) => sum) => Sum a b class (forall exists. (forall xx. f xx => exists) -> exists) => Exists f instance (forall exists. (forall xx. f xx => exists) -> exists) => Exists f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 15:47:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 15:47:51 -0000 Subject: [GHC] #12442: Pure unifier usually doesn't need to unify kinds In-Reply-To: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> References: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> Message-ID: <062.4942bda6da929f8b1f835a439a498334@haskell.org> #12442: Pure unifier usually doesn't need to unify kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T12442 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"34834234fff4a9dd0408d3b29e001cd132665327/ghc" 34834234/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="34834234fff4a9dd0408d3b29e001cd132665327" Comments in Unify, fixing #12442 [ci skip] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 15:49:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 15:49:20 -0000 Subject: [GHC] #12442: Pure unifier usually doesn't need to unify kinds In-Reply-To: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> References: <047.e9e2d8cc959848de0b431837d76e1a6f@haskell.org> Message-ID: <062.c1ae5ca7d3f911c830d5bd69239cd328@haskell.org> #12442: Pure unifier usually doesn't need to unify kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T12442 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2433 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: Here's the Note: {{{ Note [tcMatchTy vs tcMatchTyKi] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This module offers two variants of matching: with kinds and without. The TyKi variant takes two types, of potentially different kinds, and matches them. Along the way, it necessarily also matches their kinds. The Ty variant instead assumes that the kinds are already eqType and so skips matching up the kinds. How do you choose between them? 1. If you know that the kinds of the two types are eqType, use the Ty variant. It is more efficient, as it does less work. 2. If the kinds of variables in the template type might mention type families, use the Ty variant (and do other work to make sure the kinds work out). These pure unification functions do a straightforward syntactic unification and do no complex reasoning about type families. Note that the types of the variables in instances can indeed mention type families, so instance lookup must use the Ty variant. (Nothing goes terribly wrong -- no panics -- if there might be type families in kinds in the TyKi variant. You just might get match failure even though a reducing a type family would lead to success.) 3. Otherwise, if you're sure that the variable kinds to not mention type families and you're not already sure that the kind of the template equals the kind of the target, then use the TyKi version. }}} This is referenced from the various matcher functions. Sorry for letting this slip! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 16:25:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 16:25:17 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.181e917dfc5248acd0fcd73952acc812@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > > Without loopification we get a specialization for drop, with loopification we do not. > > I wonder why. Are you happy to pursue, or would you like help? It seems rather clear to me *why*: We get this code for `drop`, which does not satisfy the conditions for !SpecConstr; in particular, `drop` is not recursive (!SpecConstr only creates specializations for recursive functions): {{{ drop n xs = case xs of [] -> [] (y:ys) -> case n of I# n# -> case n# of 0# -> [] _ -> joinrec j xs n# = case xs of [] -> [] (y:ys) -> case n# of 0# -> [] _ -> call j ys (n# -# 1#) in j ys (n# -# 1#) }}} But I think I need your guidance as to what we should do about it! Should we simply enable !SpecConstr even for all non-recursive functions? (My gut feeling is that this will blow up code size and compilation times too much.) Maybe we need to float the `joinrec … in …` out out of `drop`, so that the remaining code in `drop` (which does the case analysis on `n`) is small enough to be always inlined? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 16:28:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 16:28:25 -0000 Subject: [GHC] #13596: Try disabling inlining of DynFlags combinators In-Reply-To: <046.9accb606fa75f7116120ef5bc82c66b2@haskell.org> References: <046.9accb606fa75f7116120ef5bc82c66b2@haskell.org> Message-ID: <061.8cef82d9269a9fd93b169cfc1d2ef072@haskell.org> #13596: Try disabling inlining of DynFlags combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, fair enough. I would look at the Core and `-ddump-inlinings` output to see whether there are any inlinings which may cause unnecessary code size growth. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 17:47:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 17:47:40 -0000 Subject: [GHC] #14838: missing "incomplete-patterns" warning for TH-generated functions In-Reply-To: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> References: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> Message-ID: <061.3903f6ec15bf37db8cca73c5361d4bdb@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I agree with Simon's reasoning. Moreover, it indeed appears that this was intended to be the case already, judging from [http://git.haskell.org/ghc.git/blob/34834234fff4a9dd0408d3b29e001cd132665327:/compiler/hsSyn/Convert.hs#l416 this comment]: {{{#!hs --We use FromSource as the origin of the bind -- because the TH declaration is user-written }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 18:09:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 18:09:43 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.d3cf3a3a85d68dad11c522ae0b44dded@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: sjakobi Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): Replying to [comment:9 vagarenko]: > Replying to [comment:8 sjakobi]: > > * They relieve the user from doing the byte offset computation. > Then what does that `Int# {-byte offset-}` parameter mean? What I meant is that the user doesn't need to compute the total offset. While a user may use the API you proposed like {{{#!hs indexByteInt16Array# ba (byte_offset + type_offset * int16_size) }}} the other API offers {{{#!hs indexByteInt16Array# ba byte_offset type_offset }}} which IMO is simply more concise and convenient. I hope this answers your question. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 18:26:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 18:26:02 -0000 Subject: [GHC] #14838: missing "incomplete-patterns" warning for TH-generated functions In-Reply-To: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> References: <046.404359ac761dc94d2a50e36ab6ec4ae4@haskell.org> Message-ID: <061.878fdab921b1a2adf4a263f087179fbb@haskell.org> #14838: missing "incomplete-patterns" warning for TH-generated functions -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4440 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4440 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 18:37:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 18:37:38 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.02fac5747ee2386287b1b553e7697b67@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: sjakobi Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vagarenko): Replying to [comment:10 sjakobi]: > Replying to [comment:9 vagarenko]: > > Replying to [comment:8 sjakobi]: > > > * They relieve the user from doing the byte offset computation. > > Then what does that `Int# {-byte offset-}` parameter mean? > > What I meant is that the user doesn't need to compute the total offset. While a user may use the API you proposed like > {{{#!hs > indexByteInt16Array# ba (byte_offset + type_offset * int16_size) > > }}} I still don't understand. What is total offset? What are `byte_offset` and `type_offset`? By `byte_offset` you mean number of bytes from the start of the array `ba` to the sought value of type `Int#`, correct? Then what is `type_offset`? Number of `Int16` elements before the sought element? But my motivation for this ticket was to be able to store values of different types in a `ByteArray#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 18:56:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 18:56:01 -0000 Subject: [GHC] #14841: Inconsistent allocation stats Message-ID: <049.f13f2d89e3fd0bbd99d1e3ecd80e2c48@haskell.org> #14841: Inconsistent allocation stats -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: System | Keywords: GCStats, | Operating System: Unknown/Multiple RTSStats | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm looking at Criterion internals, and seeing an inconsistency in the allocations reported by `GCStats` and `RTSStats`. Here is a small reproduction: {{{#!hs {-# LANGUAGE CPP #-} module Main where import GHC.Stats import System.Mem (performGC) main :: IO () main = do runOldThing 1000 #if __GLASGOW_HASKELL__ >= 802 putStrLn "Running new:" runThing 1000 #endif runOldThing :: Int -> IO () runOldThing n = loop n 0 >> return () where loop 0 _ = return 0 loop count x = do performGC stats <- getGCStats putStrLn $ show (count `mod` 15) ++ ": " ++ show (bytesAllocated stats - x) ++ " num: " ++ show (numGcs stats) loop (count-1) (bytesAllocated stats) #if __GLASGOW_HASKELL__ >= 802 runThing :: Int -> IO () runThing = loop where loop 0 = return () loop n = do performGC stats <- getRTSStats putStrLn $ show (n `mod` 15) ++ ": " ++ show (gcdetails_allocated_bytes (gc stats)) ++ " num: " ++ show (gcs stats) loop (n-1) #endif }}} This code just performs a garbage collection and then prints the stats in a loop. Here is a snippet of the output. {{{ ... 4: 8840 num: 1967 3: 4880 num: 1968 2: 4880 num: 1969 1: 4880 num: 1970 0: 4880 num: 1971 14: 4880 num: 1972 13: 4976 num: 1973 12: 4976 num: 1974 11: 4976 num: 1975 10: 4976 num: 1976 9: 4976 num: 1977 8: 4880 num: 1978 7: 4880 num: 1979 6: 4880 num: 1980 5: 4880 num: 1981 4: 8840 num: 1982 3: 4880 num: 1983 2: 4880 num: 1984 1: 4880 num: 1985 0: 4880 num: 1986 14: 4880 num: 1987 13: 4976 num: 1988 12: 4976 num: 1989 11: 4976 num: 1990 10: 4976 num: 1991 9: 4976 num: 1992 8: 4880 num: 1993 7: 4880 num: 1994 6: 4880 num: 1995 5: 4880 num: 1996 4: 8840 num: 1997 3: 4880 num: 1998 2: 4880 num: 1999 1: 4880 num: 2000 }}} On the left, I've included the gc number `mod` 15 to show that exactly every 15 gcs, there is an extra 4k bytes reported. This output was made with 8.2.1. On 7.8.4, 7.10.3, and 8.0.2 it's every 23. And on 8.4.0.20180204 it's every 9. I've played around with extra allocations between garbage collections, but the interval remained constant. I tried poking around the rts, but I've been unable to determine if this is a bug or just unavoidable noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 21:23:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 21:23:00 -0000 Subject: [GHC] #14826: Flatten data types extending other data types in STG In-Reply-To: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> References: <046.542e466e9e1c00bebb5d10d37acdec0f@haskell.org> Message-ID: <061.fd6b48f2e7c3092bb15851e46acf3d7b@haskell.org> #14826: Flatten data types extending other data types in STG -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: 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 sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 21:51:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 21:51:58 -0000 Subject: [GHC] #14842: Layout extensions missing from documentation Message-ID: <042.f93a226097e3778bd4bc727df59d1107@haskell.org> #14842: Layout extensions missing from documentation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Picking up this issue from https://mail.haskell.org/pipermail/ghc-devs/2018-February/015373.html > seems like none of the extensions that alter or relax layout are documented currently. (AlternativeLayoutRule, AlternativeLayoutRuleTransitional, DoAndIfThenElse, NondecreasingIndentation, RelaxedLayout) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 21:58:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 21:58:49 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.d4cb30a44f9d783b32d23d8e6dcfac23@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): JFTR, I just compared `master` with my branch with !SpecConstr disabled, and all allocation regressions but one (in `queens`, not yet investigated) did go away. So the issue of !SpecConstr vs. loopification seems to be the main road blocker here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 22:07:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 22:07:25 -0000 Subject: [GHC] #14842: Layout extensions missing from documentation In-Reply-To: <042.f93a226097e3778bd4bc727df59d1107@haskell.org> References: <042.f93a226097e3778bd4bc727df59d1107@haskell.org> Message-ID: <057.3a644456afc4b9273299f6a236d8c4fb@haskell.org> #14842: Layout extensions missing from documentation -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sjakobi: Old description: > Picking up this issue from > > https://mail.haskell.org/pipermail/ghc-devs/2018-February/015373.html > > > seems like none of the extensions > that alter or relax layout are documented currently. > (AlternativeLayoutRule, AlternativeLayoutRuleTransitional, > DoAndIfThenElse, > NondecreasingIndentation, RelaxedLayout) New description: Picking up this issue from https://mail.haskell.org/pipermail/ghc-devs/2018-February/015373.html > seems like none of the extensions that alter or relax layout are documented currently. (AlternativeLayoutRule, AlternativeLayoutRuleTransitional, DoAndIfThenElse, NondecreasingIndentation, RelaxedLayout) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 22 22:10:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Feb 2018 22:10:02 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.2807a8588a0d8dd5075fd7ba3cefa565@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: sjakobi Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): Replying to [comment:11 vagarenko]: > I don't understand. What is total offset? What are `byte_offset` and `type_offset`? > > By `byte_offset` you mean number of bytes from the start of the array `ba` to the sought value of type `Int#`, correct? > > Then what is `type_offset`? Number of `Int16` elements before the sought element? But my motivation for this ticket was to be able to store values of different types in a `ByteArray#`. Yes, sorry for my lack of clarity and thanks for putting it in a nutshell! What I assume is [comment:2 Mathnerd314]'s motivation is that even when a `ByteArray#` contains several types, it may contain a sequence of values of the same type. For example you may want to serialize a vector of `Int32`s by first writing the length of the vector as a `Word64` followed by the values. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 00:37:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 00:37:23 -0000 Subject: [GHC] #13362: GHC first generation of GC to be as large as largest cache size by default In-Reply-To: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> References: <045.9df30bf1acd19df01317b133116e51f6@haskell.org> Message-ID: <060.7ccf28c91ed431c9e74005f9e3c37716@haskell.org> #13362: GHC first generation of GC to be as large as largest cache size by default -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: numa cache gc | newcomers 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 sjakobi: Old description: > This will improve performance a lot by default. > > If anyone needs different size - there is "-A" RTS option. Machines are > very different. Currently this size is 512k by default for all different > architectures and hardware no matter what. > In most cases machines with larger caches have more RAM as well and vice > versa. So this will affect positively both small and larger machines. It > will be most efficient in most cases to keep short lived objects in > caches. Most modern workstation and server machines have L3 cache as > well, that is why I'm asking for "largest cache size". > > Second idea will be if there are two short lived generations on machines > with second and third level caches with sizes that match both. > > For NUMA machines with non-unified caches (like > [http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825 > this strange and non-common ARM]) the common solution could be to set > first generation to be with size of the largest cache of smallest core. > Which will not be the optimal, but close to. > > [https://www.reddit.com/r/haskell/comments/5rf1r5/ghc_first_generation_of_gc_to_be_as_large_as/ > Related Reddit discussion] New description: This will improve performance a lot by default. If anyone needs different size - there is "-A" RTS option. Machines are very different. Since 8.2 this size has been 1MB by default for all different architectures and hardware no matter what. In most cases machines with larger caches have more RAM as well and vice versa. So this will affect positively both small and larger machines. It will be most efficient in most cases to keep short lived objects in caches. Most modern workstation and server machines have L3 cache as well, that is why I'm asking for "largest cache size". Second idea will be if there are two short lived generations on machines with second and third level caches with sizes that match both. For NUMA machines with non-unified caches (like [http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825 this strange and non-common ARM]) the common solution could be to set first generation to be with size of the largest cache of smallest core. Which will not be the optimal, but close to. [https://www.reddit.com/r/haskell/comments/5rf1r5/ghc_first_generation_of_gc_to_be_as_large_as/ Related Reddit discussion] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 04:09:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 04:09:15 -0000 Subject: [GHC] #14843: Can't splice a partially applied PromoteTupleT type from Template Haskell Message-ID: <050.3a3c674a7e7086c9c05579f6851de573@haskell.org> #14843: Can't splice a partially applied PromoteTupleT type from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.2.2 Haskell | 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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH.Syntax type T1 = $(return (PromotedTupleT 2)) type T2 = $([t| '(,) |]) type T3 = $(return (PromotedT (tupleDataName 2))) }}} The splices for `T2` and `T3` both work. However, the splice for `T1` causes Template Haskell to have a conniption: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:7:13: error: • Malformed type PromotedTupleT 2 When splicing a TH type: '(,) • In the untyped splice: $(return (PromotedTupleT 2)) | 7 | type T1 = $(return (PromotedTupleT 2)) | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 04:18:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 04:18:51 -0000 Subject: [GHC] #14843: Can't splice a partially applied PromoteTupleT type from Template Haskell In-Reply-To: <050.3a3c674a7e7086c9c05579f6851de573@haskell.org> References: <050.3a3c674a7e7086c9c05579f6851de573@haskell.org> Message-ID: <065.a5a1486f690d3351fba6fa041945e9ac@haskell.org> #14843: Can't splice a partially applied PromoteTupleT type from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4442 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4442 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 06:59:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 06:59:35 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.895128f677f4db43506d5253274ec302@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:16 deech]: > I've put together a [https://github.com/deech/Trac12506 reduced example] that has the same issues. It's much easier to work with. In putting this together I noticed there is a vast difference in compilation time and memory between GHC 8.02 and GHC 8.22; the former takes 45 seconds and uses 1.4GB RAM to compile, the latter, 10 seconds and 200 MB so that is a great improvement. > > However while compilation speed is much improved between 8.0.2 and 8.2.2 that still only brings it up to par with GHC 7.10 which is GHC version against which I reported the issue in the first place so the problem still exists. > > Hopefully this reduced example helps clarify the underlying issue. Great, that makes things so much easier! Thanks a lot, I'll look into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 08:58:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 08:58:31 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.094302a6db7a3af0bb95f19cd3fb3054@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > We get this code for drop, which does not satisfy the conditions for SpecConstr; in particular, drop is not recursive (SpecConstr only creates specializations for recursive functions): And rightly so! The new code for `drop` look splendid. The first iteration unboxes the boxed parameter `n`, and then the `joinrec` is a tight inner loop that races down the list; it's pretty much identical to the `$sdrop` we got before. So why is this worse than the previous version? It should be easy enough for me to repro this even without your loopification patch, by manually writing the post-loopification code. If you can post that code here I'll be in a better position to help. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 08:59:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 08:59:56 -0000 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> References: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> Message-ID: <061.e7bb3d405e81b0e10f8cfde154b34d1b@haskell.org> #915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: 855 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * blockedby: => 855 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 09:05:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 09:05:15 -0000 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> References: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> Message-ID: <061.07ac919bca8b0bd70bca1a7c763c2218@haskell.org> #915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: 855 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by spl): * cc: leather@… (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 09:53:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 09:53:42 -0000 Subject: [GHC] #3831: SpecConstr should exploit cases where there is exactly one call pattern In-Reply-To: <044.5fe60f4f535f1251caca48895d45a780@haskell.org> References: <044.5fe60f4f535f1251caca48895d45a780@haskell.org> Message-ID: <059.c68758de04f5ded44f7768cb4ca240d5@haskell.org> #3831: SpecConstr should exploit cases where there is exactly one call pattern -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.13 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | simplCore/should_compile/T3831 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Huh. Indeed those join points have more than one call pattern. (And are non-rec to boot.) It looks as if something must have changed since I wrote that. Short of reverting to that version of GHC and trying it, I'm not sure what to suggest. Mysterious, but not actually a problem, I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 12:08:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 12:08:01 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.c02d6f47d4e98899433b85aa2c70bd07@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): OK, got it compiled against GHC head. The output of `-ddump-timings` shows two obvious suspects: {{{ [5 of 5] Compiling Main ( app/Main.hs, app/Main.o ) *** Parser [Main]: Parser [Main]: alloc=14721280 time=9.927 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=585898184 time=956.617 *** Desugar [Main]: Desugar [Main]: alloc=76966472 time=214.242 *** Simplifier [Main]: Simplifier [Main]: alloc=3469053424 time=2430.489 *** CoreTidy [Main]: CoreTidy [Main]: alloc=220130032 time=371.644 *** CorePrep [Main]: CorePrep [Main]: alloc=7744 time=0.030 *** CodeGen [Main]: CodeGen [Main]: alloc=3436008728 time=4730.477 Linking app/Main ... }}} In other words, while compiling `Main`, we get very long timings on the Simplifier and CodeGen steps. I suspect that the latter is caused by the former. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 13:40:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 13:40:59 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.217a2fffdbc771ae149b04d985d1eb1f@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > So why is this worse than the previous version? Because if `drop` itself is in an inner loop, something like `map (\n -> drop n xs) [0..1000]`, then we have to allocate a box for the the `I#` to wrap the argument. Previously, `drop` would have a specialization rule, and the calls to `drop` would be replaced by a call to `$sdrop`. _But_: Maybe we should simply not worry: For x2n1, allocation goes up by 80%, but the instruction count stays the same (+0.05%). I guess that the extra `I#` constructor needed to allocate is consumed pretty quickly, and never GC’ed… _But again_: This line of reasoning doesn’t cut it for other benchmarks. For example `treejoin`’s allocation goes up by 27%, and the instruction count by 72%(!). With `-f-no-spec-constr`, there is no difference in either number. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 13:51:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 13:51:14 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.ab95b768903f0bd875fc432777950386@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Because if drop itself is in an inner loop, something like map (\n -> drop n xs) [0..1000], then we have to allocate a box for the the I# to wrap the argument. Ah, well that would ''also'' be true of any non-recursive function that was called in this way. I think you are claiming that all the extra allocation is due to boxing the arguments to a non-recursive function that is called repeatedly. That seems surprising, but perhaps it is true. If so, then I suppose a possible fix is to specialise non-recursive functions too. Maybe that would be good in general; I'm not sure. Might be worth trying... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 13:58:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 13:58:44 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.0f51f1c59edcd8b41e57ad848f5fb94c@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 14:09:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 14:09:02 -0000 Subject: [GHC] #855: Improvements to SpecConstr In-Reply-To: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> References: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> Message-ID: <061.5089731a89047d4d058930c1bf841f61@haskell.org> #855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * blocking: 915 => Comment: Re: Specialising on lambdas. To have a concrete example to work on, I here is [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-hs stream-fusion.hs], which contains a minimal stream fusion harness using just `singletonS`, `enumFromToS`, `sumS`, `mapS` and `concatMapS`. There are three example functions `ex{1,2,3}` with increasing nesting of `concatMapS` that should all reduce to the same function `goal`. More examples can follow when we get these running. Currently, GHC HEAD (8.5, `8529fbba309cd692bbbb0386321515d05a6ed256`) produces [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-simpl-L436 this infamous piece of Core] ([https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-spec-L1387 -ddump-spec]) for `ex1`. The goal is to specialise `go` for the call-pattern including a lambda [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-simpl-L466-L470 here]. Before I found this ticket, I basically re-implemented part of what simonpj did, results in [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc2362df this commit]. I basically tracked `CallOcc`urrences similarly to `ScrutOcc`s. With this specialisation for lambdas, things currently look like [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-simpl-L435 this]. The function has been specialised alright, but the free variables of [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-head-simpl-L466-L470 said lambda], which includes the constant `Step`, are passed to [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-simpl-L453-L457 the specialisation as arguments]. We want to specialise for this new `Call` pattern! However, without `-fspec-constr-keen`, !SpecConstr will only fire when it finds a matching `ScrutOcc`. Looking at the output of [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-spec-L1495-L1499 -ddump-spec] the corresponding `ScrutOcc` will only become visible in the specialised RHS, but we currently only specialise the original RHS. Even then, I imagine that in the general case we need a simplifier run in-between to reliably detect that we scrutinize the new parameter. But that's not actually a problem, because we can use `GHC.Types.SPEC` to tell the compiler to specialise without seeing an `ArgOcc`. Still, GHC needs to see a `Call` pattern with that constant argument, which will emerge [https://gist.github.com/sgraf812/7b272f09c7da34073b994efd5425ccc8#file- stream-fusion-lam-spec-L1503-L1517 here], but only after the corresponding RULEs fired. Here are some ideas: 1. We can query the `exprFreeVarsList` [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc2362df #diff-992f9a53caac96c0e6303669d68a20e1R2163 here] and see which free variables of the lambda have known constant value and include these in the specialisation. This was somehow fruitless so far for this case, as the free var for the `Yield ...` wasn't included in the `ValueEnv`. Not sure if this is even enough to reach the fixed point in all cases. 2. Specialise specialisations (and fix anything non-terminating) (+ mini simplifier passes) + mini RULE engine. I'm uncomfortable with that much code duplication. 3. Include call-pattern specialisation in the Simplifier, for a radical change. On an abstract level, this seems reasonable: Specialisation is a more modest form of inlining with code size in mind, one that even works for recursive functions. It could chew on stuff the inliner gave up on because of code size requirements (even non-recursive functions). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 14:16:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 14:16:36 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe In-Reply-To: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> References: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> Message-ID: <057.a2ca9feb6632a30fb626cb751dbfce1d@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:3 simonmar]: > you wouldn't perhaps consider Phabricator instead? It's much easier to review code there I will when I have it working and have some non-hacky commits; until then I prefer Github because it is much easier to update multi-commit patch series there than on Phab. > I'd be surprised if you can do that, we thought pretty hard about whether this was feasible and came to the conclusion that it probably wasn't, due to things like parallel builds, ghc --make needing to have unique supplies for multiple modules, and lazy I/O in the typechecker. I'm not convinced either yet that it will work, and the `'r'` `UniqueSupply` in the global `--make` `HscEnv` is giving me some troubles at the current state, but so far I haven't found a reason why maintaining an independent "seed" for each module (as we know all modules ahead of time in a `--make` invocation) wouldn't cover at least the cases of multiple modules and `-j`. Regarding the lazy I/O in the typechecker, could you point me at where that happens? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 14:23:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 14:23:24 -0000 Subject: [GHC] #14844: SpecConstr also non-recursive function Message-ID: <046.efe4b52b55047d5007c336d909140c96@haskell.org> #14844: SpecConstr also non-recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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 order to fix the regressions introduced by loopification (#14068), we probably need to get !SpecConstr also do something about non-recursive functions. In a first iteration, we might want to enable it for non-recursive functions straight-away, and see if it fixes the regressions introduced by Loopification. But if this turns out to be too slow/too expensive, we should try specializing non-recursive ''local'' functions ''if there is only one call-patterns''. That ought to be a straight win in all cases anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 14:23:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 14:23:46 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.1bd3e082427b424b9ffa1ff64f4b40dd@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > If so, then I suppose a possible fix is to specialise non-recursive functions too. Maybe that would be good in general; I'm not sure. Might be worth trying... Let’s do this in #14844 and then come back here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 14:31:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 14:31:34 -0000 Subject: [GHC] #14697: Redundant computation in fingerprintDynFlags when compiling many modules In-Reply-To: <046.c781f4e812a45b7f1a7576c9d7db1ab8@haskell.org> References: <046.c781f4e812a45b7f1a7576c9d7db1ab8@haskell.org> Message-ID: <061.a97854a726e567ecc6d3ea51694660be@haskell.org> #14697: Redundant computation in fingerprintDynFlags when compiling many modules -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 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:D4445 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * status: new => patch * differential: => phab:D4445 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 14:33:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 14:33:34 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe In-Reply-To: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> References: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> Message-ID: <057.95f2a4c396675323d927cdafa82557c9@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): > but so far I haven't found a reason why maintaining an independent "seed" for each module (as we know all modules ahead of time in a --make invocation) wouldn't cover at least the cases of multiple modules and -j. But what are those seeds? The unique supply for each module would need to generate uniques that are - different from those in every other module - the same each time you compile this module So it seems like the uniques would have to be qualifed by the module/package names somehow. Or did you have some other idea in mind? > Regarding the lazy I/O in the typechecker, could you point me at where that happens? Look at `TcRnMonad.forkM_maybe`. If you solved the seed problem (above) then the same solution could be applied to unique supplies for imported modules which would also solve the lazy I/O problem, but it's still not clear to me how you do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 14:33:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 14:33:34 -0000 Subject: [GHC] #14844: SpecConstr also non-recursive function In-Reply-To: <046.efe4b52b55047d5007c336d909140c96@haskell.org> References: <046.efe4b52b55047d5007c336d909140c96@haskell.org> Message-ID: <061.d06f538b82faa16ab62edc7013574ce0@haskell.org> #14844: SpecConstr also non-recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 14:38:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 14:38:27 -0000 Subject: [GHC] #14839: Bits typeclass law for LSB In-Reply-To: <049.ae12d72b715673ae15b8ffd0b77836ec@haskell.org> References: <049.ae12d72b715673ae15b8ffd0b77836ec@haskell.org> Message-ID: <064.cf3e10af07f6f5ccdfd6b55f78e91e83@haskell.org> #14839: Bits typeclass law for LSB -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: base 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: core-libraries-committee@… (added) * milestone: => 8.6.1 Comment: This is likely a job for the CLC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 14:56:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 14:56:35 -0000 Subject: [GHC] #855: Improvements to SpecConstr In-Reply-To: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> References: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> Message-ID: <061.ded36a05ac2fb5d9bd0b6ad6251bc3b7@haskell.org> #855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * blocking: => 915 Comment: Sorry, didn't mean to remove that Blocking thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 15:17:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 15:17:09 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe In-Reply-To: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> References: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> Message-ID: <057.d47d3483cd9b233d5af9e27ef6918e95@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:6 simonmar]: > So it seems like the uniques would have to be qualifed by the module/package names somehow. Yes. I use the "`mod_index`" number, like `1` in the output `[1 of 3] Compiling A`, by which I index an array of `UniqueSupply` instead of having only one global one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 15:35:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 15:35:16 -0000 Subject: [GHC] #14845: TypeInType, index by GADT witnessing constraint Message-ID: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> #14845: TypeInType, index by GADT witnessing constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Just wondering if it would ever make sense to allow or use constraints like this {{{#!hs {-# Language PolyKinds, DataKinds, KindSignatures, GADTs, TypeInType, ConstraintKinds #-} import Data.Kind data Struct :: (k -> Constraint) -> (k -> Type) where S :: cls a => Struct cls a data Foo a where F :: Foo (S::Struct Eq a) }}} {{{ $ ghci -ignore-dot-ghci /tmp/test.hs GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/test.hs, interpreted ) /tmp/test.hs:9:13: error: • Illegal constraint in a type: cls0 a0 • In the first argument of ‘Foo’, namely ‘(S :: Struct Eq a)’ In the type ‘Foo (S :: Struct Eq a)’ In the definition of data constructor ‘F’ | 9 | F :: Foo (S::Struct Eq a) | ^ Failed, no modules loaded. Prelude> }}} Please close the ticket if it doesn't -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 15:35:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 15:35:47 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness (was: TypeInType, index by GADT witnessing constraint) In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.e8685d870102b6d134d60d83d0e57a5a@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 15:57:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 15:57:10 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.733ffa56a13f3597c449ad7ed7a1a243@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13895 Comment: I too have hit this limitation—or rather, I have hit this error message—in #13895. But in the case of #13895, the root of the issue is impredicativity, whereas here I'm not sure that's the case. I'd be curious to hear goldfire's reasoning for why this restriction is in place, since the [http://git.haskell.org/ghc.git/blob/34834234fff4a9dd0408d3b29e001cd132665327:/compiler/typecheck/Inst.hs#l451 source code] doesn't have much in the way of an explanation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 15:57:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 15:57:46 -0000 Subject: [GHC] #13895: "Illegal constraint in a type" error - is it fixable? In-Reply-To: <050.ce595caa9b871911009a7eed084d4706@haskell.org> References: <050.ce595caa9b871911009a7eed084d4706@haskell.org> Message-ID: <065.b6f2357d1942564c3d995d882b605f7f@haskell.org> #13895: "Illegal constraint in a type" error - is it fixable? -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045, #14845 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #12045 => #12045, #14845 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 16:02:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 16:02:07 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.b89a5576cd50256b26361c4ccd5116e3@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think it's this. `S` is a data constructor with an evidence argument. At the term level we pass evidence to `S`. But if we promote `S` we don't have a type-level version of evidence. So I was going to say "we don't promote `S`". But then I remembered that `TypeInType` is supposed to allow GADTs at the type level. So now I'm confused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 16:17:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 16:17:02 -0000 Subject: [GHC] #14846: Renamer hangs (because of -XInstanceSigs?) Message-ID: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> #14846: Renamer hangs (because of -XInstanceSigs?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: InstanceSigs | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes, TypeInType, EmptyCase, GADTs, FlexibleInstances, ConstraintKinds, UndecidableInstances, AllowAmbiguousTypes, InstanceSigs #-} import Data.Kind import Data.Proxy type Cat ob = ob -> ob -> Type data Struct :: (k -> Constraint) -> Type where S :: Proxy (a::k) -> Struct (cls::k -> Constraint) type Structured a cls = (S ('Proxy :: Proxy a)::Struct cls) data AStruct :: Struct cls -> Type where AStruct :: cls a => AStruct (Structured a cls) class StructI (structured::Struct (cls :: k -> Constraint)) where struct :: AStruct structured instance (Structured xx cls ~ structured, cls xx) => StructI structured where struct :: AStruct (Structured xx cls) struct = AStruct data Hom :: Cat k -> Cat (Struct cls) where class Category (cat::Cat ob) where i :: StructI a => ríki a a instance Category ríki => Category (Hom ríki :: Cat (Struct cls)) where i :: forall a. StructI a => Hom ríki a a i = case struct :: AStruct (Structured a cls) of }}} Running on 8.2.1 and 8.5.20180105 both loop until interrupted {{{ $ ghci -ignore-dot-ghci 199.hs GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 199.hs, interpreted ) ^CInterrupted. > > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 16:38:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 16:38:33 -0000 Subject: [GHC] #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later In-Reply-To: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> References: <050.c5c190ffbc3e4175e84536f4424d1ad2@haskell.org> Message-ID: <065.e564f417ad9c3e6e661d2b0e59608123@haskell.org> #14675: GHC 8.4.1 regression: segfault when loading doctest on a module with ANNs on Ubuntu 16.04 or later -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14603 | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with b4e32780a976193208eebbddf789eeb80351ac95. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 16:40:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 16:40:16 -0000 Subject: [GHC] #14847: Inferring dependent kinds for non-recursive types Message-ID: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> #14847: Inferring dependent kinds for non-recursive types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this {{{ data Proxy k (a :: k) = MkProxy data Proxy2 k a = MkP (Proxy k a) }}} which is discussed in [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#inferring-dependency-in-datatype-declarations a corner of the user manual]. Surprisingly, we reject `Proxy2` -- but there is nothing difficult about inferring its kind. There would be if it was recursive -- but it isn't. Simple solution: for non-recursive type declarations (we do SCC analysis so we know which these are) do not call `getInitialKinds`; instead, just infer the kind of the definition! Simple. Warning: is this recursive? {{{ data Proxy2 k a where MkP :: Proxy k a -> Proxy2 k a }}} Presumably no more than the other definition. But currently we need `Proxy2` in the environment during kind inference, because we kind-check the result type. That seems jolly odd and inconsistent. Needs more thought. Similar questions for {{{ data T a where T :: Int -> T Bool type family F a where F Int = True F _ = False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 16:40:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 16:40:56 -0000 Subject: [GHC] #14847: Inferring dependent kinds for non-recursive types In-Reply-To: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> References: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> Message-ID: <061.ccfe2c718c6a8ced28f599c3a6dbd152@haskell.org> #14847: Inferring dependent kinds for non-recursive types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider this > {{{ > data Proxy k (a :: k) = MkProxy > data Proxy2 k a = MkP (Proxy k a) > }}} > which is discussed in [http://downloads.haskell.org/~ghc/master/users- > guide/glasgow_exts.html#inferring-dependency-in-datatype-declarations a > corner of the user manual]. > > Surprisingly, we reject `Proxy2` -- but there is nothing difficult about > inferring its kind. There would be if it was recursive -- but it isn't. > > Simple solution: for non-recursive type declarations (we do SCC analysis > so we know which these are) do not call `getInitialKinds`; instead, just > infer the kind of the definition! Simple. > > Warning: is this recursive? > {{{ > data Proxy2 k a where > MkP :: Proxy k a -> Proxy2 k a > }}} > Presumably no more than the other definition. But currently we need > `Proxy2` in the environment during kind inference, because we kind-check > the result type. That seems jolly odd and inconsistent. Needs more > thought. > > Similar questions for > {{{ > data T a where > T :: Int -> T Bool > > type family F a where > F Int = True > F _ = False > }}} New description: Consider this {{{ data Proxy k (a :: k) = MkProxy data Proxy2 k a = MkP (Proxy k a) }}} which is discussed in [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#inferring-dependency-in-datatype-declarations a corner of the user manual]. Surprisingly, we reject `Proxy2` -- but there is nothing difficult about inferring its kind. There would be if it was recursive -- but it isn't. Simple solution: for non-recursive type declarations (we do SCC analysis so we know which these are) do not call `getInitialKinds`; instead, just infer the kind of the definition! Simple. Warning: is this recursive? {{{ data Proxy2 k a where MkP :: Proxy k a -> Proxy2 k a }}} Presumably no more than the other definition. But currently we need `Proxy2` in the environment during kind inference, because we kind-check the result type. That seems jolly odd and inconsistent. Needs more thought. Similar questions for {{{ data T a where T :: Int -> T Bool type family F a where F Int = True F _ = False }}} See also: * #14451 * #12088 * #9427 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 16:50:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 16:50:17 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.4d79fbc5bce306d0c2609e0a24c42963@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): As to why {{{ drop n xs = joinrec j n xs = case xs of [] -> [] (y:ys) -> case n of I# n# -> case n# of 0# -> [] _ -> call j (I# (n# -# 1#)) xs in j n xs }}} specializes to {{{ drop n xs = case xs of [] -> [] (y:ys) -> case n of I# n# -> case n# of 0# -> [] _ -> joinrec j xs n# = case xs of [] -> [] (y:ys) -> case n# of 0# -> [] _ -> call j ys (n# -# 1#) in j ys (n# -# 1#) }}} There is the call pattern `j (I# (n# -# 1#)) xs`, also `j` scrutinizes `n`. So SpecConstr makes something like this: {{{ drop n xs = joinrec j n xs = case xs of [] -> [] (y:ys) -> case n of I# n# -> case n# of 0# -> [] _ -> call j# (n# -# 1#) xs j# n# xs = case xs of [] -> [] (y:ys) -> case n# of 0# -> [] _ -> call j# (n# -# 1#) xs in j n xs }}} Now `j` is not recursive and is inlined and we get the resulting code. I wonder why `drop` isn't inlined in your example. That would surely make the allocation go away? Are there multiple calls to `drop` that obstruct inlining? And if so, do they share a common call pattern (e.g. `j (I# n) xs`)? Then that's one of the cases non-rec specialisation might be beneficial. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 16:54:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 16:54:55 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.3ee26f441d814bd4aa1ec0864e2539dd@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Technically, we do promote `S`, but the promoted `S` can't ever be applied, because we can't produce evidence. Perhaps a better error message is warranted, but until we have real dependent types (and can promote dictionaries), I think we're stuck on this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 17:05:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 17:05:49 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.c04b55bc56c68993caec0c002182821a@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Technically, we do promote S, but the promoted S can't ever be applied Would it not be better (for now anyway) not to promote S? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 17:07:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 17:07:06 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.5f97aeb8c9b6ecb971e1e5bb821656a7@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I suppose the difference in promoting and not promoting is in the error message, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 17:08:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 17:08:03 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.652581eeae3011b5c9d3a46fa3865949@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:6 goldfire]: > I suppose the difference in promoting and not promoting is in the error message, no? Indeed. If a tree is promoted in a forest but no one can see it, is it ever really promoted? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 17:10:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 17:10:27 -0000 Subject: [GHC] #14846: Renamer hangs (because of -XInstanceSigs?) In-Reply-To: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> References: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> Message-ID: <066.2cd9331364a134b3c1ebb05c573bc0b0@haskell.org> #14846: Renamer hangs (because of -XInstanceSigs?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: InstanceSigs | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I can't reproduce this with either version of GHC you give: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:29:8: error: • Couldn't match type ‘ríki1’ with ‘Hom ríki’ ‘ríki1’ is a rigid type variable bound by the type signature for: i :: forall k2 (cls1 :: k2 -> Constraint) (a :: Struct cls1) (ríki1 :: Struct cls1 -> Struct cls1 -> *). StructI a => ríki1 a a at Bug.hs:29:8-42 Expected type: ríki1 a a Actual type: Hom ríki a a • When checking that instance signature for ‘i’ is more general than its signature in the class Instance sig: forall (a :: Struct cls0). StructI a => Hom ríki a a Class sig: forall k (cls :: k -> Constraint) (a :: Struct cls) (ríki :: Struct cls -> Struct cls -> *). StructI a => ríki a a In the instance declaration for ‘Category (Hom ríki)’ | 29 | i :: forall a. StructI a => Hom ríki a a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:30:12: error: • Could not deduce: cls1 a1 arising from a use of ‘struct’ from the context: Category ríki bound by the instance declaration at Bug.hs:28:10-65 or from: StructI a bound by the type signature for: i :: forall (a :: Struct cls0). StructI a => Hom ríki a a at Bug.hs:29:8-42 • In the expression: struct :: AStruct (Structured a cls) In the expression: case struct :: AStruct (Structured a cls) of In an equation for ‘i’: i = case struct :: AStruct (Structured a cls) of | 30 | i = case struct :: AStruct (Structured a cls) of | ^^^^^^ }}} What am I missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 17:21:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 17:21:59 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.925ed70cf575f4adde7fb1f489120cce@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I suppose the difference in promoting and not promoting is in the error message, no? Indeed! You'll get "Data constructor S can't be used in a type because it's a GADT" or something like tat, rather than the current mysterious one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 17:23:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 17:23:16 -0000 Subject: [GHC] #14068: Loopification using join points In-Reply-To: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> References: <046.e16e22cbe3c046431dc8ebed421f2e67@haskell.org> Message-ID: <061.b9dbfd7eeb0442199bd4a7b26ac28d39@haskell.org> #14068: Loopification using join points -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13966 #14067 | Differential Rev(s): Phab:D3811 #14827 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > I wonder why drop isn't inlined in your example. That would surely make the allocation go away? Are there multiple calls to drop that obstruct inlining? I am only using `drop` as an example here, the real thing might be much larger; too large to be inlined. I’ll have to look. > And if so, do they share a common call pattern (e.g. j (I# n) xs)? Then that's one of the cases non-rec specialisation might be beneficial. Yes, that is the hope! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 17:24:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 17:24:52 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.0bf3336fe708fa0290d26da0834d2ab1@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. Then we can just reword the error message. :) Note that problem isn't that it's a GADT constructor. The problem is that it's a constrained constructor and constraints don't promote. Ryan, you find it far easier than I to actually get patches sent off -- would you mind tweaking this message? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 17:33:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 17:33:14 -0000 Subject: [GHC] #14846: Renamer hangs (because of -XInstanceSigs?) In-Reply-To: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> References: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> Message-ID: <066.2f024a2254bf5575c71b08089d547f8e@haskell.org> #14846: Renamer hangs (because of -XInstanceSigs?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: InstanceSigs | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Ah, I forgot. You have to add `ScopedTypeVariables`, that should be enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 17:33:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 17:33:51 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.f73d253e671f45edcfd83a88035f3511@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): But there's a significant wrinkle here. You're proposing that we change the error message to something like `Data constructor has a constraint 'cls0 a0', and thus cannot be promoted`, yes? But the place where this error message is thrown is `tcInstBinders`, which is not in any way data- constructor–specific. Indeed, as I mentioned in comment:2, this error message also occurs in the program in #13895, but that doesn't promote any data constructors whatsoever. So if we change this error message _carte blanche_, all of a sudden GHC is going to be complaining about data constructors which don't exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 17:39:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 17:39:07 -0000 Subject: [GHC] #14846: Renamer hangs (because of -XInstanceSigs?) In-Reply-To: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> References: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> Message-ID: <066.e84b36d9acf486383999302d5a6de423@haskell.org> #14846: Renamer hangs (because of -XInstanceSigs?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: InstanceSigs | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > {{{#!hs > {-# Language RankNTypes, TypeInType, EmptyCase, GADTs, FlexibleInstances, > ConstraintKinds, UndecidableInstances, AllowAmbiguousTypes, InstanceSigs > #-} > > import Data.Kind > import Data.Proxy > > type Cat ob = ob -> ob -> Type > > data Struct :: (k -> Constraint) -> Type where > S :: Proxy (a::k) -> Struct (cls::k -> Constraint) > > type Structured a cls = (S ('Proxy :: Proxy a)::Struct cls) > > data AStruct :: Struct cls -> Type where > AStruct :: cls a => AStruct (Structured a cls) > > class StructI (structured::Struct (cls :: k -> Constraint)) where > struct :: AStruct structured > > instance (Structured xx cls ~ structured, cls xx) => StructI structured > where > struct :: AStruct (Structured xx cls) > struct = AStruct > > data Hom :: Cat k -> Cat (Struct cls) where > > class Category (cat::Cat ob) where > i :: StructI a => ríki a a > > instance Category ríki => Category (Hom ríki :: Cat (Struct cls)) where > i :: forall a. StructI a => Hom ríki a a > i = case struct :: AStruct (Structured a cls) of > }}} > > Running on 8.2.1 and 8.5.20180105 both loop until interrupted > > {{{ > $ ghci -ignore-dot-ghci 199.hs > GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( 199.hs, interpreted ) > ^CInterrupted. > > > > > }}} New description: {{{#!hs {-# Language RankNTypes, TypeInType, EmptyCase, GADTs, FlexibleInstances, ConstraintKinds, Undecida bleInstances, AllowAmbiguousTypes, InstanceSigs, ScopedTypeVariables #-} import Data.Kind import Data.Proxy type Cat ob = ob -> ob -> Type data Struct :: (k -> Constraint) -> Type where S :: Proxy (a::k) -> Struct (cls::k -> Constraint) type Structured a cls = (S ('Proxy :: Proxy a)::Struct cls) data AStruct :: Struct cls -> Type where AStruct :: cls a => AStruct (Structured a cls) class StructI (structured::Struct (cls :: k -> Constraint)) where struct :: AStruct structured instance (Structured xx cls ~ structured, cls xx) => StructI structured where struct :: AStruct (Structured xx cls) struct = AStruct data Hom :: Cat k -> Cat (Struct cls) where class Category (cat::Cat ob) where i :: StructI a => ríki a a instance Category ríki => Category (Hom ríki :: Cat (Struct cls)) where -- Commenting out this instance signature makes the issue go away i :: forall a. StructI a => Hom ríki a a i = case struct :: AStruct (Structured a cls) of }}} Running on 8.2.1 and 8.5.20180105 both loop until interrupted {{{ $ ghci -ignore-dot-ghci 199.hs GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 199.hs, interpreted ) ^CInterrupted. > > }}} -- Comment (by RyanGlScott): Thanks. I've updated the original program to reflect this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 17:40:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 17:40:14 -0000 Subject: [GHC] #14846: Renamer hangs (because of -XInstanceSigs?) In-Reply-To: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> References: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> Message-ID: <066.6208695e825de6ce2a223d023def34b1@haskell.org> #14846: Renamer hangs (because of -XInstanceSigs?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: InstanceSigs | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > {{{#!hs > {-# Language RankNTypes, TypeInType, EmptyCase, GADTs, FlexibleInstances, > ConstraintKinds, Undecida > bleInstances, AllowAmbiguousTypes, InstanceSigs, ScopedTypeVariables #-} > > import Data.Kind > import Data.Proxy > > type Cat ob = ob -> ob -> Type > > data Struct :: (k -> Constraint) -> Type where > S :: Proxy (a::k) -> Struct (cls::k -> Constraint) > > type Structured a cls = (S ('Proxy :: Proxy a)::Struct cls) > > data AStruct :: Struct cls -> Type where > AStruct :: cls a => AStruct (Structured a cls) > > class StructI (structured::Struct (cls :: k -> Constraint)) where > struct :: AStruct structured > > instance (Structured xx cls ~ structured, cls xx) => StructI structured > where > struct :: AStruct (Structured xx cls) > struct = AStruct > > data Hom :: Cat k -> Cat (Struct cls) where > > class Category (cat::Cat ob) where > i :: StructI a => ríki a a > > instance Category ríki => Category (Hom ríki :: Cat (Struct cls)) where > -- Commenting out this instance signature makes the issue go away > i :: forall a. StructI a => Hom ríki a a > i = case struct :: AStruct (Structured a cls) of > }}} > > Running on 8.2.1 and 8.5.20180105 both loop until interrupted > > {{{ > $ ghci -ignore-dot-ghci 199.hs > GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( 199.hs, interpreted ) > ^CInterrupted. > > > > > }}} New description: {{{#!hs {-# Language RankNTypes, TypeInType, EmptyCase, GADTs, FlexibleInstances, ConstraintKinds, UndecidableInstances, AllowAmbiguousTypes, InstanceSigs, ScopedTypeVariables #-} import Data.Kind import Data.Proxy type Cat ob = ob -> ob -> Type data Struct :: (k -> Constraint) -> Type where S :: Proxy (a::k) -> Struct (cls::k -> Constraint) type Structured a cls = (S ('Proxy :: Proxy a)::Struct cls) data AStruct :: Struct cls -> Type where AStruct :: cls a => AStruct (Structured a cls) class StructI (structured::Struct (cls :: k -> Constraint)) where struct :: AStruct structured instance (Structured xx cls ~ structured, cls xx) => StructI structured where struct :: AStruct (Structured xx cls) struct = AStruct data Hom :: Cat k -> Cat (Struct cls) where class Category (cat::Cat ob) where i :: StructI a => ríki a a instance Category ríki => Category (Hom ríki :: Cat (Struct cls)) where -- Commenting out this instance signature makes the issue go away i :: forall a. StructI a => Hom ríki a a i = case struct :: AStruct (Structured a cls) of }}} Running on 8.2.1 and 8.5.20180105 both loop until interrupted {{{ $ ghci -ignore-dot-ghci 199.hs GHCi, version 8.5.20180105: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 199.hs, interpreted ) ^CInterrupted. > > }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 22:54:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 22:54:49 -0000 Subject: [GHC] #14846: Renamer hangs (because of -XInstanceSigs?) In-Reply-To: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> References: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> Message-ID: <066.98e9ddbc36eb746e34913be9b3530d64@haskell.org> #14846: Renamer hangs (because of -XInstanceSigs?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: InstanceSigs | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, this program //doesn't// hang—it actually produces a stack overflow after a certain amount of time! {{{ $ time ~/Software/ghc2/inplace/bin/ghc-stage2 Bug.hs[1 of 1] Compiling Bug ( Bug.hs, Bug.o ) stack overflow: use +RTS -K to increase it real 0m18.986s user 0m18.472s sys 0m0.540s $ ~/Software/ghc2/inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 8.5.20180221 }}} Here's what this looks like in `-ddump-tc-trace`: {{{ runStage interact with inerts { workitem = [WD] $dStructI_a1MK {0}:: StructI (Structured a_a1LU[sk:4] (cls_a1Li[ssk:2] |> {co_a1M2} ->_N _N)) (CDictCan) addFunDepWork [WD] $dStructI_a1MK {0}:: StructI (Structured a_a1LU[sk:4] (cls_a1Li[ssk:2] |> {co_a1M2} ->_N _N)) arising from a use of ‘struct’ at Bug.hs:32:12-17 False arising from the type signature for: i :: forall (a :: Struct cls). StructI a => Hom ríki_a1Lj[ssk:2] a a at Bug.hs:31:8-42 True arising from a functional dependency between constraints: ‘StructI (Structured a_a1LU[sk:4] (cls_a1Li[ssk:2] |> {co_a1M2} ->_N _N))’ arising from a use of ‘struct’ at Bug.hs:32:12-17 ‘StructI a_a1LU[sk:4]’ arising from the type signature for: i :: forall (a :: Struct cls). StructI a => Hom ríki_a1Lj[ssk:2] a a at Bug.hs:31:8-42 at Bug.hs:32:12-17 False end stage interact with inerts } runStage top-level reactions { workitem = [WD] $dStructI_a1MK {0}:: StructI (Structured a_a1LU[sk:4] (cls_a1Li[ssk:2] |> {co_a1M2} ->_N _N)) (CDictCan) doTopReact [WD] $dStructI_a1MK {0}:: StructI (Structured a_a1LU[sk:4] (cls_a1Li[ssk:2] |> {co_a1M2} ->_N _N)) (CDictCan) *** Exception: stack overflow }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 23:02:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 23:02:50 -0000 Subject: [GHC] #14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)? In-Reply-To: <051.a778d1e6d6328a1b4ad713bf62d01c81@haskell.org> References: <051.a778d1e6d6328a1b4ad713bf62d01c81@haskell.org> Message-ID: <066.a4d7b448c6fad8d62876704a4069cbfa@haskell.org> #14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): Note that the `(:-)` part is not needed to trigger this: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module Bug where data Dict c where Dict :: c => Dict c class (a => b) => Implies a b instance (a => b) => Implies a b iota1 :: (() => a) => Dict a iota1 = Dict iota2 :: Implies () a => Dict a iota2 = Dict }}} Note that `iota1` typechecks but `iota2` does not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 23:07:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 23:07:42 -0000 Subject: [GHC] #14835: QuantifiedConstraints: Can't deduce "(a, b)" from "a" and "b" In-Reply-To: <051.57aa3dd69186275a0a16899ee990e8c4@haskell.org> References: <051.57aa3dd69186275a0a16899ee990e8c4@haskell.org> Message-ID: <066.2bb97b4ddb5bbc4bb23fa934ad3a5302@haskell.org> #14835: QuantifiedConstraints: Can't deduce "(a, b)" from "a" and "b" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14833 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14833 Comment: I think this is another manifestation of #14833. Here's an analogous removal of cruft for this ticket: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module Bug where data Dict c where Dict :: c => Dict c class (a => b) => Implies a b instance (a => b) => Implies a b curryC1 :: ((a, b) => c) => Dict (Implies a (Implies b c)) curryC1 = Dict curryC2 :: Implies (a, b) c => Dict (Implies a (Implies b c)) curryC2 = Dict }}} Note that `curryC1` typechecks, but `curryC2` does not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 23:08:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 23:08:12 -0000 Subject: [GHC] #14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)? In-Reply-To: <051.a778d1e6d6328a1b4ad713bf62d01c81@haskell.org> References: <051.a778d1e6d6328a1b4ad713bf62d01c81@haskell.org> Message-ID: <066.5f2ae40b8b403d342aaaf41c54dcbd25@haskell.org> #14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14835 Comment: #14835 smells similar to this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 23:23:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 23:23:56 -0000 Subject: [GHC] #14840: QuantifiedConstraints: Can't define class alias In-Reply-To: <051.efc0726cd0630f1f9a6cfd923f4eea44@haskell.org> References: <051.efc0726cd0630f1f9a6cfd923f4eea44@haskell.org> Message-ID: <066.8b8699f8b1406badecab3733b3164bd3@haskell.org> #14840: QuantifiedConstraints: Can't define class alias -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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'm not sure that this is a bug. Here's a reduced version of your first program: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module Bug where data T a class C1 a class (forall a. cls (T a)) => C2 cls instance (forall a. cls (T a)) => C2 cls }}} Note that this works without `PolyKinds`, which should give you an idea of the underlying issue. If you compile this with `-fprint-explicit-kinds`, the error message is more enlightening: {{{ Bug.hs:12:10: error: • Could not deduce: cls (T k0 a) from the context: forall (a :: k). cls (T k a) bound by an instance declaration: forall k (cls :: * -> Constraint). (forall (a :: k). cls (T k a)) => C2 cls at Bug.hs:12:10-40 • In the ambiguity check for an instance declaration To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the instance declaration for ‘C2 cls’ | 12 | instance (forall a. cls (T a)) => C2 cls | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} You can fix this by explicitly binding the kind of `a`: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module Bug where data T a class C1 a class (forall k (a :: k). cls (T a)) => C2 cls instance (forall k (a :: k). cls (T a)) => C2 cls }}} With that in mind, here's the fixed version of your first program: {{{#!hs {-# Language TypeInType, MultiParamTypeClasses, TypeFamilies, FlexibleContexts, FunctionalDependenc ies, AllowAmbiguousTypes, QuantifiedConstraints, GADTs, ConstraintKinds, KindSignatures, RankNTypes , FlexibleInstances, UndecidableInstances, TypeOperators #-} import Data.Kind class Reifies s a | s -> a where reflect :: proxy s -> a newtype Lift :: forall k. (Type -> Constraint) -> Type -> k -> Type where Lift :: a -> Lift cls a s data family Def :: (k -> Constraint) -> (k -> Type) class (forall k (s :: k) a. Reifies s (Def cls a) => cls (Lift cls a s)) => ReifiableConstraint cls instance (forall k (s :: k) a. Reifies s (Def cls a) => cls (Lift cls a s)) => ReifiableConstraint cls }}} The program in comment:1 seems to be of an entirely different nature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 23:34:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 23:34:20 -0000 Subject: [GHC] #14822: -XQuantifiedConstraints: Turn term-level entailments (:-) into constraints (=>) In-Reply-To: <051.11128ae44d764b8f1b3394d8184f1010@haskell.org> References: <051.11128ae44d764b8f1b3394d8184f1010@haskell.org> Message-ID: <066.c5ec0106e51964fbac72c859b1b1a285@haskell.org> #14822: -XQuantifiedConstraints: Turn term-level entailments (:-) into constraints (=>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: invalid | Keywords: | QuantifiedConstraints, wipT2893 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: => invalid Comment: I fully agree with kcsongor's analysis. This is essentially asking for a way to violate the open-world assumption, which isn't going to fly. If you want to use `(SBoolI b, SBoolI b') => Funny b b'` as a quantified constraint, then write an instance for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 23:37:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 23:37:37 -0000 Subject: [GHC] #14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int)) In-Reply-To: <051.f7a27f9ae9b44fe3d201fa376deb4e42@haskell.org> References: <051.f7a27f9ae9b44fe3d201fa376deb4e42@haskell.org> Message-ID: <066.02918420909c1217a4f9296c84bb89c7@haskell.org> #14748: Infer context for Data instance of (data Foo f = Foo (f Bool) (f Int)) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: wontfix | Keywords: | QuantifiedConstraints wipT2893, | deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix Comment: Closing, since this is neither how we want to tackle this problem, nor a solution that will work most of the time, as per comment:1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 23:43:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 23:43:46 -0000 Subject: [GHC] #14799: QuantifiedConstraints: Problems with Typeable In-Reply-To: <051.12e070493552ed2932e8381c578bd458@haskell.org> References: <051.12e070493552ed2932e8381c578bd458@haskell.org> Message-ID: <066.8fcce9226bfafc22fbca33efe8f6e65c@haskell.org> #14799: QuantifiedConstraints: Problems with Typeable -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints, wipT2893 Operating System: 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 your first example didn't compile for me: {{{ Bug.hs:9:31: error: parse error on input ‘@’ | 9 | a (MkEx (_::xx)) = typeRep @_ @xx Proxy | ^ }}} So I added `TypeApplications`: {{{#!hs {-# Language GADTs, ConstraintKinds, ScopedTypeVariables, QuantifiedConstraints #-} {-# Language TypeApplications #-} import Data.Typeable data Ex cls where MkEx :: cls xx => xx -> Ex cls a :: Ex Typeable -> TypeRep a (MkEx (_::xx)) = typeRep @_ @xx Proxy b :: (forall xx. cls xx => Typeable xx) => Ex cls -> TypeRep b (MkEx (_::xx)) = typeRep @_ @xx Proxy c :: (forall xx. cls xx => Show xx) => Ex cls -> String c (MkEx xx) = show xx }}} And now it compiles! So I'm not sure what you're doing differently. (Please make sure you've given us all the language extensions/flags you're using—it makes a huge difference!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 23:46:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 23:46:14 -0000 Subject: [GHC] #14733: Won't use (forall xx. f xx) with -XQuantifiedConstraints In-Reply-To: <051.d6dd7c53fb2316d2a32445d192b9d697@haskell.org> References: <051.d6dd7c53fb2316d2a32445d192b9d697@haskell.org> Message-ID: <066.67085e7c56b01f52d3d0da3d3ac7bf81@haskell.org> #14733: Won't use (forall xx. f xx) with -XQuantifiedConstraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | QuantifiedConstraints, wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: This featurette was fixed in c477f53799deb46b4987ac788ad67d1bcbb8eb0c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 23:50:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 23:50:14 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.c58858fdeffce22d0e2449e5866af1f4@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #2893 Comment: The "`Implies`" in {{{(c `Implies` Show)}}} is the `=>` in the quantified constraint `(c => Show)`. Quantified constraints also allow you to write `forall a. Monoid a`. Or, to put things another way, this is a duplicate of #2893, which tracks the implementation of `QuantifiedConstraints`. I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 23 23:51:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Feb 2018 23:51:18 -0000 Subject: [GHC] #2893: Implement "Quantified constraints" proposal In-Reply-To: <045.2638646abdcf216191d07c9810407703@haskell.org> References: <045.2638646abdcf216191d07c9810407703@haskell.org> Message-ID: <060.82179fe02994bda59c89d86c090ea86b@haskell.org> #2893: Implement "Quantified constraints" proposal -------------------------------------+------------------------------------- Reporter: porges | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.10.1 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5927 | Differential Rev(s): Phab:D4353 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #5927 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 00:12:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 00:12:35 -0000 Subject: [GHC] #12524: RFC: Allow prefixing result evaluated at GHCi prompt In-Reply-To: <051.37f7bc8117fcf9b4c55eab131373e4e2@haskell.org> References: <051.37f7bc8117fcf9b4c55eab131373e4e2@haskell.org> Message-ID: <066.e37db7029bb12ac817fd7daaa249c915@haskell.org> #12524: RFC: Allow prefixing result evaluated at GHCi prompt -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: lowest | Milestone: Component: GHCi | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * status: new => closed * resolution: => wontfix Comment: Close -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 00:14:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 00:14:23 -0000 Subject: [GHC] #14799: QuantifiedConstraints: Problems with Typeable In-Reply-To: <051.12e070493552ed2932e8381c578bd458@haskell.org> References: <051.12e070493552ed2932e8381c578bd458@haskell.org> Message-ID: <066.65298d2dca9f652978a87f3e1a72b586@haskell.org> #14799: QuantifiedConstraints: Problems with Typeable -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | QuantifiedConstraints, wipT2893 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: => fixed Comment: Seems like Simon's latest patch fixed this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 00:17:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 00:17:53 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.3ef146d1b0ee260835b9277b27b56b7a@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Oh dear. I now realize that my heart was in the right place when I wrote comment:9, but I goofed up several key details. I had written this instance: {{{#!hs instance (forall f b. Applicative f => Coercible (f (inner b)) (f (Wrapped inner b)), Traversable inner) => Traversable (Wrapped inner) where traverse :: forall f a b. Applicative f => (a -> f b) -> Wrapped inner a -> f (Wrapped inner b) traverse = coerce (traverse :: (a -> f b) -> Wrapped inner a -> f (Wrapped inner b)) }}} But this is not quite what I wanted. The `f` in the instance context is not the same `f` as the `f` in the type signature as `traverse`, which is crucial. Indeed, the quantified constraint shouldn't go in the instance context at all, but rather in the method type signature itself: {{{#!hs instance Traversable inner => Traversable (Wrapped inner) where traverse :: forall f a b. (Applicative f, forall p q. Coercible p q => Coercible (f p) (f q)) => (a -> f b) -> Wrapped inner a -> f (Wrapped inner b) traverse = coerce (traverse :: (a -> f b) -> Wrapped inner a -> f (Wrapped inner b)) }}} Of course, this isn't going to work either, because that's not actually the type signature for `traverse`. If only that were the case! But wait, there's something interesting going on here. `f` is an instance of `Applicative` and in turn an instance of `Functor`. What exactly //is// `Functor`, anyway? Here's the definition we all know and love: {{{#!hs class Functor f where fmap :: (a -> b) -> f a -> f b }}} If you squint really hard and look at the type signature for `fmap`, it says "if you give me a coercion from `a` to `b`, then I can produce a coercion from `f a` to `f b`. That's awfully close to `forall a b. Coercible a b => Coercible (f a) (f b)`! I'm going to be bold add suggest adding just that as a superclass of `Functor`: {{{#!hs class (forall a b. Coercible a b => Coercible (f a) (f b)) => Functor f }}} (This is adapted from a similar suggestion [https://ghc.haskell.org/trac/ghc/ticket/9123#comment:3 here], which predates `QuantifiedConstraints`.) If we did this, we'd be able to newtype-derive `Traversable` instances with no further changes, which is awesome! The downside, of course, is that we'd have to add a quantified constraint as a superclass of a Haskell Report class, at which many people would (understandably) turn up their noses. If that option is too unpalatable, an alternative would be to add an additional class method to `Traversable` with the right context: {{{#!hs class (Functor t, Foldable t) => Traversable t where traverse :: Applicative f => (a -> f b) -> t a -> f (t b) traverse' :: (Applicative f, forall p q. Coercible p q => Coercible (f p) (f q)) => (a -> f b) -> t a -> f (t b) traverse' = traverse }}} Then, folks who really care about performance could implement `traverse' = coerce (traverse' :: ...)` themselves and use that. However, you still wouldn't be able to newtype-derive `Traversable` with this approach, and it's rather unsatisfying in that performance-minded programmers would have to switch over all of their `traverse`s to `traverse'`s. (And arguably, //every// programmer should be performance-minded anyway!) In any case, this situation is clearly more complicated than I originally imagined, and I imagine that any solution we could pick will have its share of drawbacks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 00:20:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 00:20:41 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.3232d4ca5747295e2c9e466b3bbca8d0@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | QuantifiedConstraints, deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #2893 Comment: We've decided not to hack an unsafe deriving strategy into GHC, and instead go with `QuantifiedConstraints`. Therefore, closing in favor of #2893. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 00:27:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 00:27:24 -0000 Subject: [GHC] #11826: unsafe causes bug, news @ 11 In-Reply-To: <051.d2b6ea87ae6854f82ecff29408224987@haskell.org> References: <051.d2b6ea87ae6854f82ecff29408224987@haskell.org> Message-ID: <066.98253f3271a7c29926aff7b3fc057848@haskell.org> #11826: unsafe causes bug, news @ 11 -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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 RyanGlScott): * status: new => closed * resolution: => invalid Comment: Indeed, I'm going to chalk this up as not-a-bug unless there's compelling reason to believe otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 00:27:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 00:27:49 -0000 Subject: [GHC] #13153: Several Traversable instances have an extra fmap In-Reply-To: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> References: <045.14b8729ab63f00afb666b5ab8f62ee3b@haskell.org> Message-ID: <060.455e1f5f168b1e7170b88ae32bec1482@haskell.org> #13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): If only we had `mapTraverse` instead of `traverse` as the class method, none of this mess would be necessary. That would obviously be a hard sell for backwards compatibility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 00:29:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 00:29:37 -0000 Subject: [GHC] #14542: Renamer / typechecker hang (UndecidableSuperClasses) In-Reply-To: <051.853153405275572272973f4f54ae92da@haskell.org> References: <051.853153405275572272973f4f54ae92da@haskell.org> Message-ID: <066.0c6fef8acff312dd589d522e2fbfc799@haskell.org> #14542: Renamer / typechecker hang (UndecidableSuperClasses) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: invalid | Keywords: | UndecidableSuperClasses 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: => invalid Comment: Per comment:1, this doesn't seem to be a use case for `UndecidableSuperClasses` that should reasonably terminate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 00:40:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 00:40:14 -0000 Subject: [GHC] #14840: QuantifiedConstraints: Can't define class alias In-Reply-To: <051.efc0726cd0630f1f9a6cfd923f4eea44@haskell.org> References: <051.efc0726cd0630f1f9a6cfd923f4eea44@haskell.org> Message-ID: <066.095f57d9c8b978b4ad38765c687ed4e0@haskell.org> #14840: QuantifiedConstraints: Can't define class alias -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | QuantifiedConstraints wipT2893 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: => fixed Comment: Thanks! And comment:1 works with tricks but probably isn't much use once defined {{{#!hs class (a => b) => (a |- b) instance (a => b) => (a |- b) class (forall xx. f xx |- g xx) => f |~ g instance (forall xx. f xx |- g xx) => f |~ g class (forall xx. f xx |- exists) => Exists1 f exists instance (forall xx. f xx |- exists) => Exists1 f exists class exists => Exists2 f exists instance exists => Exists2 f exists class (Exists1 f |~ Exists2 f) => Exists (f::k -> Constraint) where instance (Exists1 f |~ Exists2 f) => Exists (f::k -> Constraint) where }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 01:12:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 01:12:19 -0000 Subject: [GHC] #14844: SpecConstr also non-recursive function In-Reply-To: <046.efe4b52b55047d5007c336d909140c96@haskell.org> References: <046.efe4b52b55047d5007c336d909140c96@haskell.org> Message-ID: <061.a7d308f004538d698c484c070f270756@haskell.org> #14844: SpecConstr also non-recursive function -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): See also my closing thoughts in Trac:855#comment:12. TLDR; Integrate SpecConstr into the simplifier as a fallback for when the inliner bails out. May even apply to non-recursive bindings, at least when there's only one call pattern. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 03:04:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 03:04:56 -0000 Subject: [GHC] #1974: length "foo" doesn't work with -XOverloadedStrings In-Reply-To: <045.c32ce584b57226e4b25ae684f879f7a5@haskell.org> References: <045.c32ce584b57226e4b25ae684f879f7a5@haskell.org> Message-ID: <060.05253c3a71a9b46665e5993affbe62bf@haskell.org> #1974: length "foo" doesn't work with -XOverloadedStrings -------------------------------------+------------------------------------- Reporter: ganesh | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.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 sjakobi): * status: new => closed * resolution: => fixed Comment: Replying to [comment:9 parcs]: > Have you considered changing the instance declaration from > > {{{ > instance IsString String where > }}} > > to > > {{{ > instance (a ~ Char) => IsString [a] where > }}} > > This new instance will make `length "foo"` happily typecheck, but it will also overlap with other `IsString` instances of the form `[T]`. (Though I don't think such instances are common in practice.) That change with in GHC-8.0 / base-4.9: {{{#!hs GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help > length "foo" 3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 03:34:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 03:34:59 -0000 Subject: [GHC] #8597: Git Hook script to prevent large binary blobs being checked in In-Reply-To: <042.1f60f889f27cefcd4aaab3c10659d3bb@haskell.org> References: <042.1f60f889f27cefcd4aaab3c10659d3bb@haskell.org> Message-ID: <057.7c993ad3f14410bdc3445019aa948ce1@haskell.org> #8597: Git Hook script to prevent large binary blobs being checked in -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): In my experience `arc diff` reliably warns about binary files. Is this good enough or is there more to do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 16:18:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 16:18:11 -0000 Subject: [GHC] #13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown In-Reply-To: <049.12eb233680e8d62e08f397274c91a741@haskell.org> References: <049.12eb233680e8d62e08f397274c91a741@haskell.org> Message-ID: <064.80c1eeabe15c4f8b8f34493f2cde3961@haskell.org> #13851: Change in specialisation(?) behaviour since 8.0.2 causes 6x slowdown -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1-rc2 Resolution: | Keywords: inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => normal Comment: In light of comment:6 I'm going to downgrade the priority and demilestone this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 17:16:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 17:16:58 -0000 Subject: [GHC] #14848: -XDuplicateRecordFields breaks record expression splices Message-ID: <048.60548a7facfb2bb72ce43f7899267ddd@haskell.org> #14848: -XDuplicateRecordFields breaks record expression splices -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- {{{ {-# language TemplateHaskell #-} {-# language DuplicateRecordFields #-} module Lib where import Language.Haskell.TH import Language.Haskell.TH.Syntax data A = A {x :: Int, y :: String} a = A 3 "test" test = $([e|case a of A {x = b} -> b|]) }}} Without `DuplicateRecordFields` it compiles correctly so `test = 3` but with `DuplicateRecordFields` enabled it gives: {{{ • Illegal variable name: ‘$sel:x:A’ When splicing a TH expression: case Lib.a of (Lib.A {Lib.$sel:x:A = b_0}) -> b_0 • In the untyped splice: $([| case a of { A {x = b} -> b } |]) }}} Additionally, there doesn't seem to be a workaround for munging the name manually, since the `$sel:x:A` name is the one actually in scope, there is no `A.x` like there would be normally, even when the label is not a duplicate. Is there a way to get around this? Ex: by changing the binding name somehow manually? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 18:34:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 18:34:44 -0000 Subject: [GHC] #14848: -XDuplicateRecordFields breaks record expression splices In-Reply-To: <048.60548a7facfb2bb72ce43f7899267ddd@haskell.org> References: <048.60548a7facfb2bb72ce43f7899267ddd@haskell.org> Message-ID: <063.2e61453443eccda33c0d848ccb310fd7@haskell.org> #14848: -XDuplicateRecordFields breaks record expression splices -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ORF 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 RyanGlScott): * keywords: => ORF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 18:44:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 18:44:05 -0000 Subject: [GHC] #14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics Message-ID: <044.8f485efed694e393dbe4d64e7f5d45ed@haskell.org> #14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See https://mail.haskell.org/pipermail/libraries/2018-February/028562.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 23:51:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 23:51:29 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.65aa550e9cc79be368ce6bed81780465@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | QuantifiedConstraints, deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Are there some tests to add (to the `QuantifiedConstraints` branch) to exemplify the solutions here and make sure they stay working? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 24 23:57:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Feb 2018 23:57:38 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.0082b46e3bc3e80aa4a0b196faba9c08@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | QuantifiedConstraints, deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Sure. Here's a test adapted from the original post: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} import Data.Coerce import Data.Kind class Monad m => MonadJoin m where join_ :: m (m a) -> m a newtype T m a = T (m a) deriving (Functor, Applicative, Monad) type Representational1 f = (forall a b. Coercible a b => Coercible (f a) (f b) :: Constraint) instance (MonadJoin m, Representational1 m) => MonadJoin (T m) where join_ = coerce @(forall a. m ( m a) -> m a) @(forall a. T m (T m a) -> T m a) join_ }}} As this is essentially the code that this proposed deriving strategy would have generated (except with `unsafeCoerce` replaced with `coerce`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 00:22:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 00:22:21 -0000 Subject: [GHC] #9793: Some as-patterns could be accepted in pattern synonyms In-Reply-To: <045.e251d4b7f57881692430bb7253319357@haskell.org> References: <045.e251d4b7f57881692430bb7253319357@haskell.org> Message-ID: <060.dddd5d2550fca2f96d73bdb8b3f05972@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.8.3 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:D1666 Wiki Page: | -------------------------------------+------------------------------------- Comment (by typedrat): I'm running up against this right now, and while the idea of contributing to GHC (especially with what may be a non-trivial first submitted change) is daunting, I'd be happy to at least try and do it if a design is decided on. Generally, my use case is trying to fake impredicative types in the specific application of GADT phantom types, and being able to just erase the existential wrapper from view and make it look like perfectly normal pattern matching when it's actually being taken apart would make it "feel" a lot nicer, in my opinion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 02:13:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 02:13:40 -0000 Subject: [GHC] #14850: mallocBytes allows underflow Message-ID: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> #14850: mallocBytes allows underflow -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.0.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Foreign.Marshal.Alloc.html#mallocBytes This function doesn't complain when passed a negative number. Instead you get something like `*** Exception: malloc: resource exhausted (out of memory)` Which is confusing, and probably not consistent across platforms. This came up in https://github.com/tel/saltine/issues/42 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 04:45:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 04:45:54 -0000 Subject: [GHC] #14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics In-Reply-To: <044.8f485efed694e393dbe4d64e7f5d45ed@haskell.org> References: <044.8f485efed694e393dbe4d64e7f5d45ed@haskell.org> Message-ID: <059.56121944b292a2def23f1b9178512fbe@haskell.org> #14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics -------------------------------------+------------------------------------- Reporter: lyxia | Owner: lyxia Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lyxia): * owner: (none) => lyxia -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 04:59:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 04:59:55 -0000 Subject: [GHC] #14841: Inconsistent allocation stats In-Reply-To: <049.f13f2d89e3fd0bbd99d1e3ecd80e2c48@haskell.org> References: <049.f13f2d89e3fd0bbd99d1e3ecd80e2c48@haskell.org> Message-ID: <064.7d12065a9e1cd78e93f948c25785c7af@haskell.org> #14841: Inconsistent allocation stats -------------------------------------+------------------------------------- Reporter: patrickdoc | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: Resolution: | Keywords: GCStats, | RTSStats Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > I'm looking at Criterion internals, and seeing an inconsistency in the > allocations reported by `GCStats` and `RTSStats`. Here is a small > reproduction: > > {{{#!hs > {-# LANGUAGE CPP #-} > module Main where > > import GHC.Stats > import System.Mem (performGC) > > main :: IO () > main = do > runOldThing 1000 > #if __GLASGOW_HASKELL__ >= 802 > putStrLn "Running new:" > runThing 1000 > #endif > > runOldThing :: Int -> IO () > runOldThing n = loop n 0 >> return () > where > loop 0 _ = return 0 > loop count x = do > performGC > stats <- getGCStats > putStrLn $ show (count `mod` 15) ++ ": " ++ show (bytesAllocated > stats - x) ++ " num: " ++ show (numGcs stats) > loop (count-1) (bytesAllocated stats) > > #if __GLASGOW_HASKELL__ >= 802 > runThing :: Int -> IO () > runThing = loop > where > loop 0 = return () > loop n = do > performGC > stats <- getRTSStats > putStrLn $ show (n `mod` 15) ++ ": " ++ show > (gcdetails_allocated_bytes (gc stats)) ++ " num: " ++ show (gcs stats) > loop (n-1) > #endif > }}} > > This code just performs a garbage collection and then prints the stats in > a loop. Here is a snippet of the output. > > {{{ > ... > 4: 8840 num: 1967 > 3: 4880 num: 1968 > 2: 4880 num: 1969 > 1: 4880 num: 1970 > 0: 4880 num: 1971 > 14: 4880 num: 1972 > 13: 4976 num: 1973 > 12: 4976 num: 1974 > 11: 4976 num: 1975 > 10: 4976 num: 1976 > 9: 4976 num: 1977 > 8: 4880 num: 1978 > 7: 4880 num: 1979 > 6: 4880 num: 1980 > 5: 4880 num: 1981 > 4: 8840 num: 1982 > 3: 4880 num: 1983 > 2: 4880 num: 1984 > 1: 4880 num: 1985 > 0: 4880 num: 1986 > 14: 4880 num: 1987 > 13: 4976 num: 1988 > 12: 4976 num: 1989 > 11: 4976 num: 1990 > 10: 4976 num: 1991 > 9: 4976 num: 1992 > 8: 4880 num: 1993 > 7: 4880 num: 1994 > 6: 4880 num: 1995 > 5: 4880 num: 1996 > 4: 8840 num: 1997 > 3: 4880 num: 1998 > 2: 4880 num: 1999 > 1: 4880 num: 2000 > }}} > > On the left, I've included the gc number `mod` 15 to show that exactly > every 15 gcs, there is an extra 4k bytes reported. This output was made > with 8.2.1. > On 7.8.4, 7.10.3, and 8.0.2 it's every 23. And on 8.4.0.20180204 it's > every 9. > > I've played around with extra allocations between garbage collections, > but the interval remained constant. I tried poking around the rts, but > I've been unable to determine if this is a bug or just unavoidable noise. New description: I'm looking at Criterion internals, and seeing an inconsistency in the allocations reported by `GCStats` and `RTSStats`. Here is a small reproduction: {{{#!hs {-# LANGUAGE CPP #-} module Main where import GHC.Stats import System.Mem (performGC) main :: IO () main = do runOldThing 1000 #if __GLASGOW_HASKELL__ >= 802 putStrLn "Running new:" runThing 1000 #endif runOldThing :: Int -> IO () runOldThing n = loop n 0 >> return () where loop 0 _ = return 0 loop count x = do performGC stats <- getGCStats putStrLn $ show (count `mod` 15) ++ ": " ++ show (bytesAllocated stats - x) ++ " num: " ++ show (numGcs stats) loop (count-1) (bytesAllocated stats) #if __GLASGOW_HASKELL__ >= 802 runThing :: Int -> IO () runThing = loop where loop 0 = return () loop n = do performGC stats <- getRTSStats putStrLn $ show (n `mod` 15) ++ ": " ++ show (gcdetails_allocated_bytes (gc stats)) ++ " num: " ++ show (gcs stats) loop (n-1) #endif }}} This code just performs a garbage collection and then prints the stats in a loop. Here is a snippet of the output. {{{ ... 4: 8840 num: 1967 3: 4880 num: 1968 2: 4880 num: 1969 1: 4880 num: 1970 0: 4880 num: 1971 14: 4880 num: 1972 13: 4976 num: 1973 12: 4976 num: 1974 11: 4976 num: 1975 10: 4976 num: 1976 9: 4976 num: 1977 8: 4880 num: 1978 7: 4880 num: 1979 6: 4880 num: 1980 5: 4880 num: 1981 4: 8840 num: 1982 3: 4880 num: 1983 2: 4880 num: 1984 1: 4880 num: 1985 0: 4880 num: 1986 14: 4880 num: 1987 13: 4976 num: 1988 12: 4976 num: 1989 11: 4976 num: 1990 10: 4976 num: 1991 9: 4976 num: 1992 8: 4880 num: 1993 7: 4880 num: 1994 6: 4880 num: 1995 5: 4880 num: 1996 4: 8840 num: 1997 3: 4880 num: 1998 2: 4880 num: 1999 1: 4880 num: 2000 }}} On the left, I've included the gc number `mod` 15 to show that exactly every 15 gcs, there is an extra 4k bytes reported. This output was made with 8.2.1. On 7.8.4, 7.10.3, and 8.0.2 it's every 23. And on 8.4.0.20180204 it's every 14. I've played around with extra allocations between garbage collections, but the interval remained constant. I tried poking around the rts, but I've been unable to determine if this is a bug or just unavoidable noise. -- Comment (by patrickdoc): I can't count in mod 15 apparently; on GHC HEAD it occurs every 14. I've traced the 15 -> 14 change to this commit: https://phabricator.haskell.org/D3658, which increases the size of `GCDetails` and `RTSStats` with an extra field. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 05:15:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 05:15:34 -0000 Subject: [GHC] #14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics In-Reply-To: <044.8f485efed694e393dbe4d64e7f5d45ed@haskell.org> References: <044.8f485efed694e393dbe4d64e7f5d45ed@haskell.org> Message-ID: <059.6fbd60899f78ff3d5426682830a5f0a5@haskell.org> #14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics -------------------------------------+------------------------------------- Reporter: lyxia | Owner: lyxia Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.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:D4447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lyxia): * differential: => phab:D4447 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 06:30:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 06:30:43 -0000 Subject: [GHC] #14850: mallocBytes allows underflow In-Reply-To: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> References: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> Message-ID: <060.cb9371412cbadad71b3231390afe0b93@haskell.org> #14850: mallocBytes allows underflow -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) Comment: `mallocBytes` does a conversion from `Int` (signed) to `CSize` (unsigned). On 64bit Linux system `Word` and `CSize` have the same size so this function could use `Word` as argument, but I wonder if this is always the case. In any case I think the argument should be an unsigned type (`Word`, `CSize`, or something else). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 10:07:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 10:07:55 -0000 Subject: [GHC] #13011: Simplifier ticks exhausted: a 10-line case In-Reply-To: <052.bf42032c1e22b5cab8fc1d52eefb6688@haskell.org> References: <052.bf42032c1e22b5cab8fc1d52eefb6688@haskell.org> Message-ID: <067.898baf65a7d1a0293cbe927fb60eeb00@haskell.org> #13011: Simplifier ticks exhausted: a 10-line case -------------------------------------+------------------------------------- Reporter: L.K.Rebellion | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Simplifier | ticks exhausted Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #8319 #12776 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by L.K.Rebellion): * priority: high => lowest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 12:37:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 12:37:03 -0000 Subject: [GHC] #14834: Executable have problems with DWARF debug information In-Reply-To: <045.869f13e723668fe5f6114e93abdf8ce6@haskell.org> References: <045.869f13e723668fe5f6114e93abdf8ce6@haskell.org> Message-ID: <060.bf5a2111aad1d81dc99c714785c10fe4@haskell.org> #14834: Executable have problems with DWARF debug information -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Debugging) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 12:38:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 12:38:16 -0000 Subject: [GHC] #14834: Executable have problems with DWARF debug information In-Reply-To: <045.869f13e723668fe5f6114e93abdf8ce6@haskell.org> References: <045.869f13e723668fe5f6114e93abdf8ce6@haskell.org> Message-ID: <060.cf1698607bea4a90f50bf9a927efddce@haskell.org> #14834: Executable have problems with DWARF debug information -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Debugging) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @bgamari: any idea what's going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 16:21:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 16:21:58 -0000 Subject: [GHC] #14846: Renamer hangs (because of -XInstanceSigs?) In-Reply-To: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> References: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> Message-ID: <066.3d164711f792a54ee02567ed7e653141@haskell.org> #14846: Renamer hangs (because of -XInstanceSigs?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: InstanceSigs | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): In case you're worried about that `UndecidableInstances` part, here's a version that doesn't use `UndecidableInstances`: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy type Cat ob = ob -> ob -> Type data Struct :: (k -> Constraint) -> Type where S :: Proxy (a::k) -> Struct (cls::k -> Constraint) type Structured a cls = (S ('Proxy :: Proxy a)::Struct cls) data AStruct :: Struct cls -> Type where AStruct :: cls a => AStruct (Structured a cls) class StructI xx (structured::Struct (cls :: k -> Constraint)) where struct :: AStruct structured instance (Structured xx cls ~ structured, cls xx) => StructI xx structured where struct :: AStruct (Structured xx cls) struct = AStruct data Hom :: Cat k -> Cat (Struct cls) where class Category (cat::Cat ob) where i :: StructI xx a => ríki a a instance Category ríki => Category (Hom ríki :: Cat (Struct cls)) where i :: forall xx a. StructI xx a => Hom ríki a a i = case struct :: AStruct (Structured a cls) of }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 17:24:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 17:24:27 -0000 Subject: [GHC] #14851: "Pattern match has inaccessible right hand side" with TypeRep Message-ID: <047.2738bd9dfc4a4e69d806d1613c57324e@haskell.org> #14851: "Pattern match has inaccessible right hand side" with TypeRep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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 I say {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns #-} module Bug where import Type.Reflection pattern X arg <- (checkFun -> arg) checkFun :: TypeRep fun -> a checkFun = undefined f x = case (x, True) of (X _, _) -> 5 _ -> 6 g x = case x of (X _) -> 5 _ -> 6 }}} I get {{{ Bug.hs:13:11: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In a case alternative: (X _, _) -> ... | 13 | (X _, _) -> 5 | ^^^^^^^^^^^^^ }}} I'm troubled by two things: 1. There's nothing inaccessible about my right-hand side. 2. This happens only for `f`, not `g`. If there's no tuple, there's no problem. Note that this problems requires `TypeRep`. Even another polykinded tycon (like `Proxy`) didn't trigger the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 17:31:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 17:31:22 -0000 Subject: [GHC] #14850: mallocBytes allows underflow In-Reply-To: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> References: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> Message-ID: <060.ee2fc2d7f078645bdf90614146a28bc5@haskell.org> #14850: mallocBytes allows underflow -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by wyager): I agree, changing the argument type to Word is probably the most semantically sensible approach. It has the nice effect of shifting the responsibility of underflow detection to the caller. I think the ecosystem in general could benefit from a wide-ranging examination of whether “Int” is actually appropriate (indexing, lengths, etc.). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 17:59:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 17:59:16 -0000 Subject: [GHC] #14291: Tests tend to fail in the ext-interp way when split sections is enabled In-Reply-To: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> References: <046.50939ac6d09fd8ac7c487275ec7ee681@haskell.org> Message-ID: <061.68642a80fd4ceec0a9edab725a8ffa4a@haskell.org> #14291: Tests tend to fail in the ext-interp way when split sections is enabled -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14328 | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4431 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.6.1 => 8.4.1 Comment: Merged with b4e32780a976193208eebbddf789eeb80351ac95. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 18:06:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 18:06:56 -0000 Subject: [GHC] #14834: Executable have problems with DWARF debug information In-Reply-To: <045.869f13e723668fe5f6114e93abdf8ce6@haskell.org> References: <045.869f13e723668fe5f6114e93abdf8ce6@haskell.org> Message-ID: <060.7429783217dda3ac444e60f6da45dd99@haskell.org> #14834: Executable have problems with DWARF debug information -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Debugging) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, not off hand. I've been meaning to run out DWARF output through `dwarflint` for quite some time. Perhaps it will yield a more helpful error. It looks like the error above comes from https://chromium.googlesource.com/native_client/nacl- binutils/+/upstream/master/binutils/dwarf.c#133. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 18:22:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 18:22:36 -0000 Subject: [GHC] #14851: "Pattern match has inaccessible right hand side" with TypeRep In-Reply-To: <047.2738bd9dfc4a4e69d806d1613c57324e@haskell.org> References: <047.2738bd9dfc4a4e69d806d1613c57324e@haskell.org> Message-ID: <062.aca7a0942ba1882e12fb6a66e2d651df@haskell.org> #14851: "Pattern match has inaccessible right hand side" with TypeRep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings, | 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 RyanGlScott): * keywords: => PatternMatchWarnings, PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 20:00:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 20:00:02 -0000 Subject: [GHC] #14850: mallocBytes allows underflow In-Reply-To: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> References: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> Message-ID: <060.f9de016e98acf19c8d3965c2f7474665@haskell.org> #14850: mallocBytes allows underflow -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Would someone care to offer a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 20:54:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 20:54:20 -0000 Subject: [GHC] #14852: Implement the "Eq1, Ord1, Read1, Show1 instances in GHC.Generics" proposal Message-ID: <044.7b12f61a224921b6942f6ced1273b01e@haskell.org> #14852: Implement the "Eq1, Ord1, Read1, Show1 instances in GHC.Generics" proposal -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://mail.haskell.org/pipermail/libraries/2018-February/028570.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 20:54:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 20:54:34 -0000 Subject: [GHC] #14852: Implement the "Eq1, Ord1, Read1, Show1 instances in GHC.Generics" proposal In-Reply-To: <044.7b12f61a224921b6942f6ced1273b01e@haskell.org> References: <044.7b12f61a224921b6942f6ced1273b01e@haskell.org> Message-ID: <059.dfad1b471762ea58b35d1f4bd45939f5@haskell.org> #14852: Implement the "Eq1, Ord1, Read1, Show1 instances in GHC.Generics" proposal -------------------------------------+------------------------------------- Reporter: lyxia | Owner: lyxia Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lyxia): * owner: (none) => lyxia -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 21:07:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 21:07:37 -0000 Subject: [GHC] #14853: Implement the "Semigroup and Monoid instances in Data.Functor.Product and friends" proposal Message-ID: <044.e240e6be6be3995e146fe13b744930e4@haskell.org> #14853: Implement the "Semigroup and Monoid instances in Data.Functor.Product and friends" proposal -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://mail.haskell.org/pipermail/libraries/2018-February/028570.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 21:07:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 21:07:48 -0000 Subject: [GHC] #14853: Implement the "Semigroup and Monoid instances in Data.Functor.Product and friends" proposal In-Reply-To: <044.e240e6be6be3995e146fe13b744930e4@haskell.org> References: <044.e240e6be6be3995e146fe13b744930e4@haskell.org> Message-ID: <059.c968d2ca47011b241b18405f74950b53@haskell.org> #14853: Implement the "Semigroup and Monoid instances in Data.Functor.Product and friends" proposal -------------------------------------+------------------------------------- Reporter: lyxia | Owner: lyxia Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lyxia): * owner: (none) => lyxia -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 21:12:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 21:12:50 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases Message-ID: <046.96a71a8566a954e21839a1a60572305e@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Context: I was profiling a no-op rebuild (build once, do incremental build with nothing changed) of a large code base. It takes `35.829s`, and according to the profile about `20%` of the time is spent in `mkFastStringByteString`. I run it with `-dfaststring-stats +RTS -s` and got: {{{ FastString stats: size: 4091 entries: 829959 longest chain: 268 has z-encoding: 0% 50,011,906,640 bytes allocated in the heap 7,936,277,664 bytes copied during GC 3,106,526,336 bytes maximum residency (8 sample(s)) 123,108,224 bytes maximum slop 10169 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 117 colls, 37 par 32.390s 2.293s 0.0196s 0.0911s Gen 1 8 colls, 3 par 19.722s 2.266s 0.2832s 0.6936s Parallel GC work balance: 60.62% (serial 0%, perfect 100%) TASKS: 93 (1 bound, 92 peak workers (92 total), using -N30) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.009s ( 0.009s elapsed) MUT time 277.370s ( 31.261s elapsed) GC time 52.113s ( 4.558s elapsed) EXIT time 0.005s ( 0.001s elapsed) Total time 329.497s ( 35.829s elapsed) Alloc rate 180,307,295 bytes per MUT second Productivity 84.2% of total user, 87.3% of total elapsed }}} That's pretty bad, fitting `800k` elements in `4k` buckets is hard. To confirm this indeed could be improved I changed the size to `2^20` (`1048576`) and also removed division in `hashStr` function (it come up on `perf` profile), like this: {{{ hashStr :: Ptr Word8 -> Int -> Int -- use the Addr to produce a hash value between 0 & m (inclusive) hashStr (Ptr a#) (I# len#) = loop 0# 0# where loop h n | isTrue# (n ==# len#) = I# h | otherwise = loop h2 (n +# 1#) where !c = ord# (indexCharOffAddr# a# n) -- !h2 = (c +# (h *# 128#)) `remInt#` -- hASH_TBL_SIZE# -- NOTE: below is multiplication by 127 (a prime) and division by 2^20, it's by no means the best hashing function !h2 = (c +# ((h `uncheckedIShiftL#` 7#) -# h)) `andI#` hASH_TBL_SIZE_MASK# }}} Here's what I ended up with: {{{ FastString stats: size: 1048576 entries: 829959 longest chain: 8 has z-encoding: 0% 51,012,218,048 bytes allocated in the heap 8,948,377,768 bytes copied during GC 3,543,797,248 bytes maximum residency (8 sample(s)) 139,428,352 bytes maximum slop 10502 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 115 colls, 39 par 32.261s 2.677s 0.0233s 0.2225s Gen 1 8 colls, 3 par 21.786s 2.329s 0.2911s 0.5737s Parallel GC work balance: 48.75% (serial 0%, perfect 100%) TASKS: 93 (1 bound, 92 peak workers (92 total), using -N30) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.008s ( 0.008s elapsed) MUT time 65.508s ( 23.791s elapsed) GC time 54.047s ( 5.006s elapsed) EXIT time 0.007s ( 0.001s elapsed) Total time 119.570s ( 28.806s elapsed) Alloc rate 778,712,134 bytes per MUT second Productivity 54.8% of total user, 82.6% of total elapsed }}} The realtime improvement is nice (`-20%`), but even nicer is the "serial" time improvement, from `329.497s`to `119.570s` (`2.75x` speedup). This is on modified 8.0.2, but the related code looks about the same on HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 21:14:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 21:14:57 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases In-Reply-To: <046.96a71a8566a954e21839a1a60572305e@haskell.org> References: <046.96a71a8566a954e21839a1a60572305e@haskell.org> Message-ID: <061.5349ce80c4aa677e35ea0ae98922a005@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I should note that the vast majority of the calls comes from `getFS :: BinHandle -> IO FastString`, which is used when reading interface files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 21:15:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 21:15:54 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases In-Reply-To: <046.96a71a8566a954e21839a1a60572305e@haskell.org> References: <046.96a71a8566a954e21839a1a60572305e@haskell.org> Message-ID: <061.7cc4fe5cc7d14d0218edc59103e279e9@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 21:40:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 21:40:37 -0000 Subject: [GHC] #14853: Implement the "Semigroup and Monoid instances in Data.Functor.Product and friends" proposal In-Reply-To: <044.e240e6be6be3995e146fe13b744930e4@haskell.org> References: <044.e240e6be6be3995e146fe13b744930e4@haskell.org> Message-ID: <059.93b7ac85aed79a68b305fecdf35fcb51@haskell.org> #14853: Implement the "Semigroup and Monoid instances in Data.Functor.Product and friends" proposal -------------------------------------+------------------------------------- Reporter: lyxia | Owner: lyxia Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.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:D4449 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lyxia): * differential: => phab:D4449 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 21:57:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 21:57:31 -0000 Subject: [GHC] #11777: RTS source code issues In-Reply-To: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> References: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> Message-ID: <061.887fdfd27f84dd1d07edc6f07e81ab5b@haskell.org> #11777: RTS source code issues -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4426, Wiki Page: | Phab:D4427, Phab:D4428 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c969c987ab63db29f305f9a0fd2047bc8156f309/ghc" c969c987/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c969c987ab63db29f305f9a0fd2047bc8156f309" driver/utils/dynwrapper.c: Remove unused variable The variable was already unused when the file was introduced in b35a6ce0e34255d200ddcf341ffc645fd237ea32. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11777 Differential Revision: https://phabricator.haskell.org/D4426 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 21:57:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 21:57:31 -0000 Subject: [GHC] #11777: RTS source code issues In-Reply-To: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> References: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> Message-ID: <061.504a917ee4278a0107a1f54d49244c2e@haskell.org> #11777: RTS source code issues -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4426, Wiki Page: | Phab:D4427, Phab:D4428 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"be498a24250f637471426989b3bdf5f1b18e47bb/ghc" be498a24/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be498a24250f637471426989b3bdf5f1b18e47bb" RTS: Remember to free some pointers Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari, simonmar Subscribers: Phyx, rwbarton, thomie, carter GHC Trac Issues: #11777 Differential Revision: https://phabricator.haskell.org/D4428 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 21:57:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 21:57:31 -0000 Subject: [GHC] #11777: RTS source code issues In-Reply-To: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> References: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> Message-ID: <061.660d0ba8f8fc8ebb86f99c1d73cd180f@haskell.org> #11777: RTS source code issues -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sjakobi Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4426, Wiki Page: | Phab:D4427, Phab:D4428 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cb89ba88d42ab77f9e20d722ec1ab40ec6f8e703/ghc" cb89ba88/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cb89ba88d42ab77f9e20d722ec1ab40ec6f8e703" RTS: Remove unused retainer schemes Reviewers: bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11777 Differential Revision: https://phabricator.haskell.org/D4427 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 21:58:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 21:58:12 -0000 Subject: [GHC] #11777: RTS source code issues In-Reply-To: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> References: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> Message-ID: <061.86d8af4f816475a5c54ddd6f2837252e@haskell.org> #11777: RTS source code issues -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sjakobi Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 7.10.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4426, Wiki Page: | Phab:D4427, Phab:D4428 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 22:07:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 22:07:19 -0000 Subject: [GHC] #14734: QuantifiedConstraints conflated with impredicative polymorphism? In-Reply-To: <051.b13ce9a287df15f46f4472a3cecc22de@haskell.org> References: <051.b13ce9a287df15f46f4472a3cecc22de@haskell.org> Message-ID: <066.7677d7a63ca9f04df88c81b451ebab74@haskell.org> #14734: QuantifiedConstraints conflated with impredicative polymorphism? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: invalid | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): Ok thanks for the response, I'll keep using aliases -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 22:33:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 22:33:10 -0000 Subject: [GHC] #14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)? In-Reply-To: <051.a778d1e6d6328a1b4ad713bf62d01c81@haskell.org> References: <051.a778d1e6d6328a1b4ad713bf62d01c81@haskell.org> Message-ID: <066.e085e285077bd575ff7f4cf790997ea6@haskell.org> #14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Same as? {{{#!hs {-# Language QuantifiedConstraints, GADTs, FlexibleInstances, MultiParamTypeClasses, ConstraintKinds, UndecidableInstances #-} import Data.Kind import Data.Proxy import Unsafe.Coerce data Dict c where Dict :: c => Dict c class (a => b) => Entails a b instance (a => b) => Entails a b wit :: Dict a -> Dict b -> Dict (Entails (a, b) xx) -> Dict xx wit Dict Dict Dict = Dict }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 22:53:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 22:53:48 -0000 Subject: [GHC] #14855: Implementation of liftA2 for Const has high arity Message-ID: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> #14855: Implementation of liftA2 for Const has high arity -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.2 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: -------------------------------------+------------------------------------- {{{ instance Monoid m => Applicative (Const m) where pure _ = Const mempty liftA2 _ (Const x) (Const y) = Const (x `mappend` y) (<*>) = coerce (mappend :: m -> m -> m) }}} https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Data.Functor.Const.html#line-69 `(<*>)` is implemented with a `coerce` but `liftA2` isn't. Would the following not have better inlining behavior? {{{ liftA2 _ = coerce (mappend :: m -> m -> m) }}} Going further, should the unused argument also be moved to the RHS? What about `pure`? What are the pros and cons compared to this other alternative: {{{ pure = \_ -> mempty liftA2 = \_ -> coerce (mappend :: m -> m -> m) }}} This came up while implementing `Applicative` for `K1` in phab:D4447. `K1` is essentially the same type as `Const` and thus their instances should be identical for the sake of consistency. Is `Const`'s `Applicative` instance already optimal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 22:56:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 22:56:36 -0000 Subject: [GHC] #14855: Implementation of liftA2 for Const has high arity In-Reply-To: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> References: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> Message-ID: <059.c92b22dec82f9e7bc50e54cc94b685ab@haskell.org> #14855: Implementation of liftA2 for Const has high arity -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lyxia): * cc: lyxia (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 22:56:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 22:56:53 -0000 Subject: [GHC] #14318: TH shadowing bind statement triggers -Wunused-matches In-Reply-To: <044.951fdf427e51c6e07b18c7fa19ddd812@haskell.org> References: <044.951fdf427e51c6e07b18c7fa19ddd812@haskell.org> Message-ID: <059.a7d5b35c613d8c87f1d4d874399d1559@haskell.org> #14318: TH shadowing bind statement triggers -Wunused-matches -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.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 lyxia): * cc: lyxia (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 22:57:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 22:57:13 -0000 Subject: [GHC] #14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics In-Reply-To: <044.8f485efed694e393dbe4d64e7f5d45ed@haskell.org> References: <044.8f485efed694e393dbe4d64e7f5d45ed@haskell.org> Message-ID: <059.30456781cac22715b3b3b134a3910ddc@haskell.org> #14849: Add Applicative, Semigroup and Monoid instances in GHC.Generics -------------------------------------+------------------------------------- Reporter: lyxia | Owner: lyxia Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.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:D4447 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lyxia): * cc: lyxia (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 22:57:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 22:57:39 -0000 Subject: [GHC] #14852: Implement the "Eq1, Ord1, Read1, Show1 instances in GHC.Generics" proposal In-Reply-To: <044.7b12f61a224921b6942f6ced1273b01e@haskell.org> References: <044.7b12f61a224921b6942f6ced1273b01e@haskell.org> Message-ID: <059.6c92b37fb2ce3c2842ea9f3718b9c8cd@haskell.org> #14852: Implement the "Eq1, Ord1, Read1, Show1 instances in GHC.Generics" proposal -------------------------------------+------------------------------------- Reporter: lyxia | Owner: lyxia Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lyxia): * cc: lyxia (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 22:57:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 22:57:59 -0000 Subject: [GHC] #14853: Implement the "Semigroup and Monoid instances in Data.Functor.Product and friends" proposal In-Reply-To: <044.e240e6be6be3995e146fe13b744930e4@haskell.org> References: <044.e240e6be6be3995e146fe13b744930e4@haskell.org> Message-ID: <059.6e9133609f9fa703cca37039f63e524d@haskell.org> #14853: Implement the "Semigroup and Monoid instances in Data.Functor.Product and friends" proposal -------------------------------------+------------------------------------- Reporter: lyxia | Owner: lyxia Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.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:D4449 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lyxia): * cc: lyxia (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 23:05:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 23:05:53 -0000 Subject: [GHC] #14318: TH shadowing bind statement triggers -Wunused-matches In-Reply-To: <044.951fdf427e51c6e07b18c7fa19ddd812@haskell.org> References: <044.951fdf427e51c6e07b18c7fa19ddd812@haskell.org> Message-ID: <059.c499ff3d2df5061502d8c6e258a200e2@haskell.org> #14318: TH shadowing bind statement triggers -Wunused-matches -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.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 lyxia: Old description: > {{{ > $(newName "x" >>= \x -> > newName "f" >>= \f -> > lamE [varP f, varP x] > (doE [ bindS (varP x) (listE [varE f `appE` varE x]) > , noBindS (varE x)]) > ) > }}} > > generates the following expression: > > {{{ > \f x -> do > x <- f x > x > }}} > > and `-Wunused-matches` complains that `x` is not used, while both bound > occurrences are in fact used. New description: {{{ {-# LANGUAGE TemplateHaskell #-} module Test where import Language.Haskell.TH m :: (a -> [b]) -> a -> [b] m = $(newName "x" >>= \x -> newName "f" >>= \f -> lamE [varP f, varP x] (doE [ bindS (varP x) (listE [varE f `appE` varE x]) , noBindS (varE x)]) ) }}} The splice generates the following expression: {{{ \f x -> do x <- [f x] x }}} and `-Wunused-matches` complains that `x` is not used, while both bound occurrences are in fact used (the two uses have different types so that's quite certain). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 23:10:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 23:10:23 -0000 Subject: [GHC] #14856: GHC API: Linker failure on loading target multiple times Message-ID: <049.5d72fe6ce564adad9a42ef4e09990bc5@haskell.org> #14856: GHC API: Linker failure on loading target multiple times ----------------------------------------+--------------------------- Reporter: fizzixnerd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.2 Keywords: GHC API Linker | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------- Minimum Working Example: https://github.com/Fizzixnerd/ghc-bug `stack exec -- ghc --version` >The Glorious Glasgow Haskell Compilation System, version 8.2.2 `uname --all` >Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64 GNU/Linux Description: Loading a dynamic module more than once causes a linker failure with the following message: ''' /usr/bin/ld.gold: error: cannot find -lghc_2 collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) *** Exception: ExitFailure 1 ''' `-lghc_2' sometimes is `-lghc_5' or other numbers. Steps to Reproduce: 1) Clone above repo. 2) `stack build` 3) `stack exec mwe-exe` The repo code will use the GHC API to load a string from the file contained in scripts/ named `val'. There are three functions defined in src/Lib.hs. `anotherFunc' should behave normally. `someFunc' should display the bad behavior. Notes: - When using `intero`: intero must be restarted if this bug is encountered at the prompt, or else you will keep getting it over and over again. - I could not figure out how to load it up without using the `-dynamic' flag, but that should probably be checked out too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 25 23:11:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Feb 2018 23:11:09 -0000 Subject: [GHC] #14856: GHC API: Linker failure on loading target multiple times In-Reply-To: <049.5d72fe6ce564adad9a42ef4e09990bc5@haskell.org> References: <049.5d72fe6ce564adad9a42ef4e09990bc5@haskell.org> Message-ID: <064.a3ee0183d9918f51c4684e3e001fc6c0@haskell.org> #14856: GHC API: Linker failure on loading target multiple times -------------------------------+---------------------------------------- Reporter: fizzixnerd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.2 Resolution: | Keywords: GHC API Linker Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Old description: > Minimum Working Example: https://github.com/Fizzixnerd/ghc-bug > > `stack exec -- ghc --version` > >The Glorious Glasgow Haskell Compilation System, version 8.2.2 > > `uname --all` > >Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) > x86_64 GNU/Linux > > Description: Loading a dynamic module more than once causes a linker > failure with the following message: > > ''' > /usr/bin/ld.gold: error: cannot find -lghc_2 > collect2: error: ld returned 1 exit status > `gcc' failed in phase `Linker'. (Exit code: 1) > *** Exception: ExitFailure 1 > ''' > > `-lghc_2' sometimes is `-lghc_5' or other numbers. > > Steps to Reproduce: > 1) Clone above repo. > 2) `stack build` > 3) `stack exec mwe-exe` > > The repo code will use the GHC API to load a string from the file > contained in scripts/ named `val'. There are three functions defined in > src/Lib.hs. `anotherFunc' should behave normally. `someFunc' should > display the bad behavior. > > Notes: > - When using `intero`: intero must be restarted if this bug is > encountered at the prompt, or else you will keep getting it over and over > again. > > - I could not figure out how to load it up without using the `-dynamic' > flag, but that should probably be checked out too. New description: Minimum Working Example: https://github.com/Fizzixnerd/ghc-bug `stack exec -- ghc --version` >The Glorious Glasgow Haskell Compilation System, version 8.2.2 `uname --all` >Linux 4.14.0-3-amd64 #1 SMP Debian 4.14.13-1 (2018-01-14) x86_64 GNU/Linux Description: Loading a dynamic module more than once causes a linker failure with the following message: ''' /usr/bin/ld.gold: error: cannot find -lghc_2 collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) *** Exception: ExitFailure 1 ''' `-lghc_2' sometimes is `-lghc_5' or other numbers. Steps to Reproduce: 1) Clone above repo. 2) `stack build` 3) `stack exec mwe-exe` The repo code will use the GHC API to load a string from the file contained in scripts/ named `val`. There are three functions defined in src/Lib.hs. `anotherFunc` should behave normally. `someFunc' should display the bad behavior. Notes: - When using `intero`: intero must be restarted if this bug is encountered at the prompt, or else you will keep getting it over and over again. - I could not figure out how to load it up without using the `-dynamic' flag, but that should probably be checked out too. -- Comment (by fizzixnerd): fixed formatting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 00:10:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 00:10:10 -0000 Subject: [GHC] #14855: Implementation of liftA2 for Const has high arity In-Reply-To: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> References: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> Message-ID: <059.e49ae070c793f7582ef2801f92965556@haskell.org> #14855: Implementation of liftA2 for Const has high arity -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by lyxia: Old description: > {{{ > instance Monoid m => Applicative (Const m) where > pure _ = Const mempty > liftA2 _ (Const x) (Const y) = Const (x `mappend` y) > (<*>) = coerce (mappend :: m -> m -> m) > }}} > > https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Data.Functor.Const.html#line-69 > > `(<*>)` is implemented with a `coerce` but `liftA2` isn't. Would the > following not have better inlining behavior? > > {{{ > liftA2 _ = coerce (mappend :: m -> m -> m) > }}} > > Going further, should the unused argument also be moved to the RHS? What > about `pure`? What are the pros and cons compared to this other > alternative: > > {{{ > pure = \_ -> mempty > liftA2 = \_ -> coerce (mappend :: m -> m -> m) > }}} > > This came up while implementing `Applicative` for `K1` in phab:D4447. > `K1` is essentially the same type as `Const` and thus their instances > should be identical for the sake of consistency. Is `Const`'s > `Applicative` instance already optimal? New description: {{{ instance Monoid m => Applicative (Const m) where pure _ = Const mempty liftA2 _ (Const x) (Const y) = Const (x `mappend` y) (<*>) = coerce (mappend :: m -> m -> m) }}} https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Data.Functor.Const.html#line-69 `(<*>)` is implemented with a `coerce` but `liftA2` isn't. Would the following not have better inlining behavior? {{{ liftA2 _ = coerce (mappend :: m -> m -> m) }}} Going further, should the unused argument also be moved to the RHS? What about `pure`? What are the pros and cons compared to this other alternative: {{{ pure = \_ -> mempty liftA2 = \_ -> coerce (mappend :: m -> m -> m) }}} This came up while implementing `Applicative` for `K1` in phab:D4447. `K1` is essentially the same type as `Const` and thus their instances should be identical for the sake of consistency. But it's not clear to me whether `Const`'s `Applicative` instance is already optimal. Is it? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 00:11:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 00:11:06 -0000 Subject: [GHC] #14855: Implementation of liftA2 for Const has high arity In-Reply-To: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> References: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> Message-ID: <059.8a66d09e1ade1df67f9c34ab8c8791b1@haskell.org> #14855: Implementation of liftA2 for Const has high arity -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by lyxia: Old description: > {{{ > instance Monoid m => Applicative (Const m) where > pure _ = Const mempty > liftA2 _ (Const x) (Const y) = Const (x `mappend` y) > (<*>) = coerce (mappend :: m -> m -> m) > }}} > > https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Data.Functor.Const.html#line-69 > > `(<*>)` is implemented with a `coerce` but `liftA2` isn't. Would the > following not have better inlining behavior? > > {{{ > liftA2 _ = coerce (mappend :: m -> m -> m) > }}} > > Going further, should the unused argument also be moved to the RHS? What > about `pure`? What are the pros and cons compared to this other > alternative: > > {{{ > pure = \_ -> mempty > liftA2 = \_ -> coerce (mappend :: m -> m -> m) > }}} > > This came up while implementing `Applicative` for `K1` in phab:D4447. > `K1` is essentially the same type as `Const` and thus their instances > should be identical for the sake of consistency. But it's not clear to me > whether `Const`'s `Applicative` instance is already optimal. Is it? New description: {{{ instance Monoid m => Applicative (Const m) where pure _ = Const mempty liftA2 _ (Const x) (Const y) = Const (x `mappend` y) (<*>) = coerce (mappend :: m -> m -> m) }}} https://hackage.haskell.org/package/base-4.10.1.0/docs/src/Data.Functor.Const.html#line-69 `(<*>)` is implemented with a `coerce` but `liftA2` isn't. Would the following not have better inlining behavior? {{{ liftA2 _ = coerce (mappend :: m -> m -> m) }}} Going further, should the unused argument also be moved to the RHS? What about `pure`? What are the pros and cons compared to this other alternative: {{{ pure = \_ -> Const mempty liftA2 = \_ -> coerce (mappend :: m -> m -> m) }}} This came up while implementing `Applicative` for `K1` in phab:D4447. `K1` is essentially the same type as `Const` and thus their instances should be identical for the sake of consistency. But it's not clear to me whether `Const`'s `Applicative` instance is already optimal. Is it? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 00:39:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 00:39:29 -0000 Subject: [GHC] #14699: Core library status for 8.4.1 In-Reply-To: <046.12f775ea02060174a5ac178f457055aa@haskell.org> References: <046.12f775ea02060174a5ac178f457055aa@haskell.org> Message-ID: <061.87626b3899656072ad327926e082c867@haskell.org> #14699: Core library status for 8.4.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Old description: > * `needs revision`: No interface changes needed; only a bounds bump > necessary > * `revised`: Revised bounds uploaded to Hackage > * `needs release`: Waiting for upstream to tag and upload release > * `ready`: Final version has been released > * `on-release`: Final version has been released and submodule bumped > > ||= package =||= status =||= reference =|| > || `Cabal` || needs release || > https://github.com/haskell/cabal/issues/5075 || > || `Win32` || on-release || || > || `array` || revised || || > || `binary` || on-release || || > || `bytestring` || on-release || || > || `containers` || on-release || > https://github.com/haskell/containers/issues/501 || > || `deepseq` || needs revision || || > || `directory` || on-release || || > || `filepath` || on-release || > https://github.com/haskell/filepath/issues/65 || > || `haskeline` || on-release || > https://github.com/judah/haskeline/issues/75 || > || `hpc` || needs release || || > || `mtl` || needs release || https://github.com/haskell/mtl/issues/52 || > || `parallel` || revised || || > || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 > || > || `pretty` || on-release || https://github.com/haskell/pretty/issues/47 > || > || `primitive` || on-release || > https://github.com/haskell/primitive/issues/72 || > || `process` || on-release || > https://github.com/haskell/process/issues/114 || > || `stm` || on-release || #14698 || > || `terminfo` || on-release || > https://github.com/judah/terminfo/issues/27 || > || `text` || on-release || https://github.com/haskell/text/issues/215 || > || `time` || on-release || || > || `transformers` || ready || #14678 || > || `unix` || needs release || https://github.com/haskell/unix/issues/106 > || > || `haddock` || needs release || > https://github.com/haskell/haddock/issues/737 || New description: * `needs revision`: No interface changes needed; only a bounds bump necessary * `revised`: Revised bounds uploaded to Hackage * `needs release`: Waiting for upstream to tag and upload release * `ready`: Final version has been released * `on-release`: Final version has been released and submodule bumped ||= package =||= status =||= reference =|| || `Cabal` || needs release || https://github.com/haskell/cabal/issues/5075 || || `Win32` || on-release || || || `array` || revised || || || `binary` || on-release || || || `bytestring` || on-release || || || `containers` || on-release || https://github.com/haskell/containers/issues/501 || || `deepseq` || needs revision || || || `directory` || on-release || || || `filepath` || on-release || https://github.com/haskell/filepath/issues/65 || || `haskeline` || on-release || https://github.com/judah/haskeline/issues/75 || || `hpc` || needs release || || || `mtl` || on-release || https://github.com/haskell/mtl/issues/52 || || `parallel` || revised || || || `parsec` || on-release || https://github.com/haskell/parsec/issues/86 || || `pretty` || on-release || https://github.com/haskell/pretty/issues/47 || || `primitive` || on-release || https://github.com/haskell/primitive/issues/72 || || `process` || on-release || https://github.com/haskell/process/issues/114 || || `stm` || on-release || #14698 || || `terminfo` || on-release || https://github.com/judah/terminfo/issues/27 || || `text` || on-release || https://github.com/haskell/text/issues/215 || || `time` || on-release || || || `transformers` || ready || #14678 || || `unix` || needs release || https://github.com/haskell/unix/issues/106 || || `haddock` || needs release || https://github.com/haskell/haddock/issues/737 || -- Comment (by bgamari): `mtl` bumped to 2.2.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 01:39:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 01:39:39 -0000 Subject: [GHC] #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations In-Reply-To: <042.4fd9cca9b74b01eb7ff1b72244aeca47@haskell.org> References: <042.4fd9cca9b74b01eb7ff1b72244aeca47@haskell.org> Message-ID: <057.6ae3c3a6704c635a6c624040105b1cde@haskell.org> #14762: Foreign.Marshal.Pool functions use inefficient O(n) operations -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * owner: sighingnow => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 02:28:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 02:28:17 -0000 Subject: [GHC] #13088: Type operator holes don't work infix In-Reply-To: <050.1af5ba8b7425e07e484652f2ce9c33ca@haskell.org> References: <050.1af5ba8b7425e07e484652f2ce9c33ca@haskell.org> Message-ID: <065.0e58f62fbe472b3674abc15bd4740cf4@haskell.org> #13088: Type operator holes don't work infix -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11107, #13050 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: #13050 => #11107, #13050 Comment: This is a duplicate of #11107. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 02:28:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 02:28:46 -0000 Subject: [GHC] #11107: Can't use type wildcard infix In-Reply-To: <047.12dade849b8507aa88a8aa0ea7d9def2@haskell.org> References: <047.12dade849b8507aa88a8aa0ea7d9def2@haskell.org> Message-ID: <062.c5fa8821f42da7ffc6d8cc476a7e9c02@haskell.org> #11107: Can't use type wildcard infix -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: #13088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13088 Comment: Copying over the comments from #13088, a duplicate of this: > Originally noted in https://phabricator.haskell.org/D2910 (which fixed #13050). Currently, you can do this: > > {{{#!hs > {-# LANGUAGE TypeOperators #-} > foo :: a `_over` b -> _over a b > foo = id > }}} > > But not this: > > {{{#!hs > {-# LANGUAGE TypeOperators #-} > foo :: a `_` b -> over a b > foo = id > }}} > > osa1 made an attempt at fixing this, and recorded his progress [https://phabricator.haskell.org/D2910#85423 here]: > > > I played with alternative implementations and attempted at implementing type-level version of this patch as suggested by @RyanGlScott. > > > > Since `_` needs special treatment by the renamer I think we have to have some kind of special treatment for `_` in the parser too, so this implementation may not be too bad. > > > > (alternatively I guess we could remove special treatment for `_` in the parser but that'd just move special cases to the renamer, so I'm not sure that's any better than the current approach) > > > > About the type-level named infix holes: Type renamer is quite different than term renamer (`RnTypes.hs`) and I don't understand type- checker parts of the compiler -- but I was able to made an attempt at implementing this > > > > {{{#!diff > > diff --git a/compiler/hsSyn/HsTypes.hs b/compiler/hsSyn/HsTypes.hs > > index 53f200f..877c243 100644 > > --- a/compiler/hsSyn/HsTypes.hs > > +++ b/compiler/hsSyn/HsTypes.hs > > @@ -608,6 +608,7 @@ type LHsAppType name = Located (HsAppType name) > > data HsAppType name > > = HsAppInfix (Located name) -- either a symbol or an id in backticks > > | HsAppPrefix (LHsType name) -- anything else, including things like (+) > > + | HsAppWild (Located (HsWildCardInfo name)) > > deriving instance (DataId name) => Data (HsAppType name) > > > > instance (OutputableBndrId name) => Outputable (HsAppType name) where > > @@ -987,11 +988,18 @@ getAppsTyHead_maybe tys = case splitHsAppsTy tys of > > splitHsAppsTy :: [LHsAppType name] -> ([[LHsType name]], [Located name]) > > splitHsAppsTy = go [] [] [] > > where > > + go :: [LHsType name] > > + -> [[LHsType name]] > > + -> [Located name] > > + -> [LHsAppType name] > > + -> ([[LHsType name]], [Located name]) > > go acc acc_non acc_sym [] = (reverse (reverse acc : acc_non), reverse acc_sym) > > go acc acc_non acc_sym (L _ (HsAppPrefix ty) : rest) > > = go (ty : acc) acc_non acc_sym rest > > go acc acc_non acc_sym (L _ (HsAppInfix op) : rest) > > = go [] (reverse acc : acc_non) (op : acc_sym) rest > > + go acc acc_non acc_sym (L l (HsAppWild (L _ wc)) : rest) > > + = go (L l (HsWildCardTy wc) : acc) acc_non acc_sym rest > > > > -- Retrieve the name of the "head" of a nested type application > > -- somewhat like splitHsAppTys, but a little more thorough > > @@ -1334,14 +1342,18 @@ ppr_fun_ty ctxt_prec ty1 ty2 > > > > -------------------------- > > ppr_app_ty :: (OutputableBndrId name) => TyPrec -> HsAppType name -> SDoc > > -ppr_app_ty _ (HsAppInfix (L _ n)) = pprInfixOcc n > > +ppr_app_ty _ (HsAppInfix (L _ n)) > > + = pprInfixOcc n > > ppr_app_ty _ (HsAppPrefix (L _ (HsTyVar NotPromoted (L _ n)))) > > = pprPrefixOcc n > > ppr_app_ty _ (HsAppPrefix (L _ (HsTyVar Promoted (L _ n)))) > > = space <> quote (pprPrefixOcc n) -- We need a space before the ' above, so > > -- the parser does not attach it to the > > -- previous symbol > > -ppr_app_ty ctxt (HsAppPrefix ty) = ppr_mono_lty ctxt ty > > +ppr_app_ty ctxt (HsAppPrefix ty) > > + = ppr_mono_lty ctxt ty > > +ppr_app_ty ctxt (HsAppWild (L _ (AnonWildCard _))) > > + = empty -- FIXME > > > > -------------------------- > > ppr_tylit :: HsTyLit -> SDoc > > diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y > > index dfb6755..da4696a 100644 > > --- a/compiler/parser/Parser.y > > +++ b/compiler/parser/Parser.y > > @@ -1833,6 +1833,7 @@ tyapp :: { LHsAppType RdrName } > > [mj AnnSimpleQuote $1] } > > | SIMPLEQUOTE varop {% ams (sLL $1 $> $ HsAppInfix $2) > > [mj AnnSimpleQuote $1] } > > + | '`' '_' '`' { sL1 $1 (HsAppWild (sL1 $1 (AnonWildCard PlaceHolder))) } > > > > atype :: { LHsType RdrName } > > : ntgtycon { sL1 $1 (HsTyVar NotPromoted $1) } -- Not including unit tuples > > diff --git a/compiler/rename/RnTypes.hs b/compiler/rename/RnTypes.hs > > index f3fcf88..9298020 100644 > > --- a/compiler/rename/RnTypes.hs > > +++ b/compiler/rename/RnTypes.hs > > @@ -1050,8 +1050,11 @@ collectAnonWildCards lty = go lty > > > > gos = mconcat . map go > > > > + prefix_types_only :: HsAppType Name -> Maybe (LHsType Name) > > prefix_types_only (HsAppPrefix ty) = Just ty > > prefix_types_only (HsAppInfix _) = Nothing > > + prefix_types_only (HsAppWild (L l (AnonWildCard wc_name))) = > > + Just (L l (HsWildCardTy (AnonWildCard wc_name))) > > > > collectAnonWildCardsBndrs :: [LHsTyVarBndr Name] -> [Name] > > collectAnonWildCardsBndrs ltvs = concatMap (go . unLoc) ltvs > > @@ -1646,8 +1649,9 @@ extract_apps t_or_k tys acc = foldrM (extract_app t_or_k) acc tys > > > > extract_app :: TypeOrKind -> LHsAppType RdrName -> FreeKiTyVars > > -> RnM FreeKiTyVars > > -extract_app t_or_k (L _ (HsAppInfix tv)) acc = extract_tv t_or_k tv acc > > -extract_app t_or_k (L _ (HsAppPrefix ty)) acc = extract_lty t_or_k ty acc > > +extract_app t_or_k (L _ (HsAppInfix tv)) acc = extract_tv t_or_k tv acc > > +extract_app t_or_k (L _ (HsAppPrefix ty)) acc = extract_lty t_or_k ty acc > > +extract_app t_or_k (L _ (HsAppWild (L l wc))) acc = extract_lty t_or_k (L l (HsWildCardTy wc)) acc > > > > extract_hs_tv_bndrs :: [LHsTyVarBndr RdrName] -> FreeKiTyVars > > -> FreeKiTyVars -> RnM FreeKiTyVars > > }}} > > > > Once I figure out how to do the `FIXME` part this patch may just work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 06:06:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 06:06:01 -0000 Subject: [GHC] #14850: mallocBytes allows underflow In-Reply-To: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> References: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> Message-ID: <060.f32c60b0e4679078da29509c3b1ad527@haskell.org> #14850: mallocBytes allows underflow -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This would probably need to go through libraries committee review process, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 08:30:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 08:30:11 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.2f5a61adee2db17716fa5172ccdea62e@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't agree with comment:2. This ticket doesn't seem to have anything to do with impredicativity. It just has to do with a constructor that's promoted, but shouldn't be. Doesn't it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 08:45:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 08:45:15 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.abe8d50f23ed62342141ef1eb962bb72@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Are there any test cases from this ticket that we can add as regression tests for #2983? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 08:51:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 08:51:00 -0000 Subject: [GHC] #855: Improvements to SpecConstr In-Reply-To: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> References: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> Message-ID: <061.a0d790ac34df951feeffcbc49b1eba73@haskell.org> #855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Include call-pattern specialisation in the Simplifier, for a radical change I'm not keen on this * The Simplifier and `SpecConstr` are both very complex passes. Combining them would be ... difficult. * `SpecConstr` relies on a pretty elaborate form of occurrence analysis, which I'm not sure we'd want to replicated in the simplifier. Let's be really sure that nothing else will work first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 09:06:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 09:06:04 -0000 Subject: [GHC] #855: Improvements to SpecConstr In-Reply-To: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> References: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> Message-ID: <061.6a00f5aee7c6ef41e06222cc7e33a11b@haskell.org> #855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Another way of thinking about: thing in terms of defunctionalisation. Consider this higher order function {{{ let f :: (Int -> Bool) -> Int -> Char f g x = ....(g e)... in ...(f (\x.y+x)).... (f (\v.v*p*q))....(f h)... }}} Now defunctionalise by making a version of `f` that takes a data structure as its argument: {{{ data G_Fun = G1 Int -- \x.y+x | G2 Int Int -- \v.v*p*q | G3 (Int->Int) -- Escape hatch applyG :: G_Fun -> Int -> Bool applyG (G1 x) = \x.y+x applyG (G2 p q) = \v.v*p*q in ...(g e)... applyG (G3 g) = g let f' :: G_Fun -> Int -> Char f' ga x = ...(applyG ga e)... in ...(f' (G1 x))...(f' (G2 p q))...(f' (G3 h)) }}} (I guess you could do this via a w/w kind of transformation, but for now it's purely hypothetical.) Now we are back in the land of data-constructors, where `SpecConstr` thrives. Suppose the call is actually {{{ ...(f' (G1 (Yield e1 e2 e3)))... }}} Should we specialise on `(G1 x)` or on the deeper pattern `(G1 (Yield a b c))`? It depends how much `f'` scrutinises its argument. And you can see that from what `applyG` does. I think you could follow all this reasoning without ''actually'' createing `G_Fun` etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 09:24:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 09:24:14 -0000 Subject: [GHC] #855: Improvements to SpecConstr In-Reply-To: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> References: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> Message-ID: <061.a07fef238fd53f6667eee22910284e42@haskell.org> #855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Thanks for your insights! I have to read up on defunctionalisation, but what you suggest is basically what I had in mind in 1. above: Query the free variables of the lambda and see if they are in the [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc2362df #diff-992f9a53caac96c0e6303669d68a20e1R2163 ValueEnv] (meaning their RHSs are in WHNF, too). For some reason they weren't present where I expected them, looking into this now. >Should we specialise on (G1 x) or on the deeper pattern (G1 (Yield a b c))? It depends how much f' scrutinises its argument. And you can see that from what applyG does. Well, I'm not sure we can see that without running some kind of simplification first. But with `SPEC`, the matching `ArgOcc` is irrelevant, so we can look into this later. I [https://github.com/sgraf812/ghc/commit/c6c9fbe1eb5ad117b5bd23e943c82ca7bc2362df #diff-992f9a53caac96c0e6303669d68a20e1R1144 conveniently left] `CallOcc` with an `ArgOcc` field for when the result of the call is scrutinised for that. I'll go and see if I can get the free vars of the lambda into the `ValueEnv`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 09:36:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 09:36:41 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.05a1476d40197c93b12a8df5026ad545@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): It turns out that `Main.hs` produces about 2.8G of Core. This part seems to be the culprit: {{{ -- RHS size: {terms: 6,002, types: 8,003, coercions: 1,415,000, joins: 0/0} main :: IO () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 09:37:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 09:37:16 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.2de6f293385b732ba8533bc98af63710@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | QuantifiedConstraints, deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Remind me: {{{ join_ = coerce @(forall a. m ( m a) -> m a) }}} Do we allow this? (It's impredicative -- but in a benign way.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 09:39:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 09:39:30 -0000 Subject: [GHC] #9793: Some as-patterns could be accepted in pattern synonyms In-Reply-To: <045.e251d4b7f57881692430bb7253319357@haskell.org> References: <045.e251d4b7f57881692430bb7253319357@haskell.org> Message-ID: <060.1b9ded14b2aa7efee66fd68174e3bfce@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 7.8.3 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:D1666 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See https://github.com/ghc-proposals/ghc-proposals/pull/94, where I propose loosening the rules for as-patterns. Perhaps your use-case would strengthen the case. Can you explain it with code? (You could do so here, and then add a comment to the proposal thread pointing to it._ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 09:50:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 09:50:24 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases In-Reply-To: <046.96a71a8566a954e21839a1a60572305e@haskell.org> References: <046.96a71a8566a954e21839a1a60572305e@haskell.org> Message-ID: <061.deba28631d1d592cace352c38f612ae5@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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): I don't grok the details, but this looks good to me. Shouldn't the size adapt somehow? What if there are more faststrings in some later, bigger program? Won't this just happen again? At least should we not have a warning for an over-populated table? Whatever happens, please ensure there's a note pointing to this ticket, to explain the change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 09:57:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 09:57:48 -0000 Subject: [GHC] #14855: Implementation of liftA2 for Const has high arity In-Reply-To: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> References: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> Message-ID: <059.742fb21af09df514203e4bb5cd82c094@haskell.org> #14855: Implementation of liftA2 for Const has high arity -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think you'll get the same code in all these cases, but you could `-ddump-simpl` to check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 10:01:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 10:01:44 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases In-Reply-To: <046.96a71a8566a954e21839a1a60572305e@haskell.org> References: <046.96a71a8566a954e21839a1a60572305e@haskell.org> Message-ID: <061.3256f43413d24724acb7825a7bd4aa4e@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): > Shouldn't the size adapt somehow? What if there are more faststrings in some later, bigger program? Won't this just happen again? Yes, probably, but the flexibility may come at a cost. I don't have a solution yet, that's why this is a ticket and not a phabricator patch. I also don't expect to be able to focus on this in the near future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 10:03:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 10:03:34 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.4ef4697be924888cb51efd260570a2d4@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's one big coercion! Can you distil a standalone test case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 10:14:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 10:14:02 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.cbbaa4f2c1f09d5b2b5ddf3fd774622c@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): phab:D4423 #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Sorry to be slow on this, I wanted to write a comprehensive response, but I kept going in loops. It boils down to this: I don't know what the invariant should be and don't know how to arrive at the solution. I also don't think there's much to be gained from changing it at this point. Any extra src ticks won't be used right away and not having ticks on all the primitive strings probably also doesn't affect the final output. My personal bias here would be to not throw away information. We already have a written invariant ("No top level ticked strings") which gets violated and a bug in a previous fix is what's causing the violation. phab:D4423 is meant to make the previous fix correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 10:16:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 10:16:37 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.2b4349251bbf667e40b5f470abbcff30@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): phab:D4423 #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, I think Simon M is the person most likely to have a well-informed view about comment:12. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 10:25:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 10:25:04 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases In-Reply-To: <046.96a71a8566a954e21839a1a60572305e@haskell.org> References: <046.96a71a8566a954e21839a1a60572305e@haskell.org> Message-ID: <061.d481f1374ed458f1f885790b89988b7b@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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 simonmar): > 3,106,526,336 bytes maximum residency (8 sample(s)) :-o What's the residency overhead for the larger hash table? I suppose this hash table should auto-grow and rehash itself, unless there's not much overhead for the larger table. One stopgap approach might be to have a command-line flag to set the size. It would have to be a static flag though (yuck). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 11:18:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 11:18:33 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.b8f5d4aa2ee1d36b7821f96364d6741a@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13075 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): This ticket has already been fixed in [changeset:"af89d6872da2e00be738e1ac541346cd84e6d141/ghc"] {{{ Reject top-level banged bindings Bizarrely, we were not rejecting !x = e Fix: * In the test in DsBinds.dsTopLHsBinds, use isBangedHsBind, not isBangedPatBind. (Indeed the latter dies altogther.) * Implement isBangedHsBind in HsUtils; be sure to handle AbsBinds All this was shown up by Trac #13594 }}} We should mark testcase T13075 as normal and add it's stderr. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 11:20:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 11:20:17 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.35ae4681f35ebc80df679d19d179f01e@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I tried, however concatenating the relevant modules into one reduces the impact a bit. I'll attach a reduced version anyway, where we still get this: {{{ -- RHS size: {terms: 8, types: 11, coercions: 1,424, joins: 0/0} main :: IO () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 11:21:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 11:21:27 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.e57f8023a1cbdc44c66cd02173b65c4a@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "test.hs" added. Test case to reproduce -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 11:27:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 11:27:55 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.7f878d76162671cc775662717d233d24@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Copying the last line a thousand times or so over increases the number of coercions to similar levels as the original one, but this simpler cases makes the dumped Core easier to handle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 12:43:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 12:43:14 -0000 Subject: [GHC] #14335: Annotations aren't supported with -fexternal-interpreter In-Reply-To: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> References: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> Message-ID: <061.ffd137e70308f7722744250925a499c9@haskell.org> #14335: Annotations aren't supported with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14335 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): As suggested in comment:2, this doesn't require `ANN`, `-fplugin` simply doesn't work with `-fexternal-interpreter`. Reproducer: {{{ $ cat plugin/src/Plugin.hs module Plugin where import GhcPlugins plugin :: Plugin plugin = defaultPlugin{ installCoreToDos = install } install :: [CommandLineOption] -> [CoreToDo] -> CoreM [CoreToDo] install _ todo = do return (CoreDoPluginPass "test plugin" pass : todo) pass :: ModGuts -> CoreM ModGuts pass g = return g $ cat test.hs {-# OPTIONS_GHC -fplugin Plugin #-} module Test where $ ghc-stage2 test.hs -fforce-recomp -fexternal-interpreter [1 of 1] Compiling Test ( test.hs, test.o ) getHValueSafely plugin (Plugin) CallStack (from HasCallStack): wormholeRef, called at compiler/ghci/GHCi.hs:622:21 in ghc:GHCi wormhole, called at compiler/main/DynamicLoading.hs:189:56 in ghc:DynamicLoading getHValueSafely, called at compiler/main/DynamicLoading.hs:161:44 in ghc:DynamicLoading getValueSafely, called at compiler/main/DynamicLoading.hs:107:24 in ghc:DynamicLoading loadPlugin', called at compiler/main/DynamicLoading.hs:87:14 in ghc:DynamicLoading ghc-stage2: this operation requires -fno-external-interpreter }}} The call stack is added by me to debug. `getHValueSafely` is being called to get `plugin :: Plugin` from the plugin module. The problem is we're trying to dereference a `HValueRef` returned by the external GHCi process. If we want plugins to work with `-fexternal- interpreter` I guess we have to let GHCi run the plugin passes and somehow return results to `TcRnDriver` (and `SimplCore` for Core plugins). I just started reading the relevant code, but I think we may need new GHCi messages for these? As parameter we need to pass the whole `TcM` (and `CoreM` for Core plugins) context. @bgamari @simonmar does this make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 13:03:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 13:03:27 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases In-Reply-To: <046.96a71a8566a954e21839a1a60572305e@haskell.org> References: <046.96a71a8566a954e21839a1a60572305e@haskell.org> Message-ID: <061.0b20788e2a4de1a44fec3d4b3847d44d@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): If we decided to depend on https://hackage.haskell.org/package/hashtables, the implementation looks solid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 13:11:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 13:11:37 -0000 Subject: [GHC] #14701: Investigate the performance impact of code alignment In-Reply-To: <042.e11dda7ab3eddd9e4c88a6b0f72299d7@haskell.org> References: <042.e11dda7ab3eddd9e4c88a6b0f72299d7@haskell.org> Message-ID: <057.e8b7a0b874a6908f8b3ff3980f30e2c5@haskell.org> #14701: Investigate the performance impact of code alignment -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: | Keywords: 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 sjakobi): * cc: sjakobi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 13:49:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 13:49:33 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.666e119e55c18de2943d27aaf6aa1e38@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is the test case from #13895: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module Foo where import Data.Data (Data, Typeable) import Data.Kind dataCast1 :: forall (a :: Type). Data a => forall (c :: Type -> Type) (t :: forall (k :: Type). Typeable k => k -> Type). Typeable t => (forall d. Data d => c (t d)) -> Maybe (c a) dataCast1 _ = undefined }}} {{{ $ /opt/ghc/8.4.1/bin/ghci Bug.hs GHCi, version 8.4.0.20180224: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Bug.hs, interpreted ) Bug.hs:11:23: error: • Illegal constraint in a type: Typeable k0 • In the first argument of ‘Typeable’, namely ‘t’ In the type signature: dataCast1 :: forall (a :: Type). Data a => forall (c :: Type -> Type) (t :: forall (k :: Type). Typeable k => k -> Type). Typeable t => (forall d. Data d => c (t d)) -> Maybe (c a) | 11 | Typeable t | ^ Bug.hs:12:38: error: • Illegal constraint in a type: Typeable k0 • In the first argument of ‘c’, namely ‘(t d)’ In the type signature: dataCast1 :: forall (a :: Type). Data a => forall (c :: Type -> Type) (t :: forall (k :: Type). Typeable k => k -> Type). Typeable t => (forall d. Data d => c (t d)) -> Maybe (c a) | 12 | => (forall d. Data d => c (t d)) | ^^^ }}} Note that there are no promoted constructors in this program! But changing the error message as per the suggestion in comment:9 means that the new error message for this program would (incorrectly) be: {{{ Data constructor has a constraint `Typeable k0`, and thus cannot be promoted }}} Since the [http://git.haskell.org/ghc.git/blob/ffdb110a7f71b29f30adab7fea794b9f070a8e75:/compiler/typecheck/Inst.hs#l451 place where this error message arises], `tcInstBinder`, has no knowledge of where the constraint comes from (in particular, whether it comes from a promoted constructor or not). I just want to make sure that if we do change this error message, that we don't degrade the quality of the error message in this program. But I have no idea how `tcInstBinder` works, so knowing how to propagate the relevant information down into `tcInstBinder` to make it aware of the provenance of the error message is far above my pay grade. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 13:53:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 13:53:52 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.9d5a1dc7115a61c6f8be94b8a8c12a13@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | QuantifiedConstraints, deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:24 simonpj]: > Do we allow this? Sadly, not without `ImpredicativeTypes` (which `GeneralizedNewtypeDeriving` enables under the hood). > (It's impredicative -- but in a benign way.) Indeed. You had proposed a way to allow this without `ImpredicativeTypes` [https://mail.haskell.org/pipermail/ghc-devs/2016-September/012940.html here]—do you think you could create a GHC proposal about this? The details of this are far beyond my understanding, so it'd take someone with your level of expertise to get the details right in such a hypothetical proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 14:00:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 14:00:59 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.62be2dbcea5d137b69942fbed092b70c@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm. I suppose you could add the original program from this ticket: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module T5927 where data Exists c where Exists :: c a => a -> Exists c instance (forall a. c a => Show a) => Show (Exists c) where show (Exists a) = show a }}} But this actually fails! {{{ Bug.hs:9:10: error: • Could not deduce: c (Exists c) arising from a use of ‘GHC.Show.$dmshowsPrec’ from the context: forall a. c a => Show a bound by the instance declaration at Bug.hs:9:10-53 • In the expression: GHC.Show.$dmshowsPrec @(Exists c) In an equation for ‘showsPrec’: showsPrec = GHC.Show.$dmshowsPrec @(Exists c) In the instance declaration for ‘Show (Exists c)’ • Relevant bindings include showsPrec :: Int -> Exists c -> ShowS (bound at Bug.hs:9:10) | 9 | instance (forall a. c a => Show a) => Show (Exists c) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:9:10: error: • Could not deduce: c (Exists c) arising from a use of ‘GHC.Show.$dmshowList’ from the context: forall a. c a => Show a bound by the instance declaration at Bug.hs:9:10-53 • In the expression: GHC.Show.$dmshowList @(Exists c) In an equation for ‘showList’: showList = GHC.Show.$dmshowList @(Exists c) In the instance declaration for ‘Show (Exists c)’ • Relevant bindings include showList :: [Exists c] -> ShowS (bound at Bug.hs:9:10) | 9 | instance (forall a. c a => Show a) => Show (Exists c) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I'm not sure what to make of this. If you implement `showsPrec` and `showList` manually: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module T5927 where import Text.Show data Exists c where Exists :: c a => a -> Exists c instance (forall a. c a => Show a) => Show (Exists c) where show (Exists a) = show a showsPrec p (Exists a) = showsPrec p a showList l = showListWith (\(Exists a) -> shows a) l }}} Then it typechecks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 15:56:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 15:56:41 -0000 Subject: [GHC] #13596: Try disabling inlining of DynFlags combinators In-Reply-To: <046.9accb606fa75f7116120ef5bc82c66b2@haskell.org> References: <046.9accb606fa75f7116120ef5bc82c66b2@haskell.org> Message-ID: <061.7d78873c5339c2cf1c46cd00a65e9fc4@haskell.org> #13596: Try disabling inlining of DynFlags combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | 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 tdammers): Only other candidate I could come up with is `alterSettings`; other than that, everything seems to be record accessors. `NOINLINE`ing `alterSettings` however increases compile times, so that is clearly not something we would want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 17:18:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 17:18:12 -0000 Subject: [GHC] #855: Improvements to SpecConstr In-Reply-To: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> References: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> Message-ID: <061.5d5862b0c4494c74d7ac49212171f2be@haskell.org> #855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): This is what I have so far: [https://github.com/sgraf812/ghc/compare/8529fbba309cd692bbbb0386321515d05a6ed256...a593e0ac80124537e2043b7a5d8b85d69bbd2e14 #diff-992f9a53caac96c0e6303669d68a20e1 diff] The reason why I couldn't find the lambda's free vars in the `ValueEnv` earlier is that the matching [https://github.com/sgraf812/ghc/compare/8529fbba309cd692bbbb0386321515d05a6ed256...a593e0ac80124537e2043b7a5d8b85d69bbd2e14 #diff-992f9a53caac96c0e6303669d68a20e1R2140 argToPat case] didn't add them before. That's a problem for our specific case, where the free vars of the lambda are bound within the call-pattern, e.g. `Just (let x = 4 in \y. x + y)`. With that fix in place, the free var values are detected just fine and guided by the `ConVal` case I could implement the [https://github.com/sgraf812/ghc/compare/8529fbba309cd692bbbb0386321515d05a6ed256...a593e0ac80124537e2043b7a5d8b85d69bbd2e14 #diff-992f9a53caac96c0e6303669d68a20e1R2180 specialisation code]. From what I can tell, the generated specialisation looks great, but it isn't called anywhere because now the rules no longer fire. My particular solution would just introduce let bindings into the lambda body that re-bind things we find to be values (similar to how arguments of a data con are handled). Example: {{{ let { lvl_s4md = *# sc_s4rb sc_s4rb lvl_s4lL = I# lvl_s4md lvl_s4ll = Yield @ Bool @ Int False lvl_s4lL } in MkStream @ Int @ Bool (\ (ds_d2Fz :: Bool) -> case ds_d2Fz of { False -> Stop @ Bool @ Int; True -> lvl_s4ll }) True ==> let { lvl_s4md = *# sc_s4rb sc_s4rb lvl_s4lL = I# lvl_s4md lvl_s4ll = Yield @ Bool @ Int False lvl_s4lL } in MkStream @ Int @ Bool (\ (ds_d2Fz :: Bool) -> let { lvl_s4ll = Yield @ Bool @ Int False (I# sc_s4md) } in case ds_d2Fz of { False -> Stop @ Bool @ Int; True -> lvl_s4ll }) True }}} Kind-of a manual float-in of all bindings we know are values and have corresponding `ScrutOcc` (which we ignore at the moment). This results in a much better specialisation for `Just (MkStream True)` I believe (`dump-simpl`): {{{ $s$wgo_s4rg :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# $s$wgo_s4rg (sc_s4rf :: GHC.Prim.Int#) (sc1_s4re :: GHC.Prim.Int#) (sc2_s4rd :: GHC.Prim.Int#) = jump $wgo_s4ph GHC.Types.SPEC (GHC.Prim.+# sc2_s4rd sc_s4rf) sc1_s4re (GHC.Base.Just @ (Stream Int) (Main.MkStream @ Int @ Bool (\ (ds_d2Fz :: Bool) -> case ds_d2Fz of { False -> Main.Stop @ Bool @ Int; True -> Main.Yield @ Bool @ Int GHC.Types.False (GHC.Types.I# sc_s4rf) }) GHC.Types.False)); }}} There's a problem though: That function doesn't get called any more, because the corresponding RULE looks like this: {{{ "SC:$wgo2" [0] forall (sc_s4rj :: GHC.Prim.Int#) (sc_s4rk :: Bool) (sc_s4ri :: GHC.Prim.Int#) (sc_s4rh :: GHC.Prim.Int#). $wgo_s4ph GHC.Types.SPEC sc_s4rh sc_s4ri (GHC.Base.Just @ (Stream Int) (Main.MkStream @ Int @ Bool (\ (ds_d2Fz :: Bool) -> let { sc_s4rf :: GHC.Prim.Int# [LclId] sc_s4rf = sc_s4rj } in let { lvl_s4ll :: Step Bool Int [LclId] lvl_s4ll = Main.Yield @ Bool @ Int GHC.Types.False (GHC.Types.I# sc_s4rf) } in case ds_d2Fz of { False -> Main.Stop @ Bool @ Int; True -> lvl_s4ll }) sc_s4rk)) = jump $s$wgo_s4rr sc_s4rj sc_s4rk sc_s4ri sc_s4rh }}} E.g. the extra bindings I introduced obstruct the RULE engine. I can probably figure out how to generate the right rules tomorrow. Please yell if I'm missing some critical pass or function to do this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 17:21:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 17:21:53 -0000 Subject: [GHC] #14850: mallocBytes allows underflow In-Reply-To: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> References: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> Message-ID: <060.8104a8c575eed2564e66786025ff5f8c@haskell.org> #14850: mallocBytes allows underflow -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: core-libraries-committee@… (added) Comment: Indeed it does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 17:33:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 17:33:44 -0000 Subject: [GHC] #14857: GHC-8.4.1 release notes don't mention 'Div', 'Mod' and other type families Message-ID: <047.09b32790742451b61f5bc476fd1d389a@haskell.org> #14857: GHC-8.4.1 release notes don't mention 'Div', 'Mod' and other type families -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.4.1-alpha3 Keywords: | Operating System: Unknown/Multiple base,documentation,div,mod,type | families,changelog,release notes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.4.1 brought support for `Div`, `Mod` and `Log2` type families for type level natural numbers: * https://downloads.haskell.org/~ghc/master/libraries/base/base/GHC- TypeNats.html#t:Div I'm actually using this feature in `o-clock` package * https://github.com/serokell/o-clock But I was told about this feature only by other Haskell developer. And I don't see this change described in release notes for GHC 8.4.1: * https://downloads.haskell.org/%7Eghc/master/users-guide/8.4.1-notes.html #base-library -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 17:48:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 17:48:33 -0000 Subject: [GHC] #14846: Renamer hangs (because of -XInstanceSigs?) In-Reply-To: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> References: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> Message-ID: <066.892a2a77c936496b8759b2706ee8b664@haskell.org> #14846: Renamer hangs (because of -XInstanceSigs?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: InstanceSigs | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great bug report. Patch coming -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 17:49:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 17:49:26 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.b1e52bcd1183de78a52781cbbe8289ad@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chshersh): If this type class will be added to `base` library one day (which I personally really like to see) I would love to add that it would be good to have `fold1'` function with strict semantic (similar to `foldl'`). Otherwise `fold1 $ map Sum (1 :| [2 .. 10^8])` would take infinite amount of time and memory to calculate and there will be no better way to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 19:41:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 19:41:53 -0000 Subject: [GHC] #14857: GHC-8.4.1 release notes don't mention 'Div', 'Mod' and other type families In-Reply-To: <047.09b32790742451b61f5bc476fd1d389a@haskell.org> References: <047.09b32790742451b61f5bc476fd1d389a@haskell.org> Message-ID: <062.3ff815bd69e33c6f6e6b42e9845aa885@haskell.org> #14857: GHC-8.4.1 release notes don't mention 'Div', 'Mod' and other type families -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.4.1-alpha3 Resolution: | Keywords: | base,documentation,div,mod,type | families,changelog,release notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): This seems to be a `base` rather than a compiler change, which means it's documented in the base changelog, https://github.com/ghc/ghc/blob/ghc-8.4/libraries/base/changelog.md Though perhaps we should somehow link to this changelog. That said, we don't advertise changes by other boot packages unless they're really important, like backwards incompatible changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 19:53:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 19:53:27 -0000 Subject: [GHC] #14850: mallocBytes allows underflow In-Reply-To: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> References: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> Message-ID: <060.3e3ea97bd4c2f71c459882635617cd00@haskell.org> #14850: mallocBytes allows underflow -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Not to gum up the works, but is there a comprehensive list of `Int`-consuming functions like `mallocBytes` that should have an explicit overflow check? If so, perhaps one could just send that list to the libraries mailing list, and see if folks are OK with changing all of their `Int` arguments to `Word`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 19:54:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 19:54:15 -0000 Subject: [GHC] #14839: Bits typeclass law for LSB In-Reply-To: <049.ae12d72b715673ae15b8ffd0b77836ec@haskell.org> References: <049.ae12d72b715673ae15b8ffd0b77836ec@haskell.org> Message-ID: <064.9d0821268a8113ecc0849a229dc9a794@haskell.org> #14839: Bits typeclass law for LSB -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: base Operating System: 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): Have you ran this past the libraries mailing list? On the surface, this seems reasonable to me, but perhaps I'm forgetting some obscure `Bits` instance that doesn't satisfy this property. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 20:08:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 20:08:19 -0000 Subject: [GHC] #14850: mallocBytes allows underflow In-Reply-To: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> References: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> Message-ID: <060.894a75af3deb24e0c9af0df49c18bab1@haskell.org> #14850: mallocBytes allows underflow -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I'm all in favor of using `Word` instead of `Int` but `mallocBytes` is part of Haskell2010 ([https://www.haskell.org/onlinereport/haskell2010/haskellch31.html#x39-28700031.1 Foreign.Marshal.Alloc]) so it's going to be painful to get the change accepted. If we ever do it, we can fix most other uses of `Int` in the report: e.g., in [https://www.haskell.org/onlinereport/haskell2010/haskellch20.html#x28-22800020 Data.List], in [https://www.haskell.org/onlinereport/haskell2010/haskellch15.html#x23-20800015 Data.Bits], etc. We could also fix GHC's primitives (`unsafeShiftRL#`, etc.). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 20:23:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 20:23:52 -0000 Subject: [GHC] #14858: Typed hole subtitution search fails in the REPL Message-ID: <044.605f4aa7b63ca26feac6d76a97945eb0@haskell.org> #14858: Typed hole subtitution search fails in the REPL -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha3 (Type checker) | Keywords: typed holes | Operating System: Unknown/Multiple substitutions | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems as though type class defaulting might be happening before the search. This finds only undefined: {{{#!text > _traverse print "abc" :20:1: error: • Found hole: _traverse :: (() -> IO ()) -> [Char] -> t Where: ‘t’ is a rigid type variable bound by the inferred type of it :: t at :20:1-21 Or perhaps ‘_traverse’ is mis-spelled, or not in scope • In the expression: _traverse In the expression: _traverse print "abc" In an equation for ‘it’: it = _traverse print "abc" • Relevant bindings include it :: t (bound at :20:1) Valid substitutions include undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’)) }}} Annotating the return type helps, but we still don't find traverse_: {{{#!text > _traverse print "abc" :: IO () :22:1: error: • Found hole: _traverse :: (() -> IO ()) -> [Char] -> IO () Or perhaps ‘_traverse’ is mis-spelled, or not in scope • In the expression: _traverse In the expression: _traverse print "abc" :: IO () In an equation for ‘it’: it = _traverse print "abc" :: IO () • Relevant bindings include it :: IO () (bound at :22:1) Valid substitutions include mempty :: forall a. Monoid a => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’)) undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’)) }}} (note how print seems to have been defaulted to ()) Annotating the type of print helps: {{{#!text > _traverse (print :: Char -> IO ()) "abc" :: IO () :23:1: error: • Found hole: _traverse :: (Char -> IO ()) -> [Char] -> IO () Or perhaps ‘_traverse’ is mis-spelled, or not in scope • In the expression: _traverse In the expression: _traverse (print :: Char -> IO ()) "abc" :: IO () In an equation for ‘it’: it = _traverse (print :: Char -> IO ()) "abc" :: IO () • Relevant bindings include it :: IO () (bound at :23:1) Valid substitutions include mempty :: forall a. Monoid a => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’)) undefined :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => a (imported from ‘Prelude’ (and originally defined in ‘GHC.Err’)) foldMap :: forall (t :: * -> *). Foldable t => forall m a. Monoid m => (a -> m) -> t a -> m (imported from ‘Prelude’ (and originally defined in ‘Data.Foldable’)) mapM_ :: forall (t :: * -> *) (m :: * -> *) a b. (Foldable t, Monad m) => (a -> m b) -> t a -> m () (imported from ‘Prelude’ (and originally defined in ‘Data.Foldable’)) traverse_ :: forall (t :: * -> *) (f :: * -> *) a b. (Foldable t, Applicative f) => (a -> f b) -> t a -> f () (imported from ‘Data.Foldable’) }}} This was found with 8.4.1-rc.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 21:13:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 21:13:25 -0000 Subject: [GHC] #14850: mallocBytes allows underflow In-Reply-To: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> References: <045.607b90e8fd9ef877b0a8275e3d762768@haskell.org> Message-ID: <060.fe2bb77902e59ebcdde76a08360131f0@haskell.org> #14850: mallocBytes allows underflow -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by glguy): Switching to Word is more likely to hide mistakes as oversized allocations due to wrap-around. I'd prefer to keep the computations at the Int type and have the check implemented once in mallocBytes than to have to see that check duplicated out to every caller of mallocBytes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 21:24:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 21:24:57 -0000 Subject: [GHC] #855: Improvements to SpecConstr In-Reply-To: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> References: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> Message-ID: <061.45f3dc4ef86d367879a24928814e94ab@haskell.org> #855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Calling the very simple optimiser (in `CoreOpt`) on the LHS might help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 21:30:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 21:30:26 -0000 Subject: [GHC] #14858: Typed hole subtitution search fails in the REPL In-Reply-To: <044.605f4aa7b63ca26feac6d76a97945eb0@haskell.org> References: <044.605f4aa7b63ca26feac6d76a97945eb0@haskell.org> Message-ID: <059.6be5fdb217ebf51a2c540fc4ff567db4@haskell.org> #14858: Typed hole subtitution search fails in the REPL -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.4.1-alpha3 checker) | Keywords: typed holes Resolution: | substitutions Operating System: 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): Probably type-class defaulting is taking place, in an effort to make things run. Eg. {{{ ghci> 3+4 }}} We need type-class defaulting to choose `Integer` (say) as the type to use for the evaluation. Hmm. Maybe we should NOT do any type-class defaulting if there are insoluble errors (like out of scope variables). You could try this. In `TcSimplify.simpl_top` we see {{{ simpl_top wanteds = do { wc_first_go <- nestTcS (solveWantedsAndDrop wanteds) -- This is where the main work happens ; try_tyvar_defaulting wc_first_go } }}} You could try doing `try_tyvar_defaulting` only if `insolubleWC wc_first_go` is False. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 22:02:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 22:02:17 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.4cbc053c5e0bc697c241660342758574@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Hmph. You're right. You could always just add a `NB: Constrained data constructors cannot be promoted` or `Have you tried promoting a constrained data constructor?`. I don't think people will often trip over this. The other place to check is in the `AGlobal (AConLike (RealDataCon dc))` case in `TcHsType.tcTyVar`. I don't suppose it would be hard to check if the datacon had constraints. The only access seems to be in the fourth component of a `dataConFullSig`, but the comments there refer to a `dataConDictTheta` (now extinct) that could be revived to return this nugget. That might be a better route. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 22:03:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 22:03:39 -0000 Subject: [GHC] #13596: Try disabling inlining of DynFlags combinators In-Reply-To: <046.9accb606fa75f7116120ef5bc82c66b2@haskell.org> References: <046.9accb606fa75f7116120ef5bc82c66b2@haskell.org> Message-ID: <061.3bb5a960a365818ee293ffa76893996b@haskell.org> #13596: Try disabling inlining of DynFlags combinators -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, it sounds like we should probably just put this aside in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 22:06:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 22:06:55 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.5be1cdb6d9043b9c5572a3ce62a0ea9a@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK so there are two things * A data constructor should not be promoted if it has a constrained type. This should not be hard to arrange. * As comment:12 shows, a kind signature should hove no constraints in it. Surely `checkValidType` is the place for that check. By the time we get to `tcInstBinder` the crime is well past! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 22:08:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 22:08:34 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.db8649fa31c0c47a2e166eba0d4d0b29@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But ''equality'' constraints are OK. Even user-written ones. What about ones hidden behind type synonyms? I think they should be, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 22:09:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 22:09:36 -0000 Subject: [GHC] #14845: TypeInType, index GADT by constraint witness In-Reply-To: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> References: <051.fa74d2bc56c185aedc6d84b6531239e7@haskell.org> Message-ID: <066.452c74272c7b026ff13697174c0b2afa@haskell.org> #14845: TypeInType, index GADT by constraint witness -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13895 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Actually, come to think of it, the check I suggested around `dataConFullSig` will snag user-written equality constraints, which it shouldn't. For example {{{ data G a where MkG :: a ~ Int => G a }}} should be just fine to promote. So something more delicate will be needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 23:06:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 23:06:52 -0000 Subject: [GHC] #14855: Implementation of liftA2 for Const has high arity In-Reply-To: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> References: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> Message-ID: <059.d7ef5bdb78f802d2c6048a223f18d10b@haskell.org> #14855: Implementation of liftA2 for Const has high arity -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lyxia): The Core looks different when the `Monoid` remains abstract, but the same if it is specialized. So there is some optimization that makes it fine in the end. Example with abstract `Monoid`: {{{ {-# LANGUAGE ScopedTypeVariables #-} module W where import Data.Coerce import Data.Functor.Const xyz, abc :: forall x a b c. Monoid x => (a -> b -> c) -> Const x a -> Const x b -> Const x c xyz _ (Const a) (Const b) = Const (mappend a b) abc _ = coerce (mappend :: x -> x -> x) }}} Core: {{{ -- RHS size: {terms: 12, types: 24, coercions: 10, joins: 0/0} xyz1 xyz1 = \ @ x_a10q @ a_a10r @ b_a10s @ c_a10t $dMonoid_a10v _ ds1_d11x ds2_d11y -> mappend $dMonoid_a10v (ds1_d11x `cast` ) (ds2_d11y `cast` ) -- RHS size: {terms: 1, types: 0, coercions: 37, joins: 0/0} xyz xyz = xyz1 `cast` -- RHS size: {terms: 8, types: 14, coercions: 0, joins: 0/0} abc1 abc1 = \ @ x_a105 @ a_a106 @ b_a107 @ c_a108 $dMonoid_a10a _ -> mappend $dMonoid_a10a -- RHS size: {terms: 1, types: 0, coercions: 39, joins: 0/0} abc abc = abc1 `cast` }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 26 23:07:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Feb 2018 23:07:30 -0000 Subject: [GHC] #14855: Implementation of liftA2 for Const has high arity In-Reply-To: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> References: <044.0dfa084454fe441cb10c2491afd62785@haskell.org> Message-ID: <059.3a8d8beee47fa4e084b971563a984a88@haskell.org> #14855: Implementation of liftA2 for Const has high arity -------------------------------------+------------------------------------- Reporter: lyxia | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 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 lyxia): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 04:02:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 04:02:11 -0000 Subject: [GHC] #10424: Build path leaks into ABI hashes In-Reply-To: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> References: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> Message-ID: <061.eb744577229298557937210efc6f9a48@haskell.org> #10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: #4012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Any reason why this was never merged? We have also used the patch in Fedora without problems. Or has this been addressed already in another way? The latest patch is still in later debian and Fedora packages: https://salsa.debian.org/haskell- team/DHG_packages/blob/experimental/p/ghc/debian/patches/buildpath-abi- stability.patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 04:04:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 04:04:17 -0000 Subject: [GHC] #10424: Build path leaks into ABI hashes In-Reply-To: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> References: <046.a66bd75799cab79a67d2ea94ef806de6@haskell.org> Message-ID: <061.c6cbe413f69953797ea6a3238433435f@haskell.org> #10424: Build path leaks into ABI hashes -------------------------------------+------------------------------------- Reporter: nomeata | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: #4012 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > Any reason why this was never merged? We have also used the patch in Fedora without problems. The only reason is that likely only Debian and Fedora care, and both of us have the patch … :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 04:28:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 04:28:09 -0000 Subject: [GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage In-Reply-To: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> References: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> Message-ID: <065.555590b55b2771adda46f47a21cc9058@haskell.org> #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ---------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: bgamari Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Build System | Version: 8.0.2-rc1 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 juhpetersen): Still no movement here. Here is a typical Fedora buildlog: https://kojipkgs.fedoraproject.org//packages/ghc/8.2.2/65.fc28/data/logs/x86_64/build.log Anyone see anything wrong? How should a working build look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 08:47:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 08:47:30 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.49b6386240f4727ad459ba483b83b9c4@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13075 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3dec9236a80299cd3e3b9b21a42f91628db1a3d7/ghc" 3dec9236/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3dec9236a80299cd3e3b9b21a42f91628db1a3d7" Test for Trac #13075 is working now }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 08:49:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 08:49:45 -0000 Subject: [GHC] #14846: Renamer hangs (because of -XInstanceSigs?) In-Reply-To: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> References: <051.a66d690b58cfe062ed0472f10a328f1d@haskell.org> Message-ID: <066.adc73c391131f0fe3aa2ee87e86b5a68@haskell.org> #14846: Renamer hangs (because of -XInstanceSigs?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: InstanceSigs | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T14846 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire * testcase: => polykinds/T14846 * priority: normal => highest * milestone: => 8.6.1 Comment: Fixed by {{{ commit e99fdf775540440c1c58dc5ade3c5984dc49246f Author: Simon Peyton Jones Date: Mon Feb 26 17:44:55 2018 +0000 Fix a nasty bug in the pure unifier The pure unifier was building an infinite type, through a defective occurs check. So GHC went into an infinite loop. Reason: we were neglecting the 'kco' part of the type, which 'unify_ty' maintains. Yikes. The fix is easy. I refactored a bit to make it harder to go wrong in future. >--------------------------------------------------------------- e99fdf775540440c1c58dc5ade3c5984dc49246f compiler/types/Unify.hs | 59 ++++++++++++++++++--------------- testsuite/tests/polykinds/T14846.hs | 39 ++++++++++++++++++++++ testsuite/tests/polykinds/T14846.stderr | 43 ++++++++++++++++++++++++ testsuite/tests/polykinds/all.T | 1 + 4 files changed, 116 insertions(+), 26 deletions(-) }}} Richard, can you just check my work? I'll leave the ticket open, but assign to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 08:54:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 08:54:23 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.98b74b57968235d8b72f0c0bbfdc7ecf@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13075 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b2996f1b81c6c51eedc7ece93de0a6bc0426da5c/ghc" b2996f1b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b2996f1b81c6c51eedc7ece93de0a6bc0426da5c" Fix test for Trac #13075 I'd put the stderr file in my link tree, not in the source tree, so my original push had the wrong file, even though my tree validated. Sorry! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 08:55:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 08:55:10 -0000 Subject: [GHC] #13075: Top-level bang pattern accepted In-Reply-To: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> References: <047.f83b957eceda4fbb3c1b3de754ae577d@haskell.org> Message-ID: <062.aee7ccdb89166e7d4034172fa204e627@haskell.org> #13075: Top-level bang pattern accepted -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T13075 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Done! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 10:27:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 10:27:10 -0000 Subject: [GHC] #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order In-Reply-To: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> References: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> Message-ID: <065.219d7166fb09e8385de514f7eafa1fb4@haskell.org> #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14529, #14796 | Differential Rev(s): Phab:D4413 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Richard, I'm disturbed by this. * The [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#visible-type-application spec for visible type application] says that we quantify implicit variables in left-to-right order; but that we perturb that order to respect dependency, speaking of a "table topological sort". * But I can't find a single comment or Note in the source code to point out where these things are implemented. * In the case in point for #14808, we have [https://phabricator.haskell.org/D4413 this fix] in `RnSource`. Although the comment doesn't say ''why'' the order is important, I infer (from detective work) that: * `extractHsTysRdrTyVarsDups` guarantees to return variables in left-to- right order * The `hsq_implicit` field of `LHsQTyVars` is an ''ordered'' list, specifically in left to right order. Can it contain duplicates? I think not, but again that is not duplicated. * There is a `toposortTyVars` in `TcImplicitTKBndrsX` which does the perturbing to respect dependency. But again there is zero documentation that it must be a stable topo-sort, or why. It should not take detective work to infer this info. If my suppositions are correct, could you * Document the key invariants on data types * Add a Note to explain the moving parts and * Refer to it from appropriate places. E.g. I bet the same ordering constraints apply to `hsib_ars` field of `HsImplicitBndrs`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 10:27:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 10:27:38 -0000 Subject: [GHC] #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order In-Reply-To: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> References: <050.90702c1fad16a72a2e55cb4eeb0cc78a@haskell.org> Message-ID: <065.6b56e15de3632d0c7b0b65883207e0f5@haskell.org> #14808: GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14529, #14796 | Differential Rev(s): Phab:D4413 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 10:55:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 10:55:38 -0000 Subject: [GHC] #14859: Allow explicit impredicativity Message-ID: <046.bce52cd0cbee25c5f867b88fe7e6b527@haskell.org> #14859: Allow explicit impredicativity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In [https://mail.haskell.org/pipermail/ghc-devs/2016-September/012940.html this email] I suggested allowing a simple form of impredicativity. With a suitable extension flag (`-XExplicitImpredicativeTypes` perhaps), you woudl be allowed: * To write a polytype in a visible type argument; eg. `f @(forall a. a->a)` * To write a polytype as an argument of a type in a signature e.g. `f :: [forall a. a->a] -> Int` ''But that’s all''. A unification variable still cannot be unified with a polytype. The only way you can call a polymorphic function at a polytype is to use Visible Type Application (VTA). So using impredicative types might be tiresome. E.g. {{{ type SID = forall a. a->a xs :: [forall a. a->a] xs = (:) @SID id ( (:) @SID id ([] @ SID)) }}} In short, if you call a function at a polytype, you must use VTA. Simple, easy, predictable; and doubtless annoying. But at least it's possible. The main motivation is that we are naughtily doing this anyway in the implementation of `GeneralisedNewtypeDeriving` -- see Trac #14070 comment:23 ff. If we are doing it under the hood, we could just made it available to programmers. This is much less ambitious, and much easier to implement, than the proposed [https://www.microsoft.com/en-us/research/publication/guarded- impredicative-polymorphism/ Guarded impredicative polymorphism] (PLDI'18). This ticket just records the idea, to see what other use-cases people might want to add. Then someone would have to write a GHC proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 10:56:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 10:56:25 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxNDA3MDogQWxsb3cg4oCYdW5zYWZl4oCZIGRl?= =?utf-8?q?riving_strategy=2C_deriving_code_with_=E2=80=98unsafeC?= =?utf-8?b?b2VyY2XigJk=?= In-Reply-To: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> References: <051.0e42ce81d7ed5c83d414a8f7e3942e84@haskell.org> Message-ID: <066.52d13e53f47de4624939119936d6a472@haskell.org> #14070: Allow ‘unsafe’ deriving strategy, deriving code with ‘unsafeCoerce’ -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | QuantifiedConstraints, deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not sure I feel up to writing a proposal just now, but I made a ticket. (Better than an obscure email.) Trac #14859. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 10:57:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 10:57:14 -0000 Subject: [GHC] #14859: Allow explicit impredicativity In-Reply-To: <046.bce52cd0cbee25c5f867b88fe7e6b527@haskell.org> References: <046.bce52cd0cbee25c5f867b88fe7e6b527@haskell.org> Message-ID: <061.b0bcd772e0385f4191dd34e53403f0e5@haskell.org> #14859: Allow explicit impredicativity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | ImpredicativeTypes 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: => ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 11:30:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 11:30:29 -0000 Subject: [GHC] #14824: automatically select instance In-Reply-To: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> References: <044.f0689fe9c6bac9e5562a89f49f1f1955@haskell.org> Message-ID: <059.fd89c76e790ae8ecf3d687f614d06a97@haskell.org> #14824: automatically select instance -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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 AntC): See the Haskell 2010 Report section 4.3.4 **Ambiguous types, ...** The type for your expression `m [X1] :: forall a0. C X1 a0 => a0`. You've put the expression at the GHCi `*Main>` prompt, so there's an implicit `print` around it, which gives type {{{ forall a0. (C X1 a0, Show a0) => String }}} Then type var `a0` is ambiguous in the sense in section 4.3.4. That's what the error message is saying. What type do you expect GHC to infer for `a0`? What are the rules of inference that will give that type? Please reference the Haskell 2010 Report and/or GHC User Guide. Explain how the rules will work for expression `m [X0]` -- given the instances for class `C` as above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 11:33:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 11:33:59 -0000 Subject: [GHC] #14859: Allow explicit impredicativity In-Reply-To: <046.bce52cd0cbee25c5f867b88fe7e6b527@haskell.org> References: <046.bce52cd0cbee25c5f867b88fe7e6b527@haskell.org> Message-ID: <061.d0cc3be6956397544ecd124612c628bc@haskell.org> #14859: Allow explicit impredicativity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 12:53:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 12:53:29 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe In-Reply-To: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> References: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> Message-ID: <057.ef5a9dc290b38a793483dda230867a86@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): But wouldn't that run into problems if the index changes? If we add or remove imports, or if we compile a different subset of modules, or if we compile a module by itself using `ghc -c`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 13:46:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 13:46:12 -0000 Subject: [GHC] #14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)? In-Reply-To: <051.a778d1e6d6328a1b4ad713bf62d01c81@haskell.org> References: <051.a778d1e6d6328a1b4ad713bf62d01c81@haskell.org> Message-ID: <066.50708e8de203e2a308ec61c6527d93fa@haskell.org> #14833: QuantifiedConstraints: GHC can't deduce (() :: Constraint)? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T14833 Blocked By: | Blocking: Related Tickets: #14835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => quantified-constraints/T14833 * status: new => closed * resolution: => fixed Comment: I've fixed this one -- on `wip/T2893` as always. == {{{ commit 60f682407eefdb7884d12ba43d00add0c1ca9245 Author: Simon Peyton Jones Date: Tue Feb 27 13:43:26 2018 +0000 Fix a bunch of buglets in QuantifiedConstraints * Freshen tyvars in Inst.instDFunType * Freshen tyvars in TcCanonical.solveForAll * Define TcSMonad.mightMatchLater, and use it (fixes Trac #14833) * Add testsuite directry tests/quantified-constraints/, and start to populate it compiler/typecheck/Inst.hs | 8 ++++++-- compiler/typecheck/TcCanonical.hs | 22 ++++++++++++++-------- compiler/typecheck/TcEvidence.hs | 2 -- compiler/typecheck/TcInteract.hs | 34 ++++++++++++++++------------------ compiler/typecheck/TcSMonad.hs | 21 +++++++++++---------- compiler/typecheck/TcValidity.hs | 3 ++- compiler/types/Type.hs | 2 +- testsuite/tests/quantified-constraints/T14833.hs | 28 ++++++++++++++++++++++++++++ testsuite/tests/quantified-constraints/T2893.hs | 18 ++++++++++++++++++ testsuite/tests/quantified-constraints/T2893a.hs | 27 +++++++++++++++++++++++++++ testsuite/tests/quantified-constraints/T2893b.hs | 24 ++++++++++++++++++++++++ testsuite/tests/quantified-constraints/all.T | 4 ++++ testsuite/tests/typecheck/should_compile/T2893.hs | 18 ------------------ testsuite/tests/typecheck/should_compile/T2893a.hs | 27 --------------------------- testsuite/tests/typecheck/should_compile/all.T | 2 -- 15 files changed, 151 insertions(+), 89 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 13:50:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 13:50:25 -0000 Subject: [GHC] #14835: QuantifiedConstraints: Can't deduce "(a, b)" from "a" and "b" In-Reply-To: <051.57aa3dd69186275a0a16899ee990e8c4@haskell.org> References: <051.57aa3dd69186275a0a16899ee990e8c4@haskell.org> Message-ID: <066.baf1d63c5007146dbc5708eb8b25e0fb@haskell.org> #14835: QuantifiedConstraints: Can't deduce "(a, b)" from "a" and "b" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T14835 Blocked By: | Blocking: Related Tickets: #14833 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => quantified-constraints/T14835 * status: new => closed * resolution: => fixed Comment: Yes, fixed with #14833. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 13:55:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 13:55:08 -0000 Subject: [GHC] #14840: QuantifiedConstraints: Can't define class alias In-Reply-To: <051.efc0726cd0630f1f9a6cfd923f4eea44@haskell.org> References: <051.efc0726cd0630f1f9a6cfd923f4eea44@haskell.org> Message-ID: <066.a28bf9b73890b484420d7e375f601bbe@haskell.org> #14840: QuantifiedConstraints: Can't define class alias -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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 the Description is not-a-bug. I don't understand comment:1. You seem to be giving a quantified constraint like {{{ forall (sum :: Constraint). blah => sum }}} which asserts that for ANY constraint we can solve with this quantified constraint. That can't be right can it? I'll close this ticket, but do open a new one if you think comment:1 holds water somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 14:00:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 14:00:15 -0000 Subject: [GHC] #14857: GHC-8.4.1 release notes don't mention 'Div', 'Mod' and other type families In-Reply-To: <047.09b32790742451b61f5bc476fd1d389a@haskell.org> References: <047.09b32790742451b61f5bc476fd1d389a@haskell.org> Message-ID: <062.686a763610c49af7fd9ab90a47c3bd72@haskell.org> #14857: GHC-8.4.1 release notes don't mention 'Div', 'Mod' and other type families -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Documentation | Version: 8.4.1-alpha3 Resolution: | Keywords: | base,documentation,div,mod,type | families,changelog,release notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chshersh): Thanks for your response! I just saw that `base` library in mentioned in GHC changelog and thought that every change in bundled libraries is documented there. I think that mentioning only most important changes and providing link to library changelog is the best solution! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 14:11:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 14:11:09 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe In-Reply-To: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> References: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> Message-ID: <057.e975fbcbf3cb4a17215dc41ac9fd970d@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Yes, that scheme lacks "stability" against some use cases. Most prominently, adding a new module and importing it, thus turning e.g. `[1 of 3]` into `[2 of 4]`, will have us end up with different uniques and thus different `.o` files and different binaries (and the benefit of reduced `[TH]` compilations is lost for such changes). But the scheme should still solve the most common use cases: * A from-scratch build using the same code and same compiler would result in byte-identical outputs * Resuming a `--make` (`-j`) build after merely touching a file or changing a comment would result in byte-identical outputs * Resuming a `--make` (`-j`) build after changing the code in a module will would result in only the `.o` for that module to change (plus potentially some inlining sites if `-O` is on); `.o` files that were recompiled because of `[TH]` that generate identical `.o` outputs will allow for the identical-.o-file-`[TH]`-avoidance you proposed above The first point will allow us to get byte-reproducible binaries ala Debian's "reproducible builds"; until now due to Unique nondeterminism, this wasn't possible even under guaranteed input control and stopping-the- system-time sandboxes, as Nix does it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 14:19:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 14:19:19 -0000 Subject: [GHC] #14832: QuantifiedConstraints: Adding to the context causes failure In-Reply-To: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> References: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> Message-ID: <066.d47e319966a1bf07b927f68d9d1fae18@haskell.org> #14832: QuantifiedConstraints: Adding to the context causes failure -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): Using the latest commit on the `wip/T2893` branch, this program now gives you a stack overflow! {{{ $ inplace/bin/ghc-stage2 --interactive ../Bug.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( ../Bug.hs, interpreted ) ../Bug.hs:15:10: error: • Reduction stack overflow; size = 201 When simplifying the following type: rel xx yy0 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) • In the instance declaration for ‘Category (With rel)’ | 15 | instance (Refl rel, Trans rel) => Category (With rel) where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 14:35:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 14:35:10 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family Message-ID: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program fails to typecheck using the `wip/T2893` branch, to my surprise: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Proxy type family Apply (f :: * -> *) a type instance Apply Proxy a = Proxy a data ExTyFam f where MkExTyFam :: Apply f a -> ExTyFam f instance (forall a. Show (Apply f a)) => Show (ExTyFam f) where show (MkExTyFam x) = show x showsPrec = undefined -- Not defining these leads to the oddities observed in showList = undefined -- https://ghc.haskell.org/trac/ghc/ticket/5927#comment:32 test :: ExTyFam Proxy -> String test = show }}} This fails with: {{{ $ ghc-cq/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:17:24: error: • Could not deduce (Show (Apply f a)) arising from a use of ‘show’ from the context: forall a. Show (Apply f a) bound by the instance declaration at Bug.hs:16:10-57 • In the expression: show x In an equation for ‘show’: show (MkExTyFam x) = show x In the instance declaration for ‘Show (ExTyFam f)’ | 17 | show (MkExTyFam x) = show x | ^^^^^^ }}} I would have expected the `(forall a. Show (Apply f a))` quantified constraint to kick in, but it didn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 14:43:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 14:43:46 -0000 Subject: [GHC] #14861: QuantifiedConstraints: Can't use forall'd variable in context Message-ID: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> #14861: QuantifiedConstraints: Can't use forall'd variable in context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This fails to typecheck, to my surprise: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind data ECC1 :: (Type -> Constraint) -> (Type -> Type) -> Type -> Type where ECC1 :: c p => f p -> ECC1 c f p class Foldable' f where foldMap' :: Monoid m => (a -> m) -> f a -> m instance (forall p. c p => Foldable' f) => Foldable' (ECC1 c f) where foldMap' f (ECC1 x) = foldMap' f x instance Foldable' [] where foldMap' = foldMap test :: ECC1 Show [] Ordering -> Ordering test = foldMap' id }}} {{{ $ ghc-cq/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:18:25: error: • Could not deduce: c p0 arising from a use of ‘foldMap'’ from the context: forall p. c p => Foldable' f bound by the instance declaration at Bug.hs:17:10-63 or from: Monoid m bound by the type signature for: foldMap' :: forall m a. Monoid m => (a -> m) -> ECC1 c f a -> m at Bug.hs:18:3-10 or from: c a bound by a pattern with constructor: ECC1 :: forall (f :: * -> *) p (c :: * -> Constraint). c p => f p -> ECC1 c f p, in an equation for ‘foldMap'’ at Bug.hs:18:15-20 • In the expression: foldMap' f x In an equation for ‘foldMap'’: foldMap' f (ECC1 x) = foldMap' f x In the instance declaration for ‘Foldable' (ECC1 c f)’ • Relevant bindings include foldMap' :: (a -> m) -> ECC1 c f a -> m (bound at Bug.hs:18:3) | 18 | foldMap' f (ECC1 x) = foldMap' f x | ^^^^^^^^^^^^ }}} I would have expected the `(forall p. c p => Foldable' f)` quantified constraint to kick in there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 14:58:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 14:58:20 -0000 Subject: [GHC] #14848: -XDuplicateRecordFields breaks record expression splices In-Reply-To: <048.60548a7facfb2bb72ce43f7899267ddd@haskell.org> References: <048.60548a7facfb2bb72ce43f7899267ddd@haskell.org> Message-ID: <063.dc5f0e65fda9bfb05bae80e39c7bb7d4@haskell.org> #14848: -XDuplicateRecordFields breaks record expression splices -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ORF 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 adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 15:07:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 15:07:50 -0000 Subject: [GHC] #13900: Core lint in BuildFlavour=perf-llvm In-Reply-To: <046.659e0b338788e413a5940905a0f91074@haskell.org> References: <046.659e0b338788e413a5940905a0f91074@haskell.org> Message-ID: <061.ce7fca30965d92203794ca338e71941d@haskell.org> #13900: Core lint in BuildFlavour=perf-llvm -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.3 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 dfeuer): Simon thinks it's most likely that we have trouble with `case` of `join`: {{{#!hs case (join j x= .... in ....) of ... ===> join j x = case ... of ... in case ... of ... }}} This goes wrong if `j` has a `RULE` attached. We either need to apply the transformation in the `RULE` one way or another (Simon thinks he remembers there being a reason not to) or drop the `RULE`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 15:14:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 15:14:43 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.4bcae08b0cbc5cb45c4ba9b455c1e654@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): - Make sure this is truly a regression - Figure out whether the huge coercion is actually the cause - Bisect? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 15:16:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 15:16:35 -0000 Subject: [GHC] #14862: Switching to Cabal 2.2 makes ghc unusable Message-ID: <048.eb29786956ab5b6f0a644e75f882323f@haskell.org> #14862: Switching to Cabal 2.2 makes ghc unusable -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: None | Version: 8.4.1-alpha3 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 bumping Cabal to 2.2 as done [https://phabricator.haskell.org/D4453 here], we end up with a stage 1 GHC that seemingly cannot build a non- segfaulting program. For instance, if one builds the following trivial program with a stage 1 built from the ghc-8.4 branch + the patch above... {{{#!hs import System.Exit main = exitSuccess }}} Then... {{{#!sh $ ./foo Segmentation fault }}} So of course, when we proceed and build stage 2, and then build things with stage 2, all the stage2 commands crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 15:17:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 15:17:20 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.50368afb1d32ea9f283ca96a984b0bfd@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 Comment: For the record, this is another case which would stand to be improved by the coercion dropping proposed in #8095. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 15:18:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 15:18:07 -0000 Subject: [GHC] #14863: QuantifiedConstraints: Can't deduce `c' from `(a, b)' and `a |- b |- c' Message-ID: <051.903b58847c266d2c5a5e433b5aee3bbf@haskell.org> #14863: QuantifiedConstraints: Can't deduce `c' from `(a, b)' and `a |- b |- c' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints wipT2893 | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #14833 fixes #14835: we can witness `curryC :: ((a, b) |- c) :- (a |- b |- c)`. Now for the entirely predictable, how about **un**`curryC` {{{#!hs {-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs, LiberalTypeSynonyms, TypeOperators, MultiParamTypeClasses, FlexibleInstances #-} data Dict c where Dict :: c => Dict c infixr |- class (a => b) => (a |- b) instance (a => b) => (a |- b) type a :- b = Dict (a |- b) uncurryC :: forall a b c. (a |- b |- c) :- ((a, b) |- c) uncurryC = Dict }}} {{{ $ ghci -ignore-dot-ghci Z.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Z.hs, interpreted ) Z.hs:13:12: error: • Could not deduce: c arising from a use of ‘Dict’ from the context: a |- (b |- c) bound by a quantified context at Z.hs:1:1 or from: (a, b) bound by a quantified context at Z.hs:1:1 • In the expression: Dict In an equation for ‘uncurryC’: uncurryC = Dict • Relevant bindings include uncurryC :: (a |- (b |- c)) :- ((a, b) |- c) (bound at Z.hs:13:1) | 13 | uncurryC = Dict | ^^^^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 15:24:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 15:24:53 -0000 Subject: [GHC] #14862: Switching to Cabal 2.2 makes ghc unusable In-Reply-To: <048.eb29786956ab5b6f0a644e75f882323f@haskell.org> References: <048.eb29786956ab5b6f0a644e75f882323f@haskell.org> Message-ID: <063.dd4ace2adfe5be4532e26c7ecd558c0e@haskell.org> #14862: Switching to Cabal 2.2 makes ghc unusable -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: None | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Can you try bisecting to find the offending Cabal commit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 15:27:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 15:27:06 -0000 Subject: [GHC] #14862: Switching to Cabal 2.2 makes ghc unusable In-Reply-To: <048.eb29786956ab5b6f0a644e75f882323f@haskell.org> References: <048.eb29786956ab5b6f0a644e75f882323f@haskell.org> Message-ID: <063.4054d89549b890e56a0cc29c9994be92@haskell.org> #14862: Switching to Cabal 2.2 makes ghc unusable -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: None | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: angerman (added) Comment: Additional infos: It's unrelated to `integer-gmp` (I was able to reproduce this with an integer-simple-based GHC build as well); so this leaves `rts`, `ghc-prim` or `base` being possibly miscompiled (wrong/missing compile settings or include headers) due to something that wasn't accounted for in phab:D4453. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 15:34:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 15:34:39 -0000 Subject: [GHC] #14335: Annotations aren't supported with -fexternal-interpreter In-Reply-To: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> References: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> Message-ID: <061.88238eacb1de0fdc23da88130caa55bd@haskell.org> #14335: Annotations aren't supported with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14335 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: JaffaCake (removed) * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:06:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:06:35 -0000 Subject: [GHC] #14863: QuantifiedConstraints: Can't deduce `c' from `(a, b)' and `a |- b |- c' In-Reply-To: <051.903b58847c266d2c5a5e433b5aee3bbf@haskell.org> References: <051.903b58847c266d2c5a5e433b5aee3bbf@haskell.org> Message-ID: <066.fcb1572ff9f65f801de795837940cd9b@haskell.org> #14863: QuantifiedConstraints: Can't deduce `c' from `(a, b)' and `a |- b |- c' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): Once again, I think this `:-` thing is a red herring. Here's what I believe to be the essence of the bug: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module Bug where data Dict c where Dict :: c => Dict c class (a => b) => Implies a b instance (a => b) => Implies a b uncurryCImpredic1 :: forall a b c. Implies a (b => c) => Dict (Implies (a, b) c) uncurryCImpredic1 = Dict uncurryCImpredic2 :: forall a b c. a => Implies b c => Dict (Implies (a, b) c) uncurryCImpredic2 = Dict uncurryC1 :: forall a b c. (a => b => c) => Dict (Implies (a, b) c) uncurryC1 = Dict uncurryC2 :: forall a b c. Implies a (Implies b c) => Dict (Implies (a, b) c) uncurryC2 = Dict }}} {{{ $ ghc-cq/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:27:13: error: • Could not deduce: c arising from a use of ‘Dict’ from the context: Implies a (Implies b c) bound by the type signature for: uncurryC2 :: forall (a :: Constraint) (b :: Constraint) (c :: Constraint). Implies a (Implies b c) => Dict (Implies (a, b) c) at Bug.hs:26:1-77 or from: (a, b) bound by a quantified context at Bug.hs:1:1 • In the expression: Dict In an equation for ‘uncurryC2’: uncurryC2 = Dict • Relevant bindings include uncurryC2 :: Dict (Implies (a, b) c) (bound at Bug.hs:27:1) | 27 | uncurryC2 = Dict | ^^^^ }}} All of these `uncurryC`-functions typecheck except for `uncurryC2`. (Note that the first two require `ImpredicativeTypes`, so I'm not sure if this is intended to be supported or not.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:06:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:06:49 -0000 Subject: [GHC] #14335: Annotations aren't supported with -fexternal-interpreter In-Reply-To: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> References: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> Message-ID: <061.9e10be516736853fa3dbe7644e355096@haskell.org> #14335: Annotations aren't supported with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14335 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Conclusion from offline discussion: * Probably not easy to make this work, because a lot of stuff would have to be serialized to be able to run the plugin in the external interpreter (Core, typechecker state, etc.) * We should document the limitation and emit a better error message * Possibly for the future: run the plugin with the internal interpreter while using the external interpreter for other things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:18:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:18:36 -0000 Subject: [GHC] #14832: QuantifiedConstraints: Adding to the context causes failure In-Reply-To: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> References: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> Message-ID: <066.a240a7b8b73c6a2541533483f666d1bd@haskell.org> #14832: QuantifiedConstraints: Adding to the context causes failure -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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): What is "this program"? The one in comment:4 uses `CCategory` but does not define it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:20:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:20:44 -0000 Subject: [GHC] #14779: Compiling with -g fails -lint-core checks In-Reply-To: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> References: <046.6e6bd1042efbe2eb4e6d4f927eb5bdcd@haskell.org> Message-ID: <061.bf93f2fa758a6581f65b7d8c4cce05f6@haskell.org> #14779: Compiling with -g fails -lint-core checks -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Debugging) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14122, #14123, | Differential Rev(s): phab:D4423 #8472, #14406 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Current plan: Don't do anything special to top level primitive literals, have the same behavior for nested and for top level. Throw away top level ticks going in `CoreToSTG`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:25:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:25:35 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.49d54af337ac3a58ddc8e83bd1fe7902@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 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): Remember, a quantified constraint is a bit like a local instance declaration. We don't allow {{{ instance C (F a) where ... }}} where `F` is a type function; and no more should we allow {{{ forall a. Show (Apply f a) }}} as a quantified constraint (`Apply` is a type function). It's a bug that I do not reject it. This works {{{ type family Apply (f :: * -> *) :: * -> * type instance Apply Proxy = Proxy instance (t ~ Apply f, forall a. Show (t a)) => Show (ExTyFam f) where }}} It's tiresome to lift the family application out, but it forces you to ensure that the instance head is ok. Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:27:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:27:16 -0000 Subject: [GHC] #14832: QuantifiedConstraints: Adding to the context causes failure In-Reply-To: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> References: <051.dff6dedd461af3d1758ad7cdadcbf206@haskell.org> Message-ID: <066.c89c1e39ad3c07c7b34729f072bd35a5@haskell.org> #14832: QuantifiedConstraints: Adding to the context causes failure -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: 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'm referring to the original program itself: {{{#!hs {-# Language QuantifiedConstraints, RankNTypes, PolyKinds, ConstraintKinds, UndecidableInstances, GADTs #-} import Control.Category import Data.Kind import Data.Coerce data With cls a b where With :: cls a b => With cls a b type Coercion = With Coercible type Refl rel = (forall xx. rel xx xx :: Constraint) type Trans rel = (forall xx yy zz. (rel xx yy, rel yy zz) => rel xx zz :: Constraint) instance (Refl rel, Trans rel) => Category (With rel) where id = With (.) = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:28:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:28:06 -0000 Subject: [GHC] #14861: QuantifiedConstraints: Can't use forall'd variable in context In-Reply-To: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> References: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> Message-ID: <065.01f77571ddd7cd3172c282c6f000b4f8@haskell.org> #14861: QuantifiedConstraints: Can't use forall'd variable in context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 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 would have expected the (forall p. c p => Foldable' f) quantified constraint to kick in there. Can you say why? We are trying to solve `c beta`. How does the quantified constraint help with that? It tells how to solve `Foldable` constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:32:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:32:49 -0000 Subject: [GHC] #14861: QuantifiedConstraints: Can't use forall'd variable in context In-Reply-To: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> References: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> Message-ID: <065.59ae4d154ca949c86834283119061963@haskell.org> #14861: QuantifiedConstraints: Can't use forall'd variable in context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:1 simonpj]: > Can you say why? When we pattern-match on `ECC1`, we bring into scope the given constraint `c p0`, where `p0` is a fresh type variable. We have as a constraint: {{{#!hs (forall p. c p => Foldable' f) }}} GHC should be able to use the given `c p0` constraint to discharge the obligation and conclude `Foldable' f`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:33:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:33:29 -0000 Subject: [GHC] #14863: QuantifiedConstraints: Can't deduce `c' from `(a, b)' and `a |- b |- c' In-Reply-To: <051.903b58847c266d2c5a5e433b5aee3bbf@haskell.org> References: <051.903b58847c266d2c5a5e433b5aee3bbf@haskell.org> Message-ID: <066.64b79dca3ad304e6ea6966510fc1f27b@haskell.org> #14863: QuantifiedConstraints: Can't deduce `c' from `(a, b)' and `a |- b |- c' -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In `uncurryC2` we have a given {{{ [G] Implies a (Implies b c) }}} by taking its superclass we also have {{{ [G] forall. a => Implies b c }}} But now we are stuck because I have not yet implemented the superclass story for quantified constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:39:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:39:25 -0000 Subject: [GHC] #14861: QuantifiedConstraints: Can't use forall'd variable in context In-Reply-To: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> References: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> Message-ID: <065.678f5204246a19c22522248760d17c5c@haskell.org> #14861: QuantifiedConstraints: Can't use forall'd variable in context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 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): If I have {{{ instance forall p. Show p => Show T }}} then when I invoke the instance declaration I get a `Show beta` constraint with absolutely nothing telling the compiler what `beta` should be. Yes, it could be solved with `beta := Int` or a variety of other things. But GHC never guesses. Same here. You have {{{ instance (forall p. c p => Foldable' f) -- Yikes: nothing constrains p => Foldable' (ECC1 c f) where }}} When the quantified constraint fires, to solve `Foldable' f`, it generates `c beta` with no constraints whatsoever on `beta`. The fact that we have in scope `c p` does not help, because it requires quessing that `beta := p`. Sorry! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:40:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:40:47 -0000 Subject: [GHC] #14864: Suggestion: Turn on +RTS -xt by default Message-ID: <050.42bcc4fe10d01e1047b11cdb8507c4d0@haskell.org> #14864: Suggestion: Turn on +RTS -xt by default -------------------------------------+------------------------------------- Reporter: ryantrinkle | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Runtime | Version: 8.2.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I found it quite surprising and difficult to debug that my heap profile showed no leak while the GC stats showed a clear leak. As a user who is somewhat familiar with this stuff, I was quite surprised that those two data sources didn't agree. I wasn't sure how to determine why they disagreed, since none of the output referenced anything interesting. I'm not familiar with the reasoning behind disabling -xt by default, but I think it may be easier for users to figure out that they need to *disable* it (since they'll be able to see its results in the heap profile) than to figure out that they need to *enable* it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:43:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:43:47 -0000 Subject: [GHC] #14861: QuantifiedConstraints: Can't use forall'd variable in context In-Reply-To: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> References: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> Message-ID: <065.3e60722d484d29546a420af86cada31f@haskell.org> #14861: QuantifiedConstraints: Can't use forall'd variable in context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 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 don't think we're talking about the same thing here. You're talking about solving `beta := Int`, but I'm not asking for that! After, if you had: {{{#!hs instance forall p. Show p => Show T }}} Then that forces GHC to be //parametric// in `p` (so trying to solve `p := Int` would certainly be nonsense). Similarly, in: {{{#!hs instance (forall p. c p => Foldable' f) -- Yikes: nothing constrains p => Foldable' (ECC1 c f) where }}} You put "Yikes: nothing constrains `p`" here, but that is intentional! The whole point is that this constraint must be //parametric// in `p`. Therefore, if we have a given constraint of the form `c Int`, then this certainly couldn't be used to discharge that quantified constraint. However, the code I wrote should work, since the given constraint we have is `c p0`—this does not violate the parametricity of `p`, as `p0` is simply a skolem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:51:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:51:23 -0000 Subject: [GHC] #14864: Suggestion: Turn on +RTS -xt by default In-Reply-To: <050.42bcc4fe10d01e1047b11cdb8507c4d0@haskell.org> References: <050.42bcc4fe10d01e1047b11cdb8507c4d0@haskell.org> Message-ID: <065.edb219b2344cbd7df77a718592777ed4@haskell.org> #14864: Suggestion: Turn on +RTS -xt by default -------------------------------------+------------------------------------- Reporter: ryantrinkle | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Jaffacake (added) Comment: I'll admit I don't even see why you would want to disable `-xt`. Perhaps Jaffacake can shed some light on this? If there is a good reason why running without `-xt` is useful then we'll need to add a way to disable it in order to act on this ticket. Otherwise I would say in the long-run we probably ought to deprecate the option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:51:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:51:46 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.909bdf943d7fabda8d0e88ae68edf9e3@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. This is interesting. We have {{{ $dmshowsPrec :: Show a => Int -> a -> ShowS }}} and the implied instance decl is {{{ instance (forall a. c a => Show a) => Show (Exists c) where show (Exists a) = show a showsPrec = $dmshowsPrec }}} From the RHS of `showsPred` we get `[W] Show (Exists c)`. And ''alas'' we try to solve that from the quantified constraint (which takes precedence over top-level instances), by instantiating `a` to `(Exists c)`. So we get {{{ [W} c (Exists c) }}} which we can't solve. This would happen on any recursive invocation of a method at the same type. It's not clear what we want here. The quantified constraint claims to provide an instance ''for every type a'' which is jolly suspicious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:55:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:55:31 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.703d916d366d80602e82c02c15b85549@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 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 mean, that technically works, but you're cheating a little, as you're changing the definition of `Apply`. In the code that I actually want to write, such a transformation is impossible, since I need to be able to use the last argument of `Apply` in its definition. In any case, I don't see why this type-families-in-instance restriction need apply here. I can certainly see why we'd rule out: {{{#!hs instance C (F a) where ... }}} As a top-level instance. However, as a quantified constraint: {{{#!hs forall a. Show (Apply f a) }}} This should be acceptable. Whenever you _use_ this constraint, it certainly must be the case that we reduce this to something that is type- family–free. This is why this would work: {{{#!hs test :: ExTyFam Proxy -> String test = show }}} Since we would be able to reduce `forall a. Show (Apply Proxy a)` to `forall a. Show (Proxy a)`, which has no type families. (If that weren't the case, then I'd certainly expect GHC to error.) Does that make sense? This is exactly along the same vein as previous generalizations brought about due to quantified constraints. After all, we don't allow this as a top-level instance: {{{#!hs instance Show a => c (F a) }}} But we //do// allow this to appear as a quantified constraint (when we use it, it must be the case that this turns into something with an actual class for `c`). This proposed generalization fits into that tradition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 16:56:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 16:56:24 -0000 Subject: [GHC] #14861: QuantifiedConstraints: Can't use forall'd variable in context In-Reply-To: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> References: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> Message-ID: <065.37b38a3458851d9f836391483589d10c@haskell.org> #14861: QuantifiedConstraints: Can't use forall'd variable in context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 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): No, p is not a skolem. Think of the quantified constraint like a local instance decl. It says {{{ local instance forall p. c p => Foldable' f }}} That means, if you want to solve `Foldable' f` (where `f` really is a skolem coming from the instance for `Foldable' (ECC1 c f)`), then * If you can solve `c beta`, where you are free to pick beta * then you can solve `Foldable' f` So we have to guess `beta`. And we can't. Try some top level instances with tyars on the left which don't appear on the right {{{ instance C a => C [b] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 17:01:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 17:01:58 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.630511ebf1ac1319e773ba4c5b09a84f@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 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): But the error is at line 17, where we don't know `f` and cannot reduce `Apply f a`. So we really do have a local instance {{{ local instance forall a. Show (Apply f a) }}} You might argue that we should use it to solve `Show (Apply f Int)` or any other instantiation, but we don't. Because we don't expect type functions in instance heads. (And BTW it's possible that `Show (Apply f Int)` might reduce to `Show Bool` and we'd be stuck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 17:12:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 17:12:45 -0000 Subject: [GHC] #14861: QuantifiedConstraints: Can't use forall'd variable in context In-Reply-To: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> References: <050.28bc60a4ee570a7514f6106eefe47058@haskell.org> Message-ID: <065.43199d6ff208640ad604cd4dbc93ba8f@haskell.org> #14861: QuantifiedConstraints: Can't use forall'd variable in context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: invalid | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Hm. Your point about `instance C a => C [b]` being wonky is a good one. In practice, such an instance would probably be OK if we could explicitly manipulate dictionaries and specify what exactly `a` should be whenever we applied it. But alas, we cannot, and GHC is unwilling to do this for us, so I'm forced to agree that this is in the realm of the impossible for the time being. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 17:17:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 17:17:19 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.7eb6032d3e39d656d979a8b0a7fcad74@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:3 simonpj]: > (And BTW it's possible that `Show (Apply f Int)` might reduce to `Show Bool` and we'd be stuck. So? If we ever use this instance an get `Show Bool`, then reject that use site! Just as you would reject if you tried to use an instance that had a quantified constraint `(forall xx. c (Free c xx))` and you tried to instantiate `c` with, say, `Show`, and there is no `Show (Free Show xx)` instance. You keep muttering about "we don't expect type functions in instance heads". I would qualify that statement to "we don't expect type functions in //top-level// instance heads"—there shouldn't be anything problematic about allowing them in quantified constraints! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 17:25:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 17:25:24 -0000 Subject: [GHC] #5927: A type-level "implies" constraint on Constraints In-Reply-To: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> References: <048.176646aa6f5f9bdf7a2953e1f3bc3e76@haskell.org> Message-ID: <063.a80ef93d4e8aec9b9d3f96ede03ca6f7@haskell.org> #5927: A type-level "implies" constraint on Constraints -------------------------------------+------------------------------------- Reporter: illissius | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Keywords: Resolution: duplicate | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm. That is not at all how I would have expected that instance to be solved. I agree that when typechecking `$dmshowsPrec`, we should start with: * `[W] Show (Exists c)` But don't we get that immediately? In other words, this typechecks: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE UndecidableInstances #-} module T5927 where import Text.Show data Exists c where Exists :: c a => a -> Exists c instance Show (Exists c) where show = show showsPrec = undefined showList = undefined }}} Because when typechecking the RHS of `show`, we need `[W] Show (Exists c)`, but we already have that. It's only when we strengthen the context: {{{#!hs instance (forall a. c a => Show a) => Show (Exists c) where show = show showsPrec = undefined showList = undefined }}} That GHC complains: {{{ Bug.hs:12:10: error: • Could not deduce: c (Exists c) arising from a use of ‘show’ from the context: forall a. c a => Show a bound by the instance declaration at Bug.hs:11:10-53 • In the expression: show In an equation for ‘show’: show = show In the instance declaration for ‘Show (Exists c)’ • Relevant bindings include show :: Exists c -> String (bound at Bug.hs:12:3) | 12 | show = show | ^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 17:25:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 17:25:48 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.811c56e2d8ff6d7d35ad4d4cc706a138@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 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 shouldn't be anything problematic about allowing them in quantified constraints! But I think there absolutely IS something problematic! At least I have no idea how to specify or implement a system that allows them. Maybe I'm just being dense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 17:28:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 17:28:27 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.c890d158a986586172906299273c5657@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm struggling with this one, worried about order-dependence. Suppose `Apply f Int` is `Bool`. Now suppose we are given `forall a. Show (Apply f a)` and want to prove `Show (Apply f Int)`. In considering the wanted `Show (Apply f Int)`, we have two choices of how to proceed: 1. Use the given and succeed. 2. Reduce `Apply f Int` to `Bool` and fail. The problem is that it seems challenging to guarantee that we don't do (2). Simon's answer appears to be to simply disallow the constraint in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 17:32:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 17:32:54 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.e26b280ed023362ce481459333ad0963@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 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): In response to goldfire's question, let me ask an analogous one. Currently, we allow this: {{{#!hs instance (forall xx. c (Free c xx)) => Monad (Free c) where Free f >>= g = f g }}} Also, assume there is no `Show (Free Show xx)` instance. Now suppose we are given `(forall xx. c (Free c xx))`, and we want to prove `Show (Free Show xx)`. In considering the wanted `Show (Free Show xx)`, we have two choices of how to proceed: 1. Use the given and succeed. 2. Attempt to resolve the `Show (Free Show xx)` instance and fail. The exact same problem seems to arise here, so why isn't this disallowed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 17:37:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 17:37:17 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.0414b9b44fb96f081b03f879ad217d1c@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Indeed, GHC appears to have no trouble with this: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Control.Monad newtype Free cls a = Free (forall xx. cls xx => (a -> xx) -> xx) instance Functor (Free cls) instance Applicative (Free cls) instance (forall xx. cls (Free cls xx)) => Monad (Free cls) where Free f >>= g = f g f :: Free Show (Free Show a) -> Free Show a f = join }}} {{{ Bug.hs:18:5: error: • No instance for (Show (Free Show xx)) arising from a use of ‘join’ • In the expression: join In an equation for ‘f’: f = join | 18 | f = join | ^^^^ }}} Here, we reject the use site, not the instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 17:39:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 17:39:38 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.9930afd6437f8e79c793c056c35969c6@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 17:43:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 17:43:51 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.3007df4aafa4f44bd44a97aa5037d5ba@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 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): Re comment:7 there are no type functions are there. It's the function in the constraint head that is the nub of the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 17:51:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 17:51:57 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.95b946d158f4c49495edabc52175e8b3@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:10 simonpj]: > Re comment:7 there are no type functions are there. It's the function in the constraint head that is the nub of the problem. Again... so what? I'm trying to demonstrate why hypothetically allowing type families in quantified constraints would be no different than allowing type variables heading instances in quantified constraints. So far, the only rebuttal you've given me is "but we don't allow type families in instances", which is circular reasoning. So I'm still left wondering what exactly the substantive difference between these two scenarios is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 18:02:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 18:02:41 -0000 Subject: [GHC] #14862: Switching to Cabal 2.2 makes ghc unusable In-Reply-To: <048.eb29786956ab5b6f0a644e75f882323f@haskell.org> References: <048.eb29786956ab5b6f0a644e75f882323f@haskell.org> Message-ID: <063.a42e3383e0f5b44d2759d0f1626164bc@haskell.org> #14862: Switching to Cabal 2.2 makes ghc unusable -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: Component: None | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: (none) => alpmestan Comment: refold: most of us suspect the "basedir" PR, I'm trying all sorts of things from gdb/rr to figure out how even that trivial program ends up crashing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 18:09:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 18:09:46 -0000 Subject: [GHC] #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum Message-ID: <049.1d7a87ab72f359297da66e7f8ae2c6cd@haskell.org> #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: UnboxedSums | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's the code in question: {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UnboxedSums #-} {-# LANGUAGE UnboxedTuples #-} {-# OPTIONS_GHC -O2 #-} module Byte.Array.Window ( findByte , boxMaybeInt ) where import Data.Primitive (ByteArray) import Data.Word (Word8) import GHC.Types (RuntimeRep,TYPE) import GHC.Int (Int(I#)) import GHC.Exts (Int#) import qualified Data.Primitive as PM type Maybe# (a :: TYPE (r :: RuntimeRep)) = (# (# #) | a #) boxMaybeInt :: Maybe# Int# -> Maybe Int boxMaybeInt = \case (# | a #) -> Just (I# a) (# (# #) | #) -> Nothing unboxInt :: Int -> Int# unboxInt (I# i) = i -- | Finds the first occurrence of the given byte. -- TODO: optimize this to search through a whole -- Word64 at a time if the bytearray is pinned. findByte :: Int -> Int -> Word8 -> ByteArray -> Maybe Int findByte !off !len !w !arr = boxMaybeInt (go off) where go :: Int -> Maybe# Int# go !ix = if ix < len then if PM.indexByteArray arr ix == w then (# | unboxInt ix #) else go (ix + 1) else (# (# #) | #) }}} When compiled with GHC 8.5 with `-ddump-simpl -dsuppress-all`, here is the relevant part of the resulting Core: {{{ -- RHS size: {terms: 33, types: 13, coercions: 0, joins: 1/1} $wfindByte $wfindByte = \ ww_s38C ww1_s38G ww2_s38K ww3_s38O -> joinrec { $wgo_s38v $wgo_s38v ww4_s38t = case <# ww4_s38t ww1_s38G of { __DEFAULT -> Nothing; 1# -> case indexWord8Array# ww3_s38O ww4_s38t of wild_a36w { __DEFAULT -> case eqWord# wild_a36w ww2_s38K of { __DEFAULT -> jump $wgo_s38v (+# ww4_s38t 1#); 1# -> Just (I# ww4_s38t) } } }; } in jump $wgo_s38v ww_s38C -- RHS size: {terms: 21, types: 12, coercions: 0, joins: 0/0} findByte findByte = \ w_s38w w1_s38x w2_s38y w3_s38z -> case w_s38w of { I# ww1_s38C -> case w1_s38x of { I# ww3_s38G -> case w2_s38y of { W8# ww5_s38K -> case w3_s38z of { ByteArray ww7_s38O -> $wfindByte ww1_s38C ww3_s38G ww5_s38K ww7_s38O } } } } }}} I expected that the tail recursive `go` helpful function from my original code would still be a function that returns an unboxed sum when optimized and turned into Core. However, it isn't. The call to `boxMaybeInt` gets pushed into `go`. This means that when `findByte` is called and the result cased on, an allocation is going to happen. I think it would be preferable for `boxMaybeInt` to not get pushed into the worker, since `boxMaybeInt (go off)` could be inlined and the allocation of `Maybe` could be prevented (assuming that it was cased on right afterward). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 18:32:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 18:32:48 -0000 Subject: [GHC] #855: Improvements to SpecConstr In-Reply-To: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> References: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> Message-ID: <061.eb38947fb7d9dce7890263e440929174@haskell.org> #855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Long story short, I had success with the following [https://github.com/sgraf812/ghc/compare/master...sgraf812:stream-fusion diff]. Currently, it optimizes `ex1` to this code: {{{ -- RHS size: {terms: 39, types: 21, coercions: 0, joins: 3/3} Main.$wex1 [InlPrag=NOINLINE] :: GHC.Prim.Int# -> GHC.Prim.Int# [GblId, Arity=1, Caf=NoCafRefs, Str=, Unf=OtherCon []] Main.$wex1 = \ (ww_s4pl :: GHC.Prim.Int#) -> joinrec { $s$wgo_s4rk :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [LclId[JoinId(3)], Arity=3, Str=] $s$wgo_s4rk _ [Occ=Dead] (sc1_s4ri :: GHC.Prim.Int#) (sc2_s4rh :: GHC.Prim.Int#) = jump $s$wgo2_s4rc sc1_s4ri sc2_s4rh; $s$wgo1_s4rg :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [LclId[JoinId(3)], Arity=3, Str=] $s$wgo1_s4rg (sc_s4rf :: GHC.Prim.Int#) (sc1_s4re :: GHC.Prim.Int#) (sc2_s4rd :: GHC.Prim.Int#) = jump $s$wgo_s4rk sc_s4rf sc1_s4re (GHC.Prim.+# sc2_s4rd sc_s4rf); $s$wgo2_s4rc [Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] $s$wgo2_s4rc (sc_s4rb :: GHC.Prim.Int#) (sc1_s4ra :: GHC.Prim.Int#) = case GHC.Prim.<# sc_s4rb ww_s4pl of { __DEFAULT -> sc1_s4ra; 1# -> jump $s$wgo1_s4rg (GHC.Prim.*# sc_s4rb sc_s4rb) (GHC.Prim.+# sc_s4rb 1#) sc1_s4ra }; } in jump $s$wgo2_s4rc 1# 0# }}} Which is just a stone throw (or rather an inlining pass) away from the `goal`! For the examples `ex{2,3}` with increasing nesting level, things don't look so bright yet. Also I got some cleanup work to do tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 19:08:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 19:08:03 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.89af11e4d6f684d3fd55f6b7e5cd6a63@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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 aosivitz): So, I've recently run into this with a large project (using stack). I've tried to make a small reproduce case but have not succeeded. I generated a stack project that builds a library along with 400 dummy dependencies, each of which has a long package name. This is a larger number of dependencies than my original project, but it doesn't trigger the panic. So is there something else I need to do to cause this? Other funny things I've seen: Sometimes the build fails after `slack clean`, but then builds successfully after running it again. The big difference I see is that in the first case the link command is trying to build '/var/folders/.../ghc4371_0/libghc_100.dylib' when it fails, and in the second case it builds '.stack-work/.../libHSpanictest-0.0.0 -8KaC2kNKjFj6cJfkbgZkev-ghc8.2.2.dylib' and succeeds. Is that just a quirk of stack or would it be a meaningful difference? What does it mean to build 'libghc_X.dylib'? I apologize if this info is too stack specific, but it's hard for me to tell where this problem actually comes from. Also, if anyone could advise me on improving my reproduction case that would be very helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 19:40:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 19:40:13 -0000 Subject: [GHC] #14335: Plugins don't work with -fexternal-interpreter (was: Annotations aren't supported with -fexternal-interpreter) In-Reply-To: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> References: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> Message-ID: <061.0b7ee39de6c8eb2954717937f91ae7b1@haskell.org> #14335: Plugins don't work with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14335 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > It seems that using `{-# ANN #-}` pragmas from a plugin cause GHC to > crash when run with `-fexternal-interpreter` with > {{{ > ghc: this operation requires -fno-external-interpreter > }}} > It seems that the culprit is likely the use of `wormhole` in > `convertAnnotationWrapper`. New description: Original description: ~~It seems that using `{-# ANN #-}` pragmas from a plugin cause GHC to crash when run with `-fexternal-interpreter` with {{{ ghc: this operation requires -fno-external-interpreter }}} It seems that the culprit is likely the use of `wormhole` in `convertAnnotationWrapper`.~~ It turns out this is an issue with `ANN`, as suggested by comment:2 and comment:11, plugins simply don't work with -fexternal-interpreter. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 19:40:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 19:40:38 -0000 Subject: [GHC] #14335: Plugins don't work with -fexternal-interpreter In-Reply-To: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> References: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> Message-ID: <061.a92f226804643c41135d1cbfdd48aef0@haskell.org> #14335: Plugins don't work with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14335 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > Original description: > > ~~It seems that using `{-# ANN #-}` pragmas from a plugin cause GHC to > crash when run with `-fexternal-interpreter` with > {{{ > ghc: this operation requires -fno-external-interpreter > }}} > It seems that the culprit is likely the use of `wormhole` in > `convertAnnotationWrapper`.~~ > > It turns out this is an issue with `ANN`, as suggested by comment:2 and > comment:11, plugins simply don't work with -fexternal-interpreter. New description: Original description: ~~It seems that using `{-# ANN #-}` pragmas from a plugin cause GHC to crash when run with `-fexternal-interpreter` with~~ {{{ ghc: this operation requires -fno-external-interpreter }}} ~~It seems that the culprit is likely the use of `wormhole` in `convertAnnotationWrapper`.~~ It turns out this is an issue with `ANN`, as suggested by comment:2 and comment:11, plugins simply don't work with -fexternal-interpreter. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 21:44:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 21:44:24 -0000 Subject: [GHC] #14066: Skolem escape at the kind level In-Reply-To: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> References: <046.e2349c640a192dfbbdb6f96b014bd586@haskell.org> Message-ID: <061.1cf7d75848de7a38ebf07d45ee7b3c31@haskell.org> #14066: Skolem escape at the kind level -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13364, #14040 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by kcsongor): * wikipage: => https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 21:53:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 21:53:38 -0000 Subject: [GHC] #7503: Bug with PolyKinds, type synonyms & GADTs In-Reply-To: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> References: <053.4d5ff262f4cda4bbcc983d7818db9e21@haskell.org> Message-ID: <068.a6f739c47b145d6a0ab9e7166c9caa57@haskell.org> #7503: Bug with PolyKinds, type synonyms & GADTs -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.1 checker) | Keywords: GADTs, Resolution: | TypeInType Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14451 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by kcsongor): * wikipage: => https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 21:53:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 21:53:59 -0000 Subject: [GHC] #14451: Need proper SCC analysis of type declarations, taking account of CUSKs In-Reply-To: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> References: <051.ebcb090dfb4cfa66ebe4948c4fe597e5@haskell.org> Message-ID: <066.ee8fc5858698ed39c512ed24f7b9fb20@haskell.org> #14451: Need proper SCC analysis of type declarations, taking account of CUSKs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7503 | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by kcsongor): * wikipage: => https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 22:04:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 22:04:33 -0000 Subject: [GHC] #14847: Inferring dependent kinds for non-recursive types In-Reply-To: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> References: <046.faf5ec27e0a837d41fe5bdbe3d601145@haskell.org> Message-ID: <061.5a610be73c879ad6c3d6b1f7f80c0cb2@haskell.org> #14847: Inferring dependent kinds for non-recursive types -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by kcsongor): * wikipage: => https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 22:05:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 22:05:52 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.91efc33963326c56f76b97795a4394fd@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239, | Differential Rev(s): Phab:D2272 #12643, #13790 | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by kcsongor): * wikipage: => https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 22:07:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 22:07:10 -0000 Subject: [GHC] #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations In-Reply-To: <047.18a7617988133530c5da58a1eb2182c3@haskell.org> References: <047.18a7617988133530c5da58a1eb2182c3@haskell.org> Message-ID: <062.91b91a343c0a2edbfaa2001a9c9bd64c@haskell.org> #9427: Do finer-grained dependency analysis to infer more general kinds on type/class declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 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: | https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference| -------------------------------------+------------------------------------- Changes (by kcsongor): * wikipage: => https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 22:26:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 22:26:14 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.c00661807f8d10b0da1a165954307b19@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): A skolem type variable is just like a type constructor. It is equal to itself, nothing else. A type function application stands for what it reduces to. It's not a rigid thing you can match against when matching in instances or type- family definitions. We don't allow {{{ type instance F (G a) = [a] }}} Why not? Because the call `F (G Int)` would match the type instance -- but could also reduce to something that wouldn't match it any more, which would be terrible. In contrast, skolem type variables have no such difficulty. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 22:33:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 22:33:45 -0000 Subject: [GHC] #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum In-Reply-To: <049.1d7a87ab72f359297da66e7f8ae2c6cd@haskell.org> References: <049.1d7a87ab72f359297da66e7f8ae2c6cd@haskell.org> Message-ID: <064.2953e8b56fdbafef37cad64a59142d0e@haskell.org> #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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 simonpj): This is a classic difficulty. Given, say {{{ f x = g (...x...) }}} perhaps we could split `f` into two parts {{{ f x = g (f' x) f' x = ...x... }}} and then perhaps we can inline the (now small) `f`, perhaps to good effect. This is what you want to do here: you want {{{ findByte !off !len !w !arr = boxMaybeInt (go off) }}} to be inlined at every call site. It's be simple to arrange, by giving `len`, `w` and `arr` as extra arguments to `go`. But GHC just isn't clever enough to do that, unless you tell it to do so by hand, with an INLINE pragma. I don't really know how to fix this. But it's a good example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 23:15:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 23:15:46 -0000 Subject: [GHC] #14791: Move stack checks out of code paths that don't use the stack. In-Reply-To: <047.2ea20512b2a37aa4c0736d7573c92c30@haskell.org> References: <047.2ea20512b2a37aa4c0736d7573c92c30@haskell.org> Message-ID: <062.dd275de17d1150565f321f68520d276a@haskell.org> #14791: Move stack checks out of code paths that don't use the stack. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (CodeGen) | Resolution: | Keywords: 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 AndreasK): * component: Compiler => Compiler (CodeGen) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 27 23:24:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Feb 2018 23:24:38 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.7c5701f9bab695d92da7545fb9bad9cb@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: wontfix | QuantifiedConstraints wipT2893 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: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 01:27:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 01:27:55 -0000 Subject: [GHC] #14196: Replace ArrayArray# with either UnliftedArray# or Array# In-Reply-To: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> References: <049.e6e8e74aa5747261fafcac4ff3c72b33@haskell.org> Message-ID: <064.1eaef49acbecfae25e9c3547567d4482@haskell.org> #14196: Replace ArrayArray# with either UnliftedArray# or Array# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: | -------------------------------------+------------------------------------- Comment (by andrewthad): `UnliftedNewtypes` was accepted. I'll begin working on a proposal for `UnliftedArray#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 04:55:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 04:55:42 -0000 Subject: [GHC] #14866: GHC 8.4.1 rc1 segfaults when compiling the influxdb package Message-ID: <047.ed325dee96d48a0801c6e779df8726dd@haskell.org> #14866: GHC 8.4.1 rc1 segfaults when compiling the influxdb package -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 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: -------------------------------------+------------------------------------- I tried to build influxdb-1.2.2.3 with GHC 8.4.1 rc1 built with DYNAMIC_GHC_PROGRAMS=NO. Then I got {{{ [ 8 of 10] Compiling Database.InfluxDB.Query ( src/Database/InfluxDB/Query.hs, /home/fumieval/hs/influxdb-haskell/dist- newstyle/build/x86_64-linux/ghc-8.4.0.20180224/influxdb-1.2.2.3/build/Database/InfluxDB/Query.p_o ) cabal: Failed to build influxdb-1.2.2.3. The build process segfaulted (i.e. SIGSEGV). }}} It seems to be related to Template Haskell, as it doesn't happen if I remove `makeLensesWith` in `Query.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 04:56:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 04:56:24 -0000 Subject: [GHC] #14866: GHC 8.4.1 rc1 segfaults when compiling the influxdb package In-Reply-To: <047.ed325dee96d48a0801c6e779df8726dd@haskell.org> References: <047.ed325dee96d48a0801c6e779df8726dd@haskell.org> Message-ID: <062.2fb665a4aa718f829755eb53be3749c8@haskell.org> #14866: GHC 8.4.1 rc1 segfaults when compiling the influxdb package -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by fumieval): * Attachment "build.mk" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 05:50:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 05:50:43 -0000 Subject: [GHC] #14866: GHC 8.4.1 rc1 segfaults when compiling the influxdb package In-Reply-To: <047.ed325dee96d48a0801c6e779df8726dd@haskell.org> References: <047.ed325dee96d48a0801c6e779df8726dd@haskell.org> Message-ID: <062.835da080b8a371450759410fa6e8c2e3@haskell.org> #14866: GHC 8.4.1 rc1 segfaults when compiling the influxdb package -------------------------------------+------------------------------------- Reporter: fumieval | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.1-alpha3 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: #14705 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by fumieval): * status: new => closed * resolution: => duplicate * related: => #14705 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 06:24:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 06:24:02 -0000 Subject: [GHC] #14444: Linker limit on OS X Sierra breaks builds for big projects In-Reply-To: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> References: <049.ef1cbd3eecd105a31deac573ded19c35@haskell.org> Message-ID: <064.b3301ac5be255395939c03100199f199@haskell.org> #14444: Linker limit on OS X Sierra breaks builds for big projects -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: angerman Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | 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 angerman): So I believe this was mitigated in stack one way or the other; but your ticket commercialhaskell/stack#2577 makes it seem like it isn't. In cabal it is mitigated by haskell/cabal#4656. I guess we should just go ahead and fix it properly in GHC. I feel GHC should fall over quicker if you construct a massive dependency tree with long folder and library names. Of course now that most people using cabal, nix or stack don't hit this issue anymore as hard, the pressure to fix this is not as high anymore. If you as such can reproduce a sample that always fails (it might be sufficient to double your dependencies)that would be helpful. Note however: we will not be able to fix this for the case where all dependencies are direct, without some heavier lifting. IOW if it's the indirect (transitive) dependencies that cause the blow up, we might be able to fix that rather easy. If it is the direct dependencies that cause the blow up, this will pose a harder problem as we'd have to potentially inject pseudo aggregation libraries, which I'd rather not do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 06:33:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 06:33:49 -0000 Subject: [GHC] #14867: make targets for documentation not working Message-ID: <043.0dd6fd21aa956abd3688bcccaf95e777@haskell.org> #14867: make targets for documentation not working -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 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: -------------------------------------+------------------------------------- None of the documentation targets mentioned in the Wiki work: https://ghc.haskell.org/trac/ghc/wiki/Building/StandardTargets#DocumentationTargets As far as I can see there's no mention of how to build documentation in the entire wiki. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 07:03:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 07:03:50 -0000 Subject: [GHC] #14335: Plugins don't work with -fexternal-interpreter In-Reply-To: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> References: <046.25c38c823cb7fca986641ffde5e3cbd0@haskell.org> Message-ID: <061.314c9d05bdbd67e69ee610491ef92bcb@haskell.org> #14335: Plugins don't work with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14335 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4456 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D4456 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 09:18:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 09:18:25 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe In-Reply-To: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> References: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> Message-ID: <057.5e4fbd63cbfa9ff5859d7b52086492e7@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I'm very sceptical (in case you hadn't guessed!). @niteria spent a great deal of time removing cases of non-determinism from the compiler, so that we now have non-determinism at the ABI level. The way it's done currently is more robust than relying on unique determinism, because the compiler produces deterministic output even in the presence of unique non- determinism. Relying on unique determinism is quite fragile and easily broken, and we have no way to know when that happens - at least with the current scheme we have some protection in the APIs for things like `UniqFM` so that it's hard to accidentally introduce non-determinism. I'm really not keen on the idea of using the module index, because compiling a module individually with `-c` should produce exactly the same output as if it was compiled as part of a set of modules with `--make`. Why not instead extend the current mechanism to add non-determinism in the code generator? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 10:34:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 10:34:42 -0000 Subject: [GHC] #14867: [build system] Documentation targets are not working (was: make targets for documentation not working) In-Reply-To: <043.0dd6fd21aa956abd3688bcccaf95e777@haskell.org> References: <043.0dd6fd21aa956abd3688bcccaf95e777@haskell.org> Message-ID: <058.05485dcbcdb06bba9913b212345aef76@haskell.org> #14867: [build system] Documentation targets are not working -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 10:56:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 10:56:54 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.f8489162b58969384e49dce57bd74d63@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: wontfix | QuantifiedConstraints wipT2893 Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): These problems were my original motivation for #14822, if `f` has a singleton we can witness `Show (Apply f a)` without changing the definition of `Apply` {{{#!hs wit :: forall f a. SingI f :- Show (Apply f a) wit = Sub (case sing :: Sing f of SingProxy -> Dict) }}} If we had a way of turning `(a :- b)` into `(a => b)` I think this would solve Ryan's problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 11:18:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 11:18:30 -0000 Subject: [GHC] #14868: -O -g breaks string literals Message-ID: <043.b85ddd9da71a7b040ce01bef4d2ffb0c@haskell.org> #14868: -O -g breaks string literals -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With `foo.hs`: {{{#!hs main = print (4, "foo") }}} Compile it and run it like: {{{ % ghc-stage2 -O -g foo.hs % ./foo (4,"\CANq@") }}} Note that the content of the string literal is broken, although the length is preserved. With `-dcore-lint`, the following error is produced: {{{ *** Core Lint errors : in result of Simplifier *** : warning: [RHS of ww2_s3hG :: Addr#] Recursive or top-level binder has strict demand info: ww2_s3hG Binder's demand info: }}} The offending binding is: {{{#!hs ww2_s3hG :: Addr# [LclId, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] ww2_s3hG = src "foo"# }}} Happens with ghc 8.4.1-rc1 and with HEAD (df2c3b33648). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 12:26:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 12:26:18 -0000 Subject: [GHC] #14862: Switching to Cabal 2.2 makes ghc unusable In-Reply-To: <048.eb29786956ab5b6f0a644e75f882323f@haskell.org> References: <048.eb29786956ab5b6f0a644e75f882323f@haskell.org> Message-ID: <063.4bed72886aadfacc4fe1ef11f9bad9e2@haskell.org> #14862: Switching to Cabal 2.2 makes ghc unusable -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: Component: None | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Alright, so gdb hasn't been all that helpful as it seems that single- stepping somehow makes me follow a codepath that just loops between the scheduler and the top of the haskell stack without really ever making progress. I have not managed to find a breakpoint that's "far enough" so that single-stepping would just lead me right to the crash. However, in the meantime hvr saw that: {{{#!hs import Data.Typeable data Foo = Foo deriving Eq data Bar = Bar deriving Eq main = print (Just Foo == cast Bar) }}} prints `True`, while it should obviously crash (because we'd expect `cast` to return `Nothing` here). What's more: {{{#!hs *Main Data.Typeable λ> typeRepFingerprint (typeRep (Proxy :: Proxy Foo)) 00000000000000000000000000000000 *Main Data.Typeable λ> typeRepFingerprint (typeRep (Proxy :: Proxy Bar)) 00000000000000000000000000000000 }}} hvr and I then looked at the code that generates those fingerprints. We end up calling `fingerprintFingerprints` for both, so I added a `print` to `fingerprintFingerprints` to see what the inputs to the fingerprinting code are in both cases. After digging some more for a while, we ended up realizing that `SIZEOF_STRUCT_MD5CONTEXT` is detected to be... 0! Which cause the md5 context & the digest to overlap in memory, and since we memset the md5 context to 0 at the end of the md5 computation in the C code, we end up with an all-0 digest, whatever the inputs! hvr has reported a fix in [https://phabricator.haskell.org/D4453#123717 the aforementionned diff]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 12:30:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 12:30:34 -0000 Subject: [GHC] #14769: The RecompBecause [TH] check is not resume-build-safe In-Reply-To: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> References: <042.f54ba8f2fbf63135b78d7e32176ce748@haskell.org> Message-ID: <057.e574e48259bb66b075ef1ed708e25336@haskell.org> #14769: The RecompBecause [TH] check is not resume-build-safe -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #481 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Replying to [comment:10 simonmar]: > Why not instead extend the current mechanism to add non-determinism in the code generator? From my side it's just a limitation of how much time I can sink into it. Making uniques not surface at all in the generated code would be great and cover more use cases, like being able to switch between `-c` and `--make` as you say, but an approach like I suggest would already cover the most common use cases (e.g. libraries and binaries built by cabal, Stack, Linux distributions would be deterministic, as they all use `--make`, and `[TH]` recompilation would be reduced), while (to my knowledge) not regressing any existing functionality (switching between `--make` and `-c` would remain as determinism-destroying as they were so far). Also, the two approaches don't seem to be competing -- it appears to me that in an ideal world, GHC would have neither internal variables appear in outputs, nor use any form of module-spanning "impure" internal state driven by `unsafePerformIO` as it has now. Using the module index is a quickest-and-easiest way to map the modules into a compact range of integers for easy array indexing. If this turns out to not be relevant for performance, then I could imagine also using the fully qualified module name or something similar, which might address the `-c` vs `--make` issue. > Relying on unique determinism is quite fragile and easily broken, and we have no way to know when that happens - at least with the current scheme we have some protection in the APIs for things like `UniqFM` so that it's hard to accidentally introduce non-determinism. I'd argue that removing the possibility to access an `unsafePerformIO`-based number generator at all would be a much stronger guarantee that non-determinism cannot be introduced, is that not accurate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 14:26:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 14:26:55 -0000 Subject: [GHC] #14869: Documentation for isLiftedTypeKind is incorrect Message-ID: <050.35651f1fbd8cecc022a69aff4010777f@haskell.org> #14869: Documentation for isLiftedTypeKind is incorrect -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | 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: -------------------------------------+------------------------------------- I [https://github.com/ghc-proposals/ghc- proposals/pull/32#issuecomment-369252383 noticed recently] that Template Haskell reifies `Constraint` as `Type`: {{{#!hs $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeFamilies -XTemplateHaskell λ> :m + Data.Kind Language.Haskell.TH λ> type family Foo :: Constraint λ> putStrLn $(reify ''Foo >>= stringE . pprint) type family Ghci1.Foo :: * }}} The root of the issue can be traced back to the `isLiftedTypeKind` function, which `TcSplice` uses to distinguish `Type` from `Constraint`. At least, that's what its [http://git.haskell.org/ghc.git/blob/df2c3b3364834d2fd038192c89348fc50a2e0475:/compiler/types/TyCoRep.hs#l721 documentation] claims: {{{ -- | This version considers Constraint to be distinct from *. Returns True -- if the argument is equivalent to Type and False otherwise. isLiftedTypeKind :: Kind -> Bool isLiftedTypeKind = is_TYPE is_lifted where is_lifted (TyConApp lifted_rep []) = lifted_rep `hasKey` liftedRepDataConKey is_lifted _ = False }}} However, in practice this claim about treating `Constraint` and `Type` as distinct is false: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive -package ghc GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :m + TyCoRep TysWiredIn λ> isLiftedTypeKind liftedTypeKind True λ> isLiftedTypeKind constraintKind True }}} Either we should change the implementation of `isLiftedTypeKind` to match the documentation's claim, or change the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 14:27:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 14:27:10 -0000 Subject: [GHC] #14869: Documentation for isLiftedTypeKind is incorrect In-Reply-To: <050.35651f1fbd8cecc022a69aff4010777f@haskell.org> References: <050.35651f1fbd8cecc022a69aff4010777f@haskell.org> Message-ID: <065.3bb057df1ced939dfa86b20a7c1d0870@haskell.org> #14869: Documentation for isLiftedTypeKind is incorrect -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | 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: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > I [https://github.com/ghc-proposals/ghc- > proposals/pull/32#issuecomment-369252383 noticed recently] that Template > Haskell reifies `Constraint` as `Type`: > > {{{#!hs > $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive > GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/rgscott/.ghci > λ> :set -XTypeFamilies -XTemplateHaskell > λ> :m + Data.Kind Language.Haskell.TH > λ> type family Foo :: Constraint > λ> putStrLn $(reify ''Foo >>= stringE . pprint) > type family Ghci1.Foo :: * > }}} > > The root of the issue can be traced back to the `isLiftedTypeKind` > function, which `TcSplice` uses to distinguish `Type` from `Constraint`. > At least, that's what its > [http://git.haskell.org/ghc.git/blob/df2c3b3364834d2fd038192c89348fc50a2e0475:/compiler/types/TyCoRep.hs#l721 > documentation] claims: > > {{{ > -- | This version considers Constraint to be distinct from *. Returns > True > -- if the argument is equivalent to Type and False otherwise. > isLiftedTypeKind :: Kind -> Bool > isLiftedTypeKind = is_TYPE is_lifted > where > is_lifted (TyConApp lifted_rep []) = lifted_rep `hasKey` > liftedRepDataConKey > is_lifted _ = False > }}} > > However, in practice this claim about treating `Constraint` and `Type` as > distinct is false: > > {{{ > $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive -package ghc > GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/rgscott/.ghci > λ> :m + TyCoRep TysWiredIn > λ> isLiftedTypeKind liftedTypeKind > True > λ> isLiftedTypeKind constraintKind > True > }}} > > Either we should change the implementation of `isLiftedTypeKind` to match > the documentation's claim, or change the documentation. New description: I [https://github.com/ghc-proposals/ghc- proposals/pull/32#issuecomment-369252383 noticed recently] that Template Haskell reifies `Constraint` as `Type`: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeFamilies -XTemplateHaskell λ> :m + Data.Kind Language.Haskell.TH λ> type family Foo :: Constraint λ> putStrLn $(reify ''Foo >>= stringE . pprint) type family Ghci1.Foo :: * }}} The root of the issue can be traced back to the `isLiftedTypeKind` function, which `TcSplice` uses to distinguish `Type` from `Constraint`. At least, that's what its [http://git.haskell.org/ghc.git/blob/df2c3b3364834d2fd038192c89348fc50a2e0475:/compiler/types/TyCoRep.hs#l721 documentation] claims: {{{ -- | This version considers Constraint to be distinct from *. Returns True -- if the argument is equivalent to Type and False otherwise. isLiftedTypeKind :: Kind -> Bool isLiftedTypeKind = is_TYPE is_lifted where is_lifted (TyConApp lifted_rep []) = lifted_rep `hasKey` liftedRepDataConKey is_lifted _ = False }}} However, in practice this claim about treating `Constraint` and `Type` as distinct is false: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive -package ghc GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :m + TyCoRep TysWiredIn λ> isLiftedTypeKind liftedTypeKind True λ> isLiftedTypeKind constraintKind True }}} Either we should change the implementation of `isLiftedTypeKind` to match the documentation's claim, or change the documentation. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 14:30:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 14:30:36 -0000 Subject: [GHC] #14862: Switching to Cabal 2.2 makes ghc unusable In-Reply-To: <048.eb29786956ab5b6f0a644e75f882323f@haskell.org> References: <048.eb29786956ab5b6f0a644e75f882323f@haskell.org> Message-ID: <063.76921410c090bef37c1f57e9c0d7e85a@haskell.org> #14862: Switching to Cabal 2.2 makes ghc unusable -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: Component: None | Version: 8.4.1-alpha3 Resolution: | Keywords: Operating System: 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): Let's add the case in comment:4 as a testcase if there isn't already something similar; it seems like a very reasonable sanity-check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 14:52:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 14:52:30 -0000 Subject: [GHC] #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum In-Reply-To: <049.1d7a87ab72f359297da66e7f8ae2c6cd@haskell.org> References: <049.1d7a87ab72f359297da66e7f8ae2c6cd@haskell.org> Message-ID: <064.e2e44caf6a59ea714e0b04b49f494a69@haskell.org> #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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 andrewthad): Your suggested change produces the desired behavior: {{{ findByte :: Int -> Int -> Word8 -> ByteArray -> Maybe Int findByte !off !len0 !w0 !arr0 = boxMaybeInt (go off (len0 + off) w0 arr0) where go :: Int -> Int -> Word8 -> ByteArray -> Maybe# Int# go !ix !end !w !arr = if ix < end then if PM.indexByteArray arr ix == w then (# | unboxInt ix #) else go (ix + 1) end w arr else (# (# #) | #) }}} Results in the following Core: {{{ Rec { -- RHS size: {terms: 34, types: 21, coercions: 0, joins: 0/0} $wgo $wgo = \ ww_s3zd ww1_s3zh ww2_s3zl ww3_s3zp -> case tagToEnum# (<# ww_s3zd ww1_s3zh) of { False -> (#_|#) (##); True -> case indexWord8Array# ww3_s3zp ww_s3zd of wild1_a3vI { __DEFAULT -> case tagToEnum# (eqWord# wild1_a3vI ww2_s3zl) of { False -> $wgo (+# ww_s3zd 1#) ww1_s3zh ww2_s3zl ww3_s3zp; True -> (#|_#) ww_s3zd } } } end Rec } -- RHS size: {terms: 18, types: 11, coercions: 0, joins: 0/0} $wfindByte $wfindByte = \ ww_s3zy ww1_s3zC ww2_s3zG ww3_s3zK -> case $wgo ww_s3zy (+# ww1_s3zC ww_s3zy) ww2_s3zG ww3_s3zK of { (#_|#) ds_d3ui -> Nothing; (#|_#) a_a1Dk -> Just (I# a_a1Dk) } -- RHS size: {terms: 21, types: 12, coercions: 0, joins: 0/0} findByte findByte = \ w_s3zs w1_s3zt w2_s3zu w3_s3zv -> case w_s3zs of { I# ww1_s3zy -> case w1_s3zt of { I# ww3_s3zC -> case w2_s3zu of { W8# ww5_s3zG -> case w3_s3zv of { ByteArray ww7_s3zK -> $wfindByte ww1_s3zy ww3_s3zC ww5_s3zG ww7_s3zK } } } } }}} I don't much mind having to do this by hand. It's just nice to know that there's a reliable way to coax GHC into doing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 14:57:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 14:57:16 -0000 Subject: [GHC] #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum In-Reply-To: <049.1d7a87ab72f359297da66e7f8ae2c6cd@haskell.org> References: <049.1d7a87ab72f359297da66e7f8ae2c6cd@haskell.org> Message-ID: <064.b5db50281ca336298e2a8678a7c6c1be@haskell.org> #14865: GHC Defeats Manual Worker Wrapper with Unboxed Sum -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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 andrewthad): It's weird that trying to manually apply the static argument transformation (which is probably not a performance win here anyway) gets in the way of this. For example, the following code produces the same core I originally was getting: {{{ findByte :: Int -> Int -> Word8 -> ByteArray -> Maybe Int findByte !off !len0 !w0 !arr0 = boxMaybeInt (goA off (len0 + off) w0 arr0) goA :: Int -> Int -> Word8 -> ByteArray -> Maybe# Int# goA !ix0 !end !w !arr = goB ix0 where goB :: Int -> Maybe# Int# goB !ix = if ix < end then if PM.indexByteArray arr ix == w then (# | unboxInt ix #) else goB (ix + 1) else (# (# #) | #) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 15:18:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 15:18:20 -0000 Subject: [GHC] #14867: Documentation targets are not working (was: [build system] Documentation targets are not working) In-Reply-To: <043.0dd6fd21aa956abd3688bcccaf95e777@haskell.org> References: <043.0dd6fd21aa956abd3688bcccaf95e777@haskell.org> Message-ID: <058.1d3a2eeb4b74cc54790463278114f6d4@haskell.org> #14867: Documentation targets are not working -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 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 bgamari): * component: Documentation => Build System * type: task => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 15:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 15:30:56 -0000 Subject: [GHC] #14870: Runtime performance regression in 8.4 Message-ID: <046.f9c1126c397c410d03e30fa51b1fb975@haskell.org> #14870: Runtime performance regression in 8.4 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- varosi [[https://mail.haskell.org/pipermail/glasgow-haskell- users/2018-February/026701.html|reports]] that the code for his project is slower in 8.4.1 than 8.2.2: > Yesterday I successfully compiled it with GHC 8.4.1-rc1. I got compiled it > with 8.2.2 and 8.0.2 as well and ran tests for about a minute each on my > Intel Core i7 machine on Windows 10 x64. > > I got this results: > > GHC 8.4.1-rc1 > Average time: 61.87s > > GHC 8.2.2 > Average time: 60.09s > > GHC 8.0.2 > Average time: 67.07s > We should look into why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 15:31:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 15:31:19 -0000 Subject: [GHC] #14870: Runtime performance regression in 8.4 In-Reply-To: <046.f9c1126c397c410d03e30fa51b1fb975@haskell.org> References: <046.f9c1126c397c410d03e30fa51b1fb975@haskell.org> Message-ID: <061.5936dfe02528a0ec372b7dbe9d319769@haskell.org> #14870: Runtime performance regression in 8.4 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1-alpha3 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): * version: 8.2.2 => 8.4.1-alpha3 * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 15:53:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 15:53:27 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.0e190cc54e046c66af97708276715d56@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I can confirm that this *is* a regression; I'm seeing ~34 seconds overall compilation time on 7.10.3, vs. ~341 seconds on GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 15:57:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 15:57:03 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.8050c2cf975ba6b3d935864bff488164@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "test1000.hs" added. The actual test input used when comparing 7.10.3 against HEAD (8.4.x) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 17:50:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 17:50:22 -0000 Subject: [GHC] #14869: Documentation for isLiftedTypeKind is incorrect In-Reply-To: <050.35651f1fbd8cecc022a69aff4010777f@haskell.org> References: <050.35651f1fbd8cecc022a69aff4010777f@haskell.org> Message-ID: <065.e7bb4f7c0fbadcbf9dd24f61f0812758@haskell.org> #14869: Documentation for isLiftedTypeKind is incorrect -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Amusingly, the `Constraint` counterpart, `isLiftedTypeKind`, actually appears to do [http://git.haskell.org/ghc.git/blob/df2c3b3364834d2fd038192c89348fc50a2e0475:/compiler/types/Kind.hs#l68 the right thing]: {{{#!hs isConstraintKind :: Kind -> Bool isConstraintKindCon :: TyCon -> Bool isConstraintKindCon tc = tyConUnique tc == constraintKindTyConKey isConstraintKind (TyConApp tc _) = isConstraintKindCon tc isConstraintKind _ = False }}} This actually checks the unique of the tycon, and per `Note [Kind Constraint and kind *]`, the uniques for `Type` and `Constraint` [http://git.haskell.org/ghc.git/blob/df2c3b3364834d2fd038192c89348fc50a2e0475:/compiler/types/Kind.hs#l43 are different]. Thus: {{{ $ inplace/bin/ghc-stage2 --interactive -package ghc GHCi, version 8.5.20180221: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :m + Kind TysWiredIn λ> isConstraintKind liftedTypeKind False λ> isConstraintKind constraintKind True }}} Thus, to fix the aforementioned Template Haskell bug, all we'd have to do is make this change: {{{#!diff diff --git a/compiler/typecheck/TcSplice.hs b/compiler/typecheck/TcSplice.hs index 45e18e6..b052e8e 100644 --- a/compiler/typecheck/TcSplice.hs +++ b/compiler/typecheck/TcSplice.hs @@ -1707,8 +1707,8 @@ reifyFamilyInstance is_poly_tvs inst@(FamInst { fi_flavor = flavor ------------------------------ reifyType :: TyCoRep.Type -> TcM TH.Type -- Monadic only because of failure -reifyType ty | isLiftedTypeKind ty = return TH.StarT - | isConstraintKind ty = return TH.ConstraintT +reifyType ty | isConstraintKind ty = return TH.ConstraintT + | isLiftedTypeKind ty = return TH.StarT reifyType ty@(ForAllTy {}) = reify_for_all ty reifyType (LitTy t) = do { r <- reifyTyLit t; return (TH.LitT r) } reifyType (TyVarTy tv) = return (TH.VarT (reifyName tv)) }}} ----- I propose that we: 1. Change the documentation for `isLiftedTypeKind` to reflect the fact that it does not distinguish between `Constraint` and `Type`. 2. Make the above change to `TcSplice` to fix the bug. Does that sound reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 18:02:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 18:02:04 -0000 Subject: [GHC] #14048: Data instances of kind Constraint In-Reply-To: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> References: <051.8c6d06ccd49f550c423f65db1edff09f@haskell.org> Message-ID: <066.4e2aa967b96a4cdc30376ce5d750f54a@haskell.org> #14048: Data instances of kind Constraint -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Not to distract too much from the actual ticket (and perhaps this should be its own ticket), but it is rather disturbing that, as you briefly mentioned, `data Foo1 :: Constraint`/`data family Foo2 :: Constraint` is accepted today. Ultimately, it comes down to the fact that `isLiftedTypeKind` returns `True` for both `Type` //and// `Constraint`—see #14869—so GHC doesn't reject when the return kind is `Constraint`. I suppose that could be fixable by inserting an additional check for `not (isConstraintKind k)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 18:21:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 18:21:27 -0000 Subject: [GHC] #14868: -O -g breaks string literals In-Reply-To: <043.b85ddd9da71a7b040ce01bef4d2ffb0c@haskell.org> References: <043.b85ddd9da71a7b040ce01bef4d2ffb0c@haskell.org> Message-ID: <058.1efe500ffca39b668dfb2f41a7604671@haskell.org> #14868: -O -g breaks string literals -------------------------------------+------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14779, #14123 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #14779, #14123 Comment: Indeed Bartosz is looking at this and related issues in #14779. Also see #14123. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 20:04:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 20:04:26 -0000 Subject: [GHC] #14867: Documentation targets are not working In-Reply-To: <043.0dd6fd21aa956abd3688bcccaf95e777@haskell.org> References: <043.0dd6fd21aa956abd3688bcccaf95e777@haskell.org> Message-ID: <058.bed2a27c25c9ac05bae1258e4529671d@haskell.org> #14867: Documentation targets are not working -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Actually, things are strictly speaking working as they always have: the `html` rule only works when one of `BUILD_SPHINX_HTML` or `BUILD_SPHINX_PDF` is set. Presumably your `BuildFlavour` has disabled these? While we could in principle fix this (just teach `ghc.mk` to unconditionally add the documentation directories to `BUILD_DIRS` and fix whatever breakage this causes), I'm not sure it's worth the effort given that Hadrian will soon be the norm. Perhaps updating the wiki in the meantime would be a reasonable compromise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 28 22:50:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Feb 2018 22:50:40 -0000 Subject: [GHC] #12506: Compile time regression in GHC 8. In-Reply-To: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> References: <044.1c66d98985dc3977bc33250e284e20f8@haskell.org> Message-ID: <059.36f9aa50b183f0c73cd4d8f641a5ea08@haskell.org> #12506: Compile time regression in GHC 8. -------------------------------------+------------------------------------- Reporter: deech | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I can confirm that this *is* a regression; I'm seeing ~34 seconds overall compilation time on 7.10.3, vs. ~341 seconds on GHC HEAD. Aha! Excellent. Does that show on (some version of) the repro case test.hs? -- Ticket URL: GHC The Glasgow Haskell Compiler