From ghc-devs at haskell.org Thu Nov 1 04:58:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 04:58:43 -0000 Subject: [GHC] #15841: User's Guide section for Coercible links to a 404 page Message-ID: <043.ad009ea48127d14d476f5088b41d0b03@haskell.org> #15841: User's Guide section for Coercible links to a 404 page -------------------------------------+------------------------------------- Reporter: koz_ | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 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: -------------------------------------+------------------------------------- Section 10.14.4 of the User's Guide is meant to describe the Coercible constraint, and links to the safe coercions paper to do so (there's basically little else in that section at all). However, that link currently 404s (the link is specifically http://www.cis.upenn.edu/~eir/papers/2014/coercible/coercible.pdf). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 09:22:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 09:22:48 -0000 Subject: [GHC] #15821: Implement more constant folding for Naturals In-Reply-To: <046.f9a66ca4226a20e909943f505947aaf5@haskell.org> References: <046.f9a66ca4226a20e909943f505947aaf5@haskell.org> Message-ID: <061.c62db31fb4c943570c17418c792346bd@haskell.org> #15821: Implement more constant folding for Naturals -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 martijnbastiaan): leonschool(@github) and I have been working on this when we discovered the missing foldings caused issues with the project we're working on. We've got a first implementation up: https://github.com/leonschoorl/ghc/commit/114981b040c8731702466246a0f7f6afb7874ac2 (don't mind the trace calls, WIP!). @hsyl20, maybe we could work together? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 10:32:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 10:32:30 -0000 Subject: [GHC] #15654: Use deriving Functor in the codebase In-Reply-To: <047.b99ed8ac066f244e968fce2614f3392c@haskell.org> References: <047.b99ed8ac066f244e968fce2614f3392c@haskell.org> Message-ID: <062.1762679029359f5f8590c30cc1c2cd95@haskell.org> #15654: Use deriving Functor in the codebase -------------------------------------+------------------------------------- Reporter: monoidal | Owner: RolandSenn Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: I'll work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 12:34:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 12:34:00 -0000 Subject: [GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation In-Reply-To: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> References: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> Message-ID: <062.ad936d8a71804bc4a86a624c6cb9f0ad@haskell.org> #15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13587, #15835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I don't think types are really dealt with properly in typed template haskell. Your program is a lot like {{{ foo :: Int -> Q (TExp Int) foo x = [|| x ||] }}} In this case, we have to interpret the `x` as `$(lift x)` and we should do the same thing for types here. To go back to your program and some pseudo syntax: {{{ foo :: forall a. Q (TExp Int) foo = [|| get @$(lift a) ||] }}} We really mean something like this as the value of `a` is bound at compile-time but not at run-time so if we want to use it we have to use it in a splice. Does that sound sensible Simon? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 13:18:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 13:18:05 -0000 Subject: [GHC] #15841: User's Guide section for Coercible links to a 404 page In-Reply-To: <043.ad009ea48127d14d476f5088b41d0b03@haskell.org> References: <043.ad009ea48127d14d476f5088b41d0b03@haskell.org> Message-ID: <058.629e23ec27a35884df55001cb517abb1@haskell.org> #15841: User's Guide section for Coercible links to a 404 page -------------------------------------+------------------------------------- Reporter: koz_ | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 Resolution: | Keywords: newcomer 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 RyanGlScott): * keywords: => newcomer Comment: Good catch. An up-to-date version of that link can be found at https://cs.brynmawr.edu/~rae/papers/2014/coercible/coercible.pdf . Does anyone want to make a patch to correct this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 14:16:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 14:16:23 -0000 Subject: [GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation In-Reply-To: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> References: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> Message-ID: <062.68cfa55b6a086969b6d04a05a73373a3@haskell.org> #15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13587, #15835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I put a patch up which contains the test for now. https://phabricator.haskell.org/D5291 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 16:22:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 16:22:22 -0000 Subject: [GHC] #10915: Statistical profiling support in the RTS In-Reply-To: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> References: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> Message-ID: <061.7272125ae60e73a9c1f35644cc1218e3@haskell.org> #10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1215, Wiki Page: | Phab:D1214 -------------------------------------+------------------------------------- Changes (by domenkozar): * cc: domenkozar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 17:21:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 17:21:35 -0000 Subject: [GHC] #15842: Exponentiation needs PrelRules Message-ID: <045.f0a505ab673e73f37cabafaa2874c4da@haskell.org> #15842: Exponentiation needs PrelRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When a user writes `a ^ lb`, where `lb` is an integer literal, the type of `lb` defaults to `Integer` unless it's annotated. If `lb` is very small, then `RULES` will expand the whole expression into a few multiplications. If not, the computation will pay the price of `Integer` arithmetic. If we want, we should be able to improve this with a special compilation rule. When `lb :: Integer`, and `0 <= lb <= maxBound :: Word`, we should be able to replace `lb` by the equivalent `Word`. The same problem appears with `^^` and `stimes`. Perhaps those can be fixed up as well, somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 18:39:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 18:39:48 -0000 Subject: [GHC] #15841: User's Guide section for Coercible links to a 404 page In-Reply-To: <043.ad009ea48127d14d476f5088b41d0b03@haskell.org> References: <043.ad009ea48127d14d476f5088b41d0b03@haskell.org> Message-ID: <058.5e809bdfe06a1fcee00f132f08686df3@haskell.org> #15841: User's Guide section for Coercible links to a 404 page -------------------------------------+------------------------------------- Reporter: koz_ | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 Resolution: | Keywords: newcomer 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 koz_): There's also this one, which I believe is more up-to-date: https://www.microsoft.com/en-us/research/uploads/prod/2018/05/coercible- JFP.pdf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 18:58:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 18:58:09 -0000 Subject: [GHC] #15807: GHC panic with visible kind applications In-Reply-To: <051.23fa71fd3c8f35b741fff4c2f0658791@haskell.org> References: <051.23fa71fd3c8f35b741fff4c2f0658791@haskell.org> Message-ID: <066.12a93dc62ac63a4013a5976f9cd19917@haskell.org> #15807: GHC panic with visible kind applications ---------------------------------+---------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeApplications 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 goldfire): The types involved here do not have CUSKs. Since My's last rebase, I've committed a major change to the way non-CUSK types are handled, in a way that will likely affect GHC's behavior here. I'm hoping that when she rebases, this panic will go away. Regardless, more good fodder for the test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 19:41:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 19:41:27 -0000 Subject: [GHC] #15797: GHC panic using visible kind application In-Reply-To: <051.d9fe92394302d401a2d56c3c16cf3fc2@haskell.org> References: <051.d9fe92394302d401a2d56c3c16cf3fc2@haskell.org> Message-ID: <066.8651ac7306be31d03613765c8838809f@haskell.org> #15797: GHC panic using visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is fixed by adding a `checkNoErrs` to the `reportAllUnsolved` line in `failIfEmitsConstraints`. I have a patch being validated now. Regardless, please add a test case when committing the patch for #12045. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 19:58:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 19:58:26 -0000 Subject: [GHC] #15796: Core Lint error with visible kind application In-Reply-To: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> References: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> Message-ID: <066.a4cd1dbed96ddeb088d156a8721ecec6@haskell.org> #15796: Core Lint error with visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: mnguyen (removed) * keywords: TypeApplications => TypeInType * related: #12045 => Comment: Can be triggered without visible kind application: {{{#!hs {-# Language QuantifiedConstraints #-} {-# Language TypeApplications #-} {-# Language TypeOperators #-} {-# Language PolyKinds #-} {-# Language FlexibleInstances #-} {-# Language DataKinds #-} {-# Language TypeFamilies #-} {-# Language MultiParamTypeClasses #-} {-# Language ConstraintKinds #-} {-# Language UndecidableInstances #-} {-# Language GADTs #-} {-# Options_GHC -dcore-lint #-} import Data.Kind type Cat ob = ob -> ob -> Type class Ríki (obj :: Type) where type (-->) :: Cat obj class Varpi (f :: dom -> cod) newtype (··>) :: Cat (a -> b) where Natu :: Varpi f => (forall xx. f xx --> f' xx) -> (f ··> f') instance Ríki cod => ------------- Ríki (dom -> cod) where type (-->) = ((··>) :: Cat (dom -> cod)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 20:37:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 20:37:16 -0000 Subject: [GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level In-Reply-To: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> References: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> Message-ID: <061.3c06877e48b8cde1ae6c5d3399826033@haskell.org> #15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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 baramoglo): Thanks for the clarifications! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 20:44:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 20:44:25 -0000 Subject: [GHC] #15796: Core Lint error with invalid newtype declaration (was: Core Lint error with visible kind application) In-Reply-To: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> References: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> Message-ID: <066.e78b78abb1da0a5dd956e608463904ee@haskell.org> #15796: Core Lint error with invalid newtype declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies 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): * keywords: TypeInType => TypeFamilies * failure: None/Unknown => Compile-time crash or panic * component: Compiler => Compiler (Type checker) * milestone: => 8.8.1 Comment: Even simpler example: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} module Bug where newtype N a where MkN :: Show a => a -> N a type family T a type instance T (N a) = N a }}} {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs -dcore-lint GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-linux): Core Lint error : warning: In the type ‘N a_a1P7’ Found TcTyCon: N[tc] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/FamInst.hs:171:31 in ghc:FamInst }}} The culprit appears to be the invalid `Show a` context in the `MkN` newtype constructor, as removing that makes the Core Lint error go away. Note that this only happens in GHC 8.6.1 and later. In earlier versions of GHC, this simply gives an error message: {{{ $ /opt/ghc/8.4.4/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:6:3: error: • A newtype constructor cannot have a context in its type MkN :: forall a. Show a => a -> N a • In the definition of data constructor ‘MkN’ In the newtype declaration for ‘N’ | 6 | MkN :: Show a => a -> N a | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 21:40:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 21:40:05 -0000 Subject: [GHC] #15843: Tuple sections can't be quoted Message-ID: <049.0eff09d65f5dcf5b91058a38c402215d@haskell.org> #15843: Tuple sections can't be quoted -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are quite a few forms that are not supported in template haskell quotes. It seems that it would be at least a good warm up patch to add support for tuple sections which you can do simply by desugaring to a lambda and the normal tuple constructor. {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TupleSections #-} module Foo where foo = [|| (,5) ||] }}} 1. Modify `DsMeta.repE` to handle tuple sections. You can desugar `(,5) => `\x -> (x, 5)`. 2. Add the above test to the test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 21:42:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 21:42:57 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.65bdf3bfd796b7359d3199d8ba8b11a6@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mnguyen Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14579 Related Tickets: #15782 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"255d2e323a8879a7296a5ab94e6cc49023e2c86e/ghc" 255d2e3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="255d2e323a8879a7296a5ab94e6cc49023e2c86e" Fix embarrassing, egregious bug in roles of (->) Previously, I had inexplicably decided that (->)'s roles were all Representational. But, of course, its first two parameters are *dependent* RuntimeReps. All dependent parameters have a Nominal role, because all roles in kinds are Nominal. Fix is easy, but I have no idea how the world hasn't come crashing down before now. This was found while investigating #15801, which requires visible type application in types to observe. Hence, the test case will come with the main patch for #12045. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 21:42:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 21:42:57 -0000 Subject: [GHC] #15797: GHC panic using visible kind application In-Reply-To: <051.d9fe92394302d401a2d56c3c16cf3fc2@haskell.org> References: <051.d9fe92394302d401a2d56c3c16cf3fc2@haskell.org> Message-ID: <066.b89ea2c32721063e59d1b3e60bffc9fd@haskell.org> #15797: GHC panic using visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"74ed9c1c1b26971133c7166663b9c966d2eaca08/ghc" 74ed9c1c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74ed9c1c1b26971133c7166663b9c966d2eaca08" Actually fail in failIfEmitsConstraints The function TcHsType.failIfEmitsConstraints says that it fails. It even does so in its name. But it didn't! It *reported* constraints but didn't fail. Now it does. This is important in tcHsClsInstType; see the comments therein. This was discovered while looking at #15797, but that ticket requires visible kind application to exhibit the bug; the test case will come with the patch for #12045. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 21:42:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 21:42:57 -0000 Subject: [GHC] #15801: "ASSERT failed!" with visible kind applications In-Reply-To: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> References: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> Message-ID: <066.c877eb3439cbfbf704b13e95823a0e46@haskell.org> #15801: "ASSERT failed!" with visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"255d2e323a8879a7296a5ab94e6cc49023e2c86e/ghc" 255d2e3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="255d2e323a8879a7296a5ab94e6cc49023e2c86e" Fix embarrassing, egregious bug in roles of (->) Previously, I had inexplicably decided that (->)'s roles were all Representational. But, of course, its first two parameters are *dependent* RuntimeReps. All dependent parameters have a Nominal role, because all roles in kinds are Nominal. Fix is easy, but I have no idea how the world hasn't come crashing down before now. This was found while investigating #15801, which requires visible type application in types to observe. Hence, the test case will come with the main patch for #12045. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 21:42:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 21:42:57 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.191942199d20c49c107a7b7a11b3667d@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mnguyen Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14579 Related Tickets: #15782 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"74ed9c1c1b26971133c7166663b9c966d2eaca08/ghc" 74ed9c1c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="74ed9c1c1b26971133c7166663b9c966d2eaca08" Actually fail in failIfEmitsConstraints The function TcHsType.failIfEmitsConstraints says that it fails. It even does so in its name. But it didn't! It *reported* constraints but didn't fail. Now it does. This is important in tcHsClsInstType; see the comments therein. This was discovered while looking at #15797, but that ticket requires visible kind application to exhibit the bug; the test case will come with the patch for #12045. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 21:44:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 21:44:34 -0000 Subject: [GHC] #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) In-Reply-To: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> References: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> Message-ID: <060.6d478d39af0511c2e9377a6bfe32fb62@haskell.org> #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.3 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 21:57:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 21:57:01 -0000 Subject: [GHC] #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) In-Reply-To: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> References: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> Message-ID: <060.349093925e6cc37efcafeca0aa454b77@haskell.org> #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.3 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5292 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5292 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 22:05:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 22:05:47 -0000 Subject: [GHC] #15796: Core Lint error with invalid newtype declaration In-Reply-To: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> References: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> Message-ID: <066.827fff5c87d1dd365ebe39549566e1c7@haskell.org> #15796: Core Lint error with invalid newtype declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies 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): I'm pretty sure I know what's happening: * The newtype declaration is bogus. It kind-checks, but then fails the validity check. * If a declaration fails a validity check, we manufacture a "recovery tycon", which is a `TcTyCon`. See `Note [Recover from validity error]` in TcTyClsDecls. * When we create a type family instance, we (optionally) do a quick core- lint check on it, as there's no other time we ever do so. * Core lint falls over when it sees a `TcTyCon`, which should never make it past the type checker. I don't want to remove this last check. And I don't want to abolish recovery tycons, as they produce nice error messages. Maybe we tell core- lint (in a new parameter) that it's being called in the type checker? Maybe we skip this check if there are errors? Yes, that seems sensible. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 22:11:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 22:11:03 -0000 Subject: [GHC] #15796: Core Lint error with invalid newtype declaration In-Reply-To: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> References: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> Message-ID: <066.04f0cc71c72dc5798ce32672651eb0ae@haskell.org> #15796: Core Lint error with invalid newtype declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies 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 Richard Eisenberg ): In [changeset:"1f72a1c81368e34387aac38c0b1c59521cec58ec/ghc" 1f72a1c8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f72a1c81368e34387aac38c0b1c59521cec58ec" Don't lint erroneous programs. newFamInst lints its types. This is good. But it's not so good when there have been errors and thus recovery tycons are about. So we now don't. Fixes #15796. Test case: typecheck/should_fail/T15796 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 22:12:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 22:12:07 -0000 Subject: [GHC] #15796: Core Lint error with invalid newtype declaration In-Reply-To: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> References: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> Message-ID: <066.83b35140724235ed268a4fccd1667ab6@haskell.org> #15796: Core Lint error with invalid newtype declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T15796 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_fail/T15796 Comment: This is easy to merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 22:15:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 22:15:30 -0000 Subject: [GHC] #15796: Core Lint error with invalid newtype declaration In-Reply-To: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> References: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> Message-ID: <066.b93d95b8ca87605d4869cda54318060b@haskell.org> #15796: Core Lint error with invalid newtype declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T15796 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.8.1 => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 1 22:46:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Nov 2018 22:46:05 -0000 Subject: [GHC] #15842: Exponentiation needs PrelRules In-Reply-To: <045.f0a505ab673e73f37cabafaa2874c4da@haskell.org> References: <045.f0a505ab673e73f37cabafaa2874c4da@haskell.org> Message-ID: <060.b69600565c7f7303ea30ccf68a220610@haskell.org> #15842: Exponentiation needs PrelRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: newcomer 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): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 00:34:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 00:34:15 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack In-Reply-To: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> References: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> Message-ID: <061.f1ad59783cab8d106582f1c46c88640d@haskell.org> #15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.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:D5256 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"614028e3b02a5b71a9fbf9c7028f270760ccdab2/ghc" 614028e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="614028e3b02a5b71a9fbf9c7028f270760ccdab2" Data.Maybe: add callstack for fromJust (Trac #15559) Per feature request, add `HasCallStack` to `fromJust` in `Data.Maybe` and use `error` instead of `errorWithoutStackTrace`. This allows `fromJust` to print call stacks when throwing the error. Also add a new test case for the behaviour, modify existing test cases for new signature Test Plan: New test cases Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: ulysses4ever, rwbarton, carter GHC Trac Issues: #15559 Differential Revision: https://phabricator.haskell.org/D5256 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 00:34:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 00:34:16 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types In-Reply-To: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> References: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> Message-ID: <059.73cbc8763a515fd3cd0e6dc26e89f70e@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9371 | Differential Rev(s): Phab:D5206 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f877d9cc99dd1ba0c038e70527031e9ba0934cd3/ghc" f877d9c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f877d9cc99dd1ba0c038e70527031e9ba0934cd3" Move eta-reduced coaxiom compatibility handling quirks into FamInstEnv. The quirk caused an issue where GHC concluded that 'D' is possibly unifiable with 'D a' (the two types could have the same kind if D is a data family). Test Plan: Ensure T9371 stays fixed. Introduce T15704 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15704 Differential Revision: https://phabricator.haskell.org/D5206 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 02:35:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 02:35:47 -0000 Subject: [GHC] #15832: returnIO/bindIO destroys runtime explicit stack information in some cases In-Reply-To: <048.4f171325e6580b41c039ea3becfab225@haskell.org> References: <048.4f171325e6580b41c039ea3becfab225@haskell.org> Message-ID: <063.35c13472349f5aa14cc46c846501208e@haskell.org> #15832: returnIO/bindIO destroys runtime explicit stack information in some cases -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): If you look at the STG you will see that in the good case we get STG of the form, {{{#!hs main = (>>) (return undefined) (print (X (error ...))) }}} The second argument then becomes a CAF during codegen. This CAF then as a cost-center added to it due to `-fprof-cafs`. The bad case, on the other hand, is of the form: {{{#!hs main = (>>=) (return undefined) (\_ -> print (X (error ...))) }}} Here the second argument is not a CAF and therefore will not get a cost- center. This is the reason for this difference. Out of curiosity, what is your application? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 02:49:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 02:49:57 -0000 Subject: [GHC] #15832: returnIO/bindIO destroys runtime explicit stack information in some cases In-Reply-To: <048.4f171325e6580b41c039ea3becfab225@haskell.org> References: <048.4f171325e6580b41c039ea3becfab225@haskell.org> Message-ID: <063.94fbc19386a7308e310ad2b2ae628156@haskell.org> #15832: returnIO/bindIO destroys runtime explicit stack information in some cases -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 infinity0): OK, but then how do I get a proper "evaluated by" stack trace? From [https://github.com/ghc/ghc/blob/f877d9cc99dd1ba0c038e70527031e9ba0934cd3/rts/Profiling.c#L929 here] it seems that only CAF stacks can be traversed to the "evaluated by" stacks. Stacks that don't come from a CAF, can't be traversed further to see what caused the evaluation of an error/bottom value. In both cases, I am creating an `X` with a bottom inside it. This is a decently common pattern used in Haskell, the intent is that I never evaluate the bottom. However, programmers make mistakes and it's nice to be able to get a stack trace showing me what was trying to evaluate the bottom. In the good case, I can see both (a) the stack that created the bottom value and (b) the stack that caused the evaluation of bottom. In the bad case, I can only see (a) and I can't see (b), making things very hard to debug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 03:18:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 03:18:10 -0000 Subject: [GHC] #15832: returnIO/bindIO destroys runtime explicit stack information in some cases In-Reply-To: <048.4f171325e6580b41c039ea3becfab225@haskell.org> References: <048.4f171325e6580b41c039ea3becfab225@haskell.org> Message-ID: <063.75bd09e39baaab72b50b62f25565b2ad@haskell.org> #15832: returnIO/bindIO destroys runtime explicit stack information in some cases -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 infinity0): Here is an even more realistic example, which hopefully convinces you that this is a Very Important bug (at least with stack-trace printing), and closer to my real-world code: Good code: {{{#!hs data X = X Int | XX deriving (Eq, Show) mkX = X doInnocentThings a = case a of X i -> putStr "" XX -> putStr "XX" doBadThing a = case a of X i -> print i XX -> print "XX" main :: IO () main = do return undefined let a = mkX (error "XXX") doInnocentThings a doBadThing a }}} Good stack trace: {{{ *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Main.main.a, called from Main.main.a, called from Main.CAF:sat_s2O2 --> evaluated by: Main.doBadThing, called from Main.main, called from Main.CAF:sat_s2O2 --> evaluated by: Main.doBadThing, called from Main.main Test-good: XXX CallStack (from HasCallStack): error, called at Test-good.hs:16:16 in main:Main CallStack (from -prof): Main.main.a (Test-good.hs:16:16-26) Main.main.a (Test-good.hs:16:11-27) Main.CAF:sat_s2O2 () }}} Here the stack trace mentions "doBadThing", it is obvious which piece of code is at fault. Now: Bad code: (change `return undefined` to `_ <- return undefined` in the good code) Bad stack trace: {{{ *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Main.main.a, called from Main.main.a Test-bad: XXX CallStack (from HasCallStack): error, called at Test-bad.hs:16:16 in main:Main CallStack (from -prof): Main.main.a (Test-bad.hs:16:16-26) Main.main.a (Test-bad.hs:16:11-27) }}} There is no "evaluated by" entry, the only thing I see is the `let a =` statement being mentioned, which is perfectly fine logic-wise. There is no way to debug this, except by guessing based on knowledge of the whole codebase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 03:33:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 03:33:37 -0000 Subject: [GHC] #15832: returnIO/bindIO destroys runtime explicit stack information in some cases In-Reply-To: <048.4f171325e6580b41c039ea3becfab225@haskell.org> References: <048.4f171325e6580b41c039ea3becfab225@haskell.org> Message-ID: <063.f20d8a4ef2f36bf4d9f1e08c894b87b0@haskell.org> #15832: returnIO/bindIO destroys runtime explicit stack information in some cases -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Thanks for the additional context! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 04:00:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 04:00:34 -0000 Subject: [GHC] #15832: returnIO/bindIO destroys runtime explicit stack information in some cases In-Reply-To: <048.4f171325e6580b41c039ea3becfab225@haskell.org> References: <048.4f171325e6580b41c039ea3becfab225@haskell.org> Message-ID: <063.6ba3aa9ae6efcab02985c16043ee3c88@haskell.org> #15832: returnIO/bindIO destroys runtime explicit stack information in some cases -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: I agree that this is a serious debugging impediment; stack traces are very important for the usability of the language in an applied setting. Bumping the priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 08:40:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 08:40: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.5876ac3380182bc0071a8d41943c6bea@haskell.org> #14761: Incorrect diagnostic for UNPACK/missing strictness -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | typecheck/should_fail/T14761a, | typecheck/should_fail/T14761b Blocked By: | Blocking: Related Tickets: #7210 | Differential Rev(s): Phab:D4397 Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): The original example now compiles in HEAD after the merge of Phab:D5221 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 08:45:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 08:45:33 -0000 Subject: [GHC] #15844: Error fetching msys2 tarballs - crt-git Message-ID: <044.bfc9857a19082596b12202bbb22c13f4@haskell.org> #15844: Error fetching msys2 tarballs - crt-git -------------------------------------+------------------------------------- Reporter: Viwor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (make) | Keywords: | Operating System: Windows Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On Windows 10, I've set up mingw as instructed and then proceeded to run `./configure --enable-tarballs-autodownload` which resulted in the following error: {{{ configure: loading site script /mingw64/etc/config.site checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for GHC version date... inferred 8.7.20181102 checking for GHC Git commit id... inferred f877d9cc99dd1ba0c038e70527031e9ba0934cd3 checking for ghc... /mingw64/bin/ghc checking version of ghc... 8.4.3 GHC path canonicalised to: /mingw64/bin/ghc checking build system type... x86_64-w64-mingw32 checking host system type... x86_64-w64-mingw32 checking target system type... x86_64-w64-mingw32 Host platform inferred as: x86_64-unknown-mingw32 Target platform inferred as: x86_64-unknown-mingw32 GHC build : x86_64-unknown-mingw32 GHC host : x86_64-unknown-mingw32 GHC target : x86_64-unknown-mingw32 LLVM target: x86_64-unknown-windows checking for path to top of build tree... D:/ghc configure: Checking for Windows toolchain tarballs... ######################################################################## 100.0% ######################################################################## 100.0% md5sum: 'standard input': no properly formatted MD5 checksum lines found ERROR: mingw-w64-x86_64-crt-git-5.0.0.4795.e3d96cb1-1-any.pkg.tar.xz appears to be corrupted, please delete it and try again. Error fetching msys2 tarballs; see errors above. }}} After deleting the said file, the same error occurs. The same error happens when I try to build with Hadrian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 09:36:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 09:36:18 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types In-Reply-To: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> References: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> Message-ID: <059.2bc64880fe522ff36f622688617e9a1d@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9371 | Differential Rev(s): Phab:D5206 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I like this fix. But can I ask about this in `Unify.hs`: {{{ - go _ _ = maybeApart -- See Note [Lists of different lengths are MaybeApart] + go _ _ = surelyApart + -- Possibly different saturations of a polykinded tycon (See Trac #15704) }}} I don't see where in this ticket we discuss "possibly different saturations of a polykinded tycon". It'd be more direct simply to give an example. Do you have in mind this? {{{ T :: forall k. Type -> k ty1 = T Type Int :: Type ty2 = T (Type->Type) Int Int :: Type }}} Or did you have other examples in mind? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 11:20:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 11:20:54 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.54f40e7c1eb9802761f021fb97ef083b@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15592{,b} Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Concerning comment:16 we need to be careful We certainly have `C :: forall {k}. k -> Constraint`. So `k` is `Inferred` and `a` is `Required`. Now look at `T`. I think we want {{{ T :: forall k (a::k) (f :: k->Type). f a -> Type }}} That is: `k` must be `Specified` (because the user wrote it); but it must precede the `a` which comes from the class. On the other hand, if `T` didn't mention `k` it'd be `Inferred`. What about this? {{{ class D (a::k) where type S a }}} Here `k` is `Specified` for `D`, but is it `Specified` or `Inferred` for `S`? The notes in `Note [Required, Specified, and Inferred for types]` do not really answer this question. This business of thinking about how the class header affects the Inferred/Specified/Required spec for the associated type is desperately tricky. I still wonder if we should instead look at the type declaration alone. An improvement would be this: * Whether the tyvar is Inferred or Specified is determined by looking at the associated type (alone) * But the order in which the Specified variables appear is affected by the class header. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 14:11:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 14:11:11 -0000 Subject: [GHC] #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.97b3dbcf878a5a3dec0f84efb17dd8a0@haskell.org> #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.7 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK Comment: I have an idea for an fix, if it works out I will put up a patch shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 14:24:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 14:24:43 -0000 Subject: [GHC] #15845: TH eta-reduces away explicit foralls in data family instances Message-ID: <050.2b4d3ff964c54112b15d955f9b5c5215@haskell.org> #15845: TH eta-reduces away explicit foralls in data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.7 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #9692, #14179 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Language.Haskell.TH data family F1 a b data instance F1 [a] b = MkF1 data family F2 a data instance F2 a = MkF2 $(do i1 <- reify ''F1 i2 <- reify ''F2 runIO $ mapM_ (putStrLn . pprint) [i1, i2] pure []) }}} {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20181101: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) data family Bug.F1 (a_0 :: *) (b_1 :: *) :: * data instance forall (a_2 :: *). Bug.F1 ([a_2]) b_3 = Bug.MkF1 data family Bug.F2 (a_0 :: *) :: * data instance Bug.F2 a_1 = Bug.MkF2 }}} The output here is quite baffling: * In the `F1` instance, we have an explicit `forall` which quantifies `a_2` but not `b_3`! * In the `F2` instance, there isn't an explicit `forall` at all despite the fact that there ought to be one, since there is a type variable `a_1` in this instance. The culprit in both of the bullet points above is the fact that GHC eta- reduces its internal representation of data family instance axioms. This is the same thing which caused #9692 and #14179, in fact. Luckily, the same fix for those tickets will also work here. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 14:41:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 14:41:05 -0000 Subject: [GHC] #15845: TH eta-reduces away explicit foralls in data family instances In-Reply-To: <050.2b4d3ff964c54112b15d955f9b5c5215@haskell.org> References: <050.2b4d3ff964c54112b15d955f9b5c5215@haskell.org> Message-ID: <065.bb086ba61db507f774a3d2d8feb77b53@haskell.org> #15845: TH eta-reduces away explicit foralls in data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9692, #14179 | Differential Rev(s): Phab:D5294 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5294 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 14:59:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 14:59:15 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.82a1c536bba9f1d5f62852800eff24cf@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Template Haskell | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T15815 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5274 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with 2567e8f341ef638b8a93054d1be75c176bfaee66. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 15:57:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 15:57:04 -0000 Subject: [GHC] #15846: Re-examine mkResidualConstraints Message-ID: <047.e9dede8c7bf14016468890fbab6fe64d@haskell.org> #15846: Re-examine mkResidualConstraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simon and I spent some time debating `TcSimplify.mkResidualConstraints`. Here is what we learned: * The current code handles covars at the top level only. At one point, we were worried about covars in nested implications. But I conjecture this can't happen, because these would necessarily be instances of skolem- escape, prevented elsewhere. (Why skolem-escape? Because the covar would mention local skolems, and yet appears in the type of the variable(s) we're trying to infer.) * We think that any covars that come through `mkResidualConstraints` will ''never'' be solved. That's because there can't be given equality from an outer context -- if there were, we'd be in the "let should not be generalized" case and wouldn't be in `simplifyInfer`. * The `promoteTyVarSet` call in `mkResidualConstraints` appears to be entirely redundant, because anything that gets caught there should also have been caught in `decideMonoTyVars`. * So the only time that we should do work in `mkResidualConstraints` is when we have deferred type errors. Perhaps with that insight, it can be simplified. This ticket is to track our understanding of this function, settle on a way to improve it, and then execute that change. At the minimum, we should figure out whether that `promoteTyVarSet` is necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 16:10:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 16:10:19 -0000 Subject: [GHC] #15843: Tuple sections can't be quoted In-Reply-To: <049.0eff09d65f5dcf5b91058a38c402215d@haskell.org> References: <049.0eff09d65f5dcf5b91058a38c402215d@haskell.org> Message-ID: <064.5a5458001b4e9fda3a3fdfa4eb78effb@haskell.org> #15843: Tuple sections can't be quoted -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: newcomer, | TemplateHaskell 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 => newcomer, TemplateHaskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 16:24:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 16:24:40 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.b2742b8226a15bf20302c71e1d840bad@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, I see the use-case here and it sounds reasonable. However, I agree that we need to make sure that recompilation checking works in a safe and predictable manner. Let's first try to specify what semantics we are looking for. Here is my guess: a. within a GHC session with a `LoadedPlugin` the plugin-module hash check should never trigger a recompilation but the plugin's `PluginRecompile` strategy should, of course, be able to trigger a rebuild b. build artifacts produced by a GHC session with a `LoadedPlugin` should never be used by another session Does this sound right, DanielG? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 16:48:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 16:48:40 -0000 Subject: [GHC] #15841: User's Guide section for Coercible links to a 404 page In-Reply-To: <043.ad009ea48127d14d476f5088b41d0b03@haskell.org> References: <043.ad009ea48127d14d476f5088b41d0b03@haskell.org> Message-ID: <058.647325115bb2de8504c175209a6015ed@haskell.org> #15841: User's Guide section for Coercible links to a 404 page -------------------------------------+------------------------------------- Reporter: koz_ | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 Resolution: | Keywords: newcomer 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 Ben Gamari ): In [changeset:"efb314582f1a1974d68505bbf9312f130416ef65/ghc" efb3145/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="efb314582f1a1974d68505bbf9312f130416ef65" users-guide: Update link to Safe Coercions paper Fixes #15841. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 17:09:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 17:09:25 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.a2840cda53868fad734c314e7118b2d3@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15592{,b} Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard and I talked more about this. We worreid abou {{{ class C a b whre type T (x :: b a) }}} In what order do T's Specified variables show up? We got as far as a detailed proposal for associated types: * Which vars are Specified and which Inferred is determined by type decl alone (Specified = explicitly mentioned in the type decl) • For the Specified variables: * Start with lexical order from type decl * Do a stable partition, moving the ones from the class decl to the front * Use ScopedSort to put them in dependency order. But it all seemed terribly complicated. We ended up thinking that it'd be better to ''ingnore'' the class header, and just do the normal thing: * Start with the lexical order from the type decl * Use ScopedSort This simplifies the spec, and simplifies the code. It is a bit unlike what happens for class methods (where the class variables all show up at the front, but we have no idea how to do make associated types really behave like class methods. Eg {{{ class C a where type F a }}} Then perhaps `F :: forall a -> C a => Type`, which is not ery nice. And it gets worse {{{ class C a b where type F a }}} then perhaps `F :: forall {b}. forall a -> C a b => Type`. Ugh. But if `b` depends on `a` we'd have to put it later in the telescope. So we decided to keep it simple! (This is a small change from the commit in comment:15). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 17:09:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 17:09:53 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.0a0e8eebf4336f05cae3669f9059d15a@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.5 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.4.5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 17:10:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 17:10:00 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.1bbf9de51367ae5d355fc319728c6a9b@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.4.5 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 17:15:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 17:15:36 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.5cbf2ff3d271adf59448d4ae861be711@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by DanielG): I assume you mean `s/LoadedPlugin/StaticPlugin/` above? My patch doesn't change anything about how `LoadedPlugin`s are handled. Indeed since `StaticPlugin` doesn't have an associated `ModIface` only the `PluginRecompile` field can influence recompilation and that's intended. As for build products: right now I only intend to use plugins that extract information while GHC is compiling and not change anything. If someone decides to use a plugin that changes the build output I don't see how the situation is any different for `StaticPlugin` compared to `LoadedPlugin`. If the plugin changes the build output it must sutably declare `pluginRecompile`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 17:17:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 17:17:16 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.001ae0f54df17874bf892154d5ea780f@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Alright, is that to say we want this in 8.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 17:20:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 17:20:01 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.987a417baa37c438aeb140d8196b4c1f@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, interesting. I would first start by running GHC with `-v3` to make sure that the cost is still showing up in the same place. I would then try to build a profiled compiler and see more precisely where things are blowing up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 17:23:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 17:23:55 -0000 Subject: [GHC] #15803: Put more info with flag description In-Reply-To: <046.c46c3af0177d000e9d7ddd302de72349@haskell.org> References: <046.c46c3af0177d000e9d7ddd302de72349@haskell.org> Message-ID: <061.942e7e816903c21cefb5544b08062bde@haskell.org> #15803: Put more info with flag description -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Documentation Comment: Hmm, yes, this is unfortunate. I really wish all of this was less manual. Ideally the flag implication relations would be extract from the source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 17:28:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 17:28:52 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.ba6c09d1495d8d7e507257fd2608084b@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think yes, put it in 8.8. Why would 8.10 be any better? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 17:34:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 17:34:32 -0000 Subject: [GHC] #15715: problematic openFile with named pipes In-Reply-To: <042.429251213bdecb6b7a1355c60029957a@haskell.org> References: <042.429251213bdecb6b7a1355c60029957a@haskell.org> Message-ID: <057.ab37a7b31e49dfd0f04db85047d2d49e@haskell.org> #15715: problematic openFile with named pipes -------------------------------------+------------------------------------- Reporter: adp | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect API | (amd64) annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5295 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5295 Comment: Yes, this is a fair point. Thanks for raising it. I've opened Phab:D5295 adding a mention to the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 17:35:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 17:35:47 -0000 Subject: [GHC] #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm In-Reply-To: <046.0992e281b492040f72d63791112b8b7a@haskell.org> References: <046.0992e281b492040f72d63791112b8b7a@haskell.org> Message-ID: <061.50204942d70c88b670e789be6d92667f@haskell.org> #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm -------------------------------------+------------------------------------- Reporter: gwright | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: FreeBSD | 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 bgamari): * priority: normal => high * milestone: => 8.8.1 Comment: We should make sure this happens for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 18:04:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 18:04:26 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.3e61a53458cc22314dd77e2b6f8cf142@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: patch Priority: normal | Milestone: Component: GHC API | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5278 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: D5278 => Phab:D5278 Comment: Sigh, yes. `s/LoadedPlugin/StaticPlugin/` indeed. > If someone decides to use a plugin that changes the build output I don't see how the situation is any different for `StaticPlugin` compared to `LoadedPlugin`. If the plugin changes the build output it must suitably declare `pluginRecompile`. The difference I was thinking of is that a compiler session using a `LoadedPlugin` will recompile if a different version of the plugin in used (see #15492). This is accounted for in `DsUsage.mkPluginUsage`. Looking more closely at this, I actually suspect this logic will ensure that the right thing happens. However, we would need a test to know for certain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 18:06:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 18:06:55 -0000 Subject: [GHC] #15847: GHCi cannot load .o built from c with -fPIC on i386 linux Message-ID: <046.0d428416ca6e4d905bff26c968f36b08@haskell.org> #15847: GHCi cannot load .o built from c with -fPIC on i386 linux -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.7 System (Linker) | Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi cannot load .o built from c with -fPIC on i386 linux. On i386 linux, the PIC object code looks like: {{{ 000001ac : 1ac: 53 push %ebx 1ad: 83 ec 08 sub $0x8,%esp 1b0: e8 fc ff ff ff call 1b1 1b1: R_386_PC32 __x86.get_pc_thunk.bx 1b5: 81 c3 02 00 00 00 add $0x2,%ebx 1b7: R_386_GOTPC _GLOBAL_OFFSET_TABLE_ 1bb: ff 74 24 1c pushl 0x1c(%esp) 1bf: ff 74 24 1c pushl 0x1c(%esp) 1c3: ff 74 24 1c pushl 0x1c(%esp) 1c7: ff 74 24 1c pushl 0x1c(%esp) 1cb: e8 fc ff ff ff call 1cc 1cc: R_386_PLT32 __umoddi3 1d0: 83 c4 18 add $0x18,%esp 1d3: 5b pop %ebx 1d4: c3 ret }}} 1. the GOT symbol `_GLOBAL_OFFSET_TABLE_` may be undefined 2. the runtime linker doesn't support PIC-related i386 relocations like `R_386_GOTPC` or `R_386_PLT32` As a result, we will see errors like `unknown symbol '_GLOBAL_OFFSET_TABLE_'` or `unhandled ELF relocation`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 18:08:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 18:08:58 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.0b22922c13364b630dd087cd3fac2c33@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: patch Priority: normal | Milestone: Component: GHC API | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by DanielG): Yeah I just had another look and I think I forgot to hook up some of the recompilation logic, I'll fix it and add some tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 18:19:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 18:19:35 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.22e2026146433ed82c318c4f16980e2e@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: low => high Comment: Oh, I don't think 8.10 would be any better. I was just clarifying. We will need to take a bit of time to bring the core libraries up to date but otherwise I see no reason why this wouldn't be feasible. Bumping priority to ensure that this happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 18:19:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 18:19:52 -0000 Subject: [GHC] #15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux Message-ID: <046.4dfec0933239d964a3c131b34980ed97@haskell.org> #15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux ----------------------------------------+--------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.7 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #15847 Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- ghc assumes that on linux, C compiler (e.g. gcc) will build non-PIC object code when no `-fPIC` is passed. But this is no longer true for recent gcc version on some distributions. e.g. {{{ $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ gcc --version gcc (GCC) 7.3.1 20180312 $ touch dummy.c $ gcc -Q -v dummy.c 2>&1 | grep PIC options enabled: -fPIC -fPIE -faggressive-loop-optimizations }}} We need pass `-fno-PIC` explicitly just like `-no-pie`. In particular, this results in 300+ ext-interp related tests to fail on i386 when built with a gcc that has `-fPIC` on by default, as we don't support loading non-PIC .o built from .c on i386. (See #15847, fix this bug will mitigate #15847) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 18:20:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 18:20:53 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.7d51f6ee94d860055e2ab161be518c83@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => davide Comment: David, do you think you could push the necessary changes to the core libraries and merge `wip/T13064`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 18:35:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 18:35:05 -0000 Subject: [GHC] #15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux In-Reply-To: <046.4dfec0933239d964a3c131b34980ed97@haskell.org> References: <046.4dfec0933239d964a3c131b34980ed97@haskell.org> Message-ID: <061.7b1799c18dee7087540115a6d7953eb4@haskell.org> #15848: ghc builds cbits with -fPIC even when -fPIC is not passed to ghc on linux -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 8.7 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15847, #12759 | Differential Rev(s): Phab:D5288 Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * owner: (none) => watashi * differential: => Phab:D5288 * related: #15847 => #15847, #12759 Old description: > ghc assumes that on linux, C compiler (e.g. gcc) will build non-PIC > object code when no `-fPIC` is passed. But this is no longer true for > recent gcc version on some distributions. e.g. > > {{{ > $ uname -a > Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 > 20:45:30 CEST 2018 i686 GNU/Linux > $ gcc --version > gcc (GCC) 7.3.1 20180312 > $ touch dummy.c > $ gcc -Q -v dummy.c 2>&1 | grep PIC > options enabled: -fPIC -fPIE -faggressive-loop-optimizations > }}} > > We need pass `-fno-PIC` explicitly just like `-no-pie`. > > In particular, this results in 300+ ext-interp related tests to fail on > i386 when built with a gcc that has `-fPIC` on by default, as we don't > support loading non-PIC .o built from .c on i386. (See #15847, fix this > bug will mitigate #15847) New description: ghc assumes that on linux, C compiler (e.g. gcc) will build non-PIC object code when no `-fPIC` is passed. But this is no longer true for recent gcc version on some distributions. e.g. {{{ $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ gcc --version gcc (GCC) 7.3.1 20180312 $ touch dummy.c $ gcc -Q -v dummy.c 2>&1 | grep PIC options enabled: -fPIC -fPIE -faggressive-loop-optimizations }}} We need pass `-fno-PIC` explicitly just like we have done for `-no-pie` (See #12759) In particular, this results in 300+ ext-interp related tests to fail on i386 when built with a gcc that has `-fPIC` on by default, as we don't support loading non-PIC .o built from .c on i386. (See #15847, fix this bug will mitigate #15847) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 18:38:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 18:38:07 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.f0dc54874ea4771c61eb7c8a5516298d@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15592{,b} Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Just to chime in agreement with comment:21. I'm sympathetic to the desire to put class variables first, but it gets ugly quickly. Here's another example: {{{#!hs class C a where type F (x :: (f :: k -> Type) a) }}} Here, `k` is actually a ''class'' variable, even though that's highly non- obvious. So `k` should go in the first clump of variables. But it would be easy to assume that `k`, not mentioned in the class header, goes with the second clump of variables. In the end, I agreed that there are just too many wrinkles in the "class variables come first" design, and went with "infer variable order / visibility locally" instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 19:45:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 19:45:37 -0000 Subject: [GHC] #15849: Error message: "Perhaps you need a let in a do block", when there is no do block. Message-ID: <046.1a23c56db483a32d0322994bc5b0ff58@haskell.org> #15849: Error message: "Perhaps you need a let in a do block", when there is no do block. -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code: {{{#!haskell main = return () foo = return () }}} Gives the error message: {{{ parse error on input ‘=’ Perhaps you need a 'let' in a 'do' block? e.g. 'let x = 5' instead of 'x = 5' }}} But this isn't in a do block. It would be awesome if GHC checked whether there's a do block before giving a suggestion that depends on there being a do block. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 19:49:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 19:49:00 -0000 Subject: [GHC] #15850: coercion errors don't always mention that data constructors are not in scope Message-ID: <046.e7ffe47ecab8a7ffed4c8deafd63e737@haskell.org> #15850: coercion errors don't always mention that data constructors are not in scope -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose a library defines a `newtype` with a `nominal` type parameter: {{{#!hs {-# LANGUAGE RoleAnnotations #-} module Lib where type role LibIdentity nominal newtype LibIdentity a = LibIdentity a }}} (in my code, that `newtype` is `ExceptT`, whose last argument is inferred to be `nominal`) In a different module, I also define a `newtype`, and then I try to use `coerce` to remove some of the `newtype` wrappers. Unfortunately I forgot to import `LibIdentity`'s data constructor, and so the coercions fail. Sometimes, the error message helpfully explains that I need that import... but sometimes it doesn't! {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} module Local where import Data.Coerce (coerce) import Lib (LibIdentity) newtype LocalIdentity a = LocalIdentity a -- error: -- • Couldn't match representation of type ‘()’ -- with that of ‘LibIdentity ()’ -- arising from a use of ‘coerce’ -- The data constructor ‘Lib.LibIdentity’ -- of newtype ‘LibIdentity’ is not in scope helpfulError :: LocalIdentity (LibIdentity ()) -> LocalIdentity () helpfulError = coerce -- error: -- • Couldn't match type ‘LocalIdentity ()’ with ‘()’ -- arising from a use of ‘coerce’ difficultError :: LibIdentity (LocalIdentity ()) -> LibIdentity () difficultError = coerce }}} Expected: both uses of `coerce` remind me to import the data constructor of `LibIdentity`. Observed: only `helpfulError` reminds me, while `difficultError` doesn't. (in my code, the `coerce` is generated by `GeneralizedNewtypeDeriving` and the error message does not include the type whose data constructor needs to be imported, making it quite difficult to guess how to fix the error) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 19:51:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 19:51:43 -0000 Subject: [GHC] #15849: Error message: "Perhaps you need a let in a do block", when there is no do block. In-Reply-To: <046.1a23c56db483a32d0322994bc5b0ff58@haskell.org> References: <046.1a23c56db483a32d0322994bc5b0ff58@haskell.org> Message-ID: <061.082db560b73aee5ccc3e5247677103c2@haskell.org> #15849: Error message: "Perhaps you need a let in a do block", when there is no do block. -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 19:55:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 19:55:36 -0000 Subject: [GHC] #15851: Error message: "accepting non-standard pattern guards" when there are no actual patterns Message-ID: <046.7b78294270bf143bdef7262b7c188794@haskell.org> #15851: Error message: "accepting non-standard pattern guards" when there are no actual patterns -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code: {{{#!hs {-# LANGUAGE NoPatternGuards #-} main :: IO () main = print (foo 5) foo :: Int -> Int foo x | x < 5, x > 1 = x | otherwise = -1 }}} Produces this message: {{{ test.hs:7:7: warning: accepting non-standard pattern guards (use PatternGuards to suppress this message) x < 5, x > 1 }}} This is not really a "pattern guard". It's just a guard with multiple clauses, which is a syntax extension that's enabled by `-XPatternGuards`, but there are no patterns. (Incidentally, I wish I could disable pattern guards to avoid the `f x |x<-4` problem where a student tries to compare to negative 4 and gets an accidental pattern guard, yet still keep the multiple-clause syntax; but that's a whole different can of worms.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 20:03:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 20:03:36 -0000 Subject: [GHC] #15852: Bad axiom produced for polykinded data family Message-ID: <047.481c46c837c01249db862f276fa4c502@haskell.org> #15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: TypeFamilies, | 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: -------------------------------------+------------------------------------- When I say {{{#!hs data family DF a (b :: k) data instance DF (Proxy c) :: Proxy j -> Type }}} with `-ddump-tc`, I get {{{ axiom Scratch.D:R:DFProxyProxy0 :: forall k1 k2 (c :: k1) (j :: k2) (a :: Proxy j). DF (Proxy c) a = Scratch.R:DFProxyProxy k1 k2 c j }}} This is bogus, because `a` should be on the RHS, too. It's not clear to me whether this is a pretty-printing bug or a real one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 21:11:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 21:11:32 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.bdc7a60f6dad999ef86a29e4ba7a146e@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: kavon => (none) * status: closed => new * resolution: fixed => * milestone: 8.6.2 => 8.6.3 Comment: Sadly I had to back out both comment:25 and comment:18 on `ghc-8.6` due to breakage. This will likely need to wait for 8.6.3 at the earliest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 21:13:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 21:13:52 -0000 Subject: [GHC] #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) In-Reply-To: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> References: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> Message-ID: <060.eed4cfdf7feeddfb0dcab60d9627040b@haskell.org> #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.3 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5292 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6bb8aaa3b4fcebf8f0de2f81f00dcc20b857c4f5/ghc" 6bb8aaa3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6bb8aaa3b4fcebf8f0de2f81f00dcc20b857c4f5" rts: Add FALLTHROUGH macro Instead of using the GCC `/* fallthrough */` syntax we now use the `__attribute__((fallthrough))`, which Phyx says should be more portable than the former. Also adds a missing fallthrough annotation in the MachO linker, fixing #14613. Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #14613 Differential Revision: https://phabricator.haskell.org/D5292 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 21:18:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 21:18:06 -0000 Subject: [GHC] #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) In-Reply-To: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> References: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> Message-ID: <060.f8c2f304d79291f076ef9aac41a9067a@haskell.org> #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.3 (Linking) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5292 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.6.2 => 8.6.3 Comment: This just missed the cut-off for 8.6.2,. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 21:18:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 21:18:28 -0000 Subject: [GHC] #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) In-Reply-To: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> References: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> Message-ID: <060.ad85ad4e229e28ec27af283b2294679e@haskell.org> #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.3 (Linking) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5292 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 2 22:34:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Nov 2018 22:34:09 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.0227cbd7be6e6102eeb74349e8ad8c7f@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by davide): Absolutely. I'll post an update on Monday, but it seems fairly straightforward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 01:03:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 01:03:37 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types In-Reply-To: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> References: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> Message-ID: <059.910f9c94f0dce02ca1135db9a51bc501@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9371 | Differential Rev(s): Phab:D5206 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Replying to [comment:8 simonpj]: > I like this fix. But can I ask about this in `Unify.hs`: > {{{ > - go _ _ = maybeApart -- See Note [Lists of different lengths are MaybeApart] > + go _ _ = surelyApart > + -- Possibly different saturations of a polykinded tycon (See Trac #15704) > }}} > I don't see where in this ticket we discuss "possibly different saturations of a polykinded tycon". > > It'd be more direct simply to give an example. Do you have in mind this? > {{{ > T :: forall k. Type -> k > > ty1 = T Type Int :: Type > ty2 = T (Type->Type) Int Int :: Type > }}} > Or did you have other examples in mind? > > Thanks The `D` in the ticket is a polykinded tycon: {{{#!hs ty1 = D @(Type -> Type) Int :: Type ty2 = D @(Type -> Type -> Type) Int Bool :: Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 01:59:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 01:59:15 -0000 Subject: [GHC] #15852: Bad axiom produced for polykinded data family In-Reply-To: <047.481c46c837c01249db862f276fa4c502@haskell.org> References: <047.481c46c837c01249db862f276fa4c502@haskell.org> Message-ID: <062.8b9b6b120ec4433d78441dd5bc4d6b20@haskell.org> #15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies, | 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): My guess is that it is a pretty-printing bug, as if it were anything more serious would have been discovered by now. I would start by looking at `Coercion.pprCoAxiom`. Actually, better than just fixing this bug would be removing `Coercion.pprCoAxiom` in favor of the `IfaceAxiom` case of `pprIfaceDecl`. Unless it's not a pretty-printing bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 02:19:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 02:19:55 -0000 Subject: [GHC] #13904: LLVM does not need to trash caller-saved registers. In-Reply-To: <044.9fbf455960cc2fbed77cfe6c815566aa@haskell.org> References: <044.9fbf455960cc2fbed77cfe6c815566aa@haskell.org> Message-ID: <059.6489f1cd54dd17a385f8c247929cafbf@haskell.org> #13904: LLVM does not need to trash caller-saved registers. -------------------------------------+------------------------------------- Reporter: kavon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4992, #4308 | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: kavon => (none) * status: closed => new * resolution: fixed => * milestone: 8.6.2 => 8.8.1 Comment: This was reverted in `ghc-8.6` due to regressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 02:27:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 02:27:00 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.e63563e59cc81c5ab832fc5e6e79e891@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It's just a little twiddling! How hard could it be? :) You ask good questions. But your first guesses are off: - `tcInferInst` is the right notional idea, but not a function you would actually use here. - `getInitialKind` looks at the "left-hand side" of a type declaration and invents a skeleton for the type's kind. (Example: from `data T a (b :: Type -> Type) c`, it guesses `T :: kappa1 -> (Type -> Type) -> kappa2 -> Type` for fresh unification variables `kappa1` and `kappa2`.) Because you don't need to guess the kind, it's not what you want here. What you need to do is to bring the type variables on the LHS into scope (with either guessed or provided kinds), kind-check the RHS, and then say that the LHS's kind is the same as the RHS's. Here is some direction to how to do so: - Have a special case in `kcTyClGroup` that detects a single type synonym. Type synonyms cannot be recursive, so we don't have to worry about that. (Or maybe we do, because we detect recursion in type synonyms later, perhaps? If that's the case, the renamer may want to either reject recursive type synonyms or remember the recursiveness using a new field in the AST.) - `kcLHsQTyVars` brings the LHS tyvars into scope, with appropriate kinds. Claim that the type does ''not'' have a CUSK. (Even if it ''does'' have a CUSK, CUSKness can matter only with recursion.) - `tcLHsType` does a nice job of checking the type itself -- but you'll need only the kind here, not the type. - You'll need to skolemise and quantify, much like the main branch of `kcTyClGroup`. Does that give enough guidance? I do think that, actually, we can do better here. The plan above would still have GHC take two passes over these special type synonyms, when really we can do it in one pass. But the infrastructure isn't set up for that, so it would take a more significant refactoring. Still I think the plan above is an improvement over the status quo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 02:45:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 02:45:16 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.c00a2a7fdb42cc2c8e6f53f6679c1b47@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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): Phab:D5283 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I've answered comment:5 on Phab:D5283 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 09:06:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 09:06:01 -0000 Subject: [GHC] #15853: Unregisterised GHC panics when building test cgrun018 Message-ID: <047.a568cb0e736c463bce20c7d17a5e90c5@haskell.org> #15853: Unregisterised GHC panics when building test cgrun018 -------------------------------------+------------------------------------- Reporter: iliastsi | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.3 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: cgrun018 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- An unregisterised ghc-8.4 on amd64 panics when building test cgrun018. {{{ Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( cgrun018.hs, cgrun018.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-unknown-linux): pprStatics: float F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/cmm/PprC.hs:525:5 in ghc:PprC }}} We have seen this error while building packages for Debian on 64-bit architectures where GHC is unregisterised (e.g., mips64el, s390x): [https://buildd.debian.org/status/fetch.php?pkg=haskell- gloss&arch=mips64el&ver=1.13.0.1-1&stamp=1540810998&raw=0 gloss on mips64el], [https://buildd.debian.org/status/fetch.php?pkg=haskell- juicypixels&arch=s390x&ver=3.2.9.5-3&stamp=1540808360&raw=0 juicypixels on s390x] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 11:04:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 11:04:29 -0000 Subject: [GHC] #11477: Remove -Wamp In-Reply-To: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> References: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> Message-ID: <061.b0f653005b63da5623b1c217e56d4936@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.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: D4785 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: closed => new * owner: RolandSenn => (none) * resolution: fixed => Comment: Reopen to add little comment to release notes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 11:04:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 11:04:42 -0000 Subject: [GHC] #11477: Remove -Wamp In-Reply-To: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> References: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> Message-ID: <061.a99d0d9dd2d8b490ba7980198a535508@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.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: D4785 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 12:21:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 12:21:03 -0000 Subject: [GHC] #15854: PPC: Panic in native code generator Message-ID: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> #15854: PPC: Panic in native code generator ---------------------------------+---------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+---------------------------------------- Head fails on powerpc64le: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181103 for powerpc64le-unknown-linux): PPC.CodeGen.getRegister: no match 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/PrimopWrappers.o' failed }}} I think I know what is going on and will work on a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 12:29:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 12:29:58 -0000 Subject: [GHC] #15854: PPC: Panic in native code generator In-Reply-To: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> References: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> Message-ID: <062.ecb0a2d23c211d590d36e91a2417d315@haskell.org> #15854: PPC: Panic in native code generator ----------------------------------------+--------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+--------------------------------- Changes (by trommler): * owner: (none) => trommler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 13:14:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 13:14:21 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.779919bfb3798732e65be48cbb9d52ef@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): {{{ ==== STAGE 1 TESTS ==== SUMMARY for test run started at Sat Nov 3 12:57:26 2018 GMT 0:00:05 spent to go through 2 total tests, which gave rise to 10 test cases, of which 0 were skipped 0 had missing libraries 10 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures ==== STAGE 2 TESTS ==== Unexpected results from: TEST="ArithInt8 ArithWord8 CmpInt8 CmpWord8 PrimFFIInt8 PrimFFIWord8 ShowPrim T14761c T14936 T2783 T3816 T4334 T7919 haddock.Cabal haddock.base haddock.compiler hpc_fork recomp007 space_leak_001 user001" SUMMARY for test run started at Sat Nov 3 11:53:52 2018 GMT 1:03:32 spent to go through 6660 total tests, which gave rise to 29965 test cases, of which 5949 were skipped 259 had missing libraries 23453 expected passes 257 expected failures 0 caused framework failures 0 caused framework warnings 1 unexpected passes 33 unexpected failures 13 unexpected stat failures Unexpected passes: /tmp/ghctest-sla3_okl/test spaces/rts/T2783.run T2783 [unexpected] (threaded1) Unexpected failures: /tmp/ghctest-sla3_okl/test spaces/driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) /tmp/ghctest-sla3_okl/test spaces/ffi/should_run/PrimFFIInt8.run PrimFFIInt8 [exit code non-0] (optllvm) /tmp/ghctest-sla3_okl/test spaces/ffi/should_run/PrimFFIWord8.run PrimFFIWord8 [exit code non-0] (optllvm) /tmp/ghctest-sla3_okl/test spaces/primops/should_run/ShowPrim.run ShowPrim [exit code non-0] (optllvm) /tmp/ghctest-sla3_okl/test spaces/primops/should_run/CmpInt8.run CmpInt8 [exit code non-0] (optllvm) /tmp/ghctest-sla3_okl/test spaces/primops/should_run/CmpWord8.run CmpWord8 [exit code non-0] (optllvm) /tmp/ghctest-sla3_okl/test spaces/primops/should_run/ArithInt8.run ArithInt8 [exit code non-0] (optllvm) /tmp/ghctest-sla3_okl/test spaces/primops/should_run/ArithWord8.run ArithWord8 [exit code non-0] (optllvm) /tmp/ghctest-sla3_okl/test spaces/rts/T7919.run T7919 [bad exit code] (ghci) /tmp/ghctest-sla3_okl/test spaces/typecheck/should_compile/T14761c.run T14761c [exit code non-0] (hpc) /tmp/ghctest-sla3_okl/test spaces/typecheck/should_compile/T14761c.run T14761c [exit code non-0] (optasm) /tmp/ghctest-sla3_okl/test spaces/typecheck/should_compile/T14761c.run T14761c [exit code non-0] (profasm) /tmp/ghctest-sla3_okl/test spaces/typecheck/should_compile/T14761c.run T14761c [exit code non-0] (optllvm) /tmp/ghctest-sla3_okl/test spaces/libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (normal) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (hpc) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (optasm) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (profasm) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (threaded1) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (threaded2) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (dyn) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (profthreaded) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (optllvm) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (normal) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (hpc) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (optasm) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (profasm) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (ghci) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (threaded1) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (threaded2) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (dyn) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (profthreaded) /tmp/ghctest-sla3_okl/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (optllvm) Unexpected stat failures: /tmp/ghctest-sla3_okl/test spaces/perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) /tmp/ghctest-sla3_okl/test spaces/perf/haddock/haddock.base.run haddock.base [stat not good enough] (normal) /tmp/ghctest-sla3_okl/test spaces/perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) /tmp/ghctest-sla3_okl/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (hpc) /tmp/ghctest-sla3_okl/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profasm) /tmp/ghctest-sla3_okl/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (hpc) /tmp/ghctest-sla3_okl/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optasm) /tmp/ghctest-sla3_okl/test spaces/perf/space_leaks/T4334.run T4334 [stat not good enough] (threaded2) /tmp/ghctest-sla3_okl/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (dyn) /tmp/ghctest-sla3_okl/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optllvm) /tmp/ghctest-sla3_okl/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded1) /tmp/ghctest-sla3_okl/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded2) /tmp/ghctest-sla3_okl/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profthreaded) == Start post-testsuite package check GHC package manager version 8.7.20181102 Timestamp 2018-11-03 11:53:47.825914931 UTC for /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181102/package.conf.d/package.cache using cache: /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181102/package.conf.d/package.cache db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181102/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181102/package.conf.d"] flag db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181102/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181102/package.conf.d"] == End post-testsuite package check }}} As indicated above, some of these errors are caused by `GhostScript not available for hp2ps tests`. It turns out that I do have gs installed. Do I need to be running my terminal over a gui, rather than ssh, perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 13:47:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 13:47:19 -0000 Subject: [GHC] #11477: Remove -Wamp In-Reply-To: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> References: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> Message-ID: <061.ed5558e4e86c83d0f19ccb670df6a830@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.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:D4785 Wiki Page: | Phab:D5296 -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * differential: Phab: D4785 => Phab:D4785 Phab:D5296 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 15:01:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 15:01:24 -0000 Subject: [GHC] #15855: Warn about incomplete NamedFieldPuns patterns Message-ID: <051.e93dcaca790961e76627949ac09c5501@haskell.org> #15855: Warn about incomplete NamedFieldPuns patterns -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In certain situations it's nice to be able to ensure that record pattern matches are exhaustive: {{{#!haskell data R = R {a, b :: Int} -- should warn f R{a} = a -- should not warn g R{a, b} = a + b -- should not warn h R{a, ..} = a + b -- should not warn i R{a, b = _} = a }}} It's useful when there are several functions that inspect a record (e.g. handlers that update a subset of fields in a database) and we want to make certain that when a new field is added to the record, the programmer won't forget to update functions working with that record (either by handling the field or explicitly discarding it). Currently the only non-hacky way to do it is writing `f (R a _) = ...`, which is obviously not ideal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 15:38:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 15:38:13 -0000 Subject: [GHC] #15852: Bad axiom produced for polykinded data family In-Reply-To: <047.481c46c837c01249db862f276fa4c502@haskell.org> References: <047.481c46c837c01249db862f276fa4c502@haskell.org> Message-ID: <062.46e35d3ed0b9d6597d070dcc04d5494c@haskell.org> #15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies, | 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 think your hunch about it being a pretty-printing bug is right on the money. Moreover, I believe the `IfaceAxiom` case of `pprIfaceDecl` actually //is// the culprit, since: * `Coercion.pprCoAxiom` just calls `Coercion.ppr_co_ax_branch`, which already eta-expands the LHSes of data family instances. * `pprIfaceDecl` (for `IfaceAxiom`s) calls `pprAxBranch` which, judging from its current implementation: {{{#!hs pprAxBranch :: SDoc -> IfaceAxBranch -> SDoc pprAxBranch pp_tc (IfaceAxBranch { ifaxbTyVars = tvs , ifaxbCoVars = cvs , ifaxbLHS = pat_tys , ifaxbRHS = rhs , ifaxbIncomps = incomps }) = hang ppr_binders 2 (hang pp_lhs 2 (equals <+> ppr rhs)) $+$ nest 2 maybe_incomps where ppr_binders = sdocWithDynFlags $ \dflags -> ppWhen (gopt Opt_PrintExplicitForalls dflags) ppr_binders' ppr_binders' | null tvs && null cvs = empty | null cvs = brackets (pprWithCommas (pprIfaceTvBndr True) tvs) | otherwise = brackets (pprWithCommas (pprIfaceTvBndr True) tvs <> semi <+> pprWithCommas pprIfaceIdBndr cvs) pp_lhs = hang pp_tc 2 (pprParendIfaceAppArgs pat_tys) maybe_incomps = ppUnless (null incomps) $ parens $ text "incompatible indices:" <+> ppr incomps }}} Doesn't perform any sort of eta-expansion. In order to fix this, it looks like we'll need some equivalent of `etaExpandFamInstLHS`, but for iface data types. There's one major wrinkle that presents itself: how do we know that we're dealing with a data family instance in `pprAxBranch`? It's not obvious to me if that information is stored somewhere (I couldn't find anything in `IfaceTyCon`, for instance), and if not, where it //ought// to be stored. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 16:02:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 16:02:29 -0000 Subject: [GHC] #15855: Warn about incomplete NamedFieldPuns patterns In-Reply-To: <051.e93dcaca790961e76627949ac09c5501@haskell.org> References: <051.e93dcaca790961e76627949ac09c5501@haskell.org> Message-ID: <066.cd1aea76058ae82e1c8afbe371aa4aa3@haskell.org> #15855: Warn about incomplete NamedFieldPuns patterns -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Artyom.Kazak): A more concrete example: {{{#!haskell -- Handler for POST /update/info updateInfo :: UpdateInfo -> Handler () updateInfo u = do mapM_ setTitle (updateTitle u) mapM_ setDate (updateDate u) -- | Auxiliary data structure used by the handler. -- -- NB: Don't forget to update 'updateInfo' when adding fields here data UpdateInfo = UpdateInfo { updateTitle :: Maybe Text , updateDate :: Maybe UTCTime } instance FromJSON UpdateInfo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 19:28:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 19:28:58 -0000 Subject: [GHC] #15856: GhostScript not available for hp2ps tests Message-ID: <042.38af0a545c08ca985911b262b0de4318@haskell.org> #15856: GhostScript not available for hp2ps tests -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Keywords: ghostscript | Operating System: Linux gs hp2ps testsuite | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: T7919 T14761c | Blocked By: Blocking: | Related Tickets: #15736 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I run `validate --slow` a number of tests fail, apparently erroneously, because `GhostScript not available for hp2ps tests`. I don't know why this is the case (Ghostscript is installed on my ubuntu; perhaps there are some developer libraries / headers that also need to be installed, but I don't recall seeing anything in the documentation about that). The message "GhostScript not available for hp2ps tests" seems to come from a Python script that Simon Marlow produced in 2002. Unfortunately, there are two places where the message could have been generated. There are probably 2 ways forward: - a temporary bodge: taking the running of those tests that depend on hp2ps out of validation, in the same way that certain tests are not run when a dependent library is unavailable - figuring out why the python script fails to understand that a ghostscript is actually present and fixing that -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 21:10:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 21:10:38 -0000 Subject: [GHC] #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.432df9b0bd4c8e77bef0caf8f9287974@haskell.org> #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * priority: high => normal * owner: AndreasK => (none) Comment: Fixing this won't be easy, so for the moment I will leave it as is. The main issue is that we try to jump from a loaded library to the rts. Now we have the problem that we end up with a memory layout of something like this: <... 2+GB of things ...> Fixing the C stubs was reasonably easy. We can just tell gcc to use the large memory model making jumps 64bit sized. What I had failed to consider is that we also jump into the rts from regular haskell code. Now making sure all THIS code works well with a 64 bit address space sounds bad enough. But it also comes with performance costs as we increase code size. Given, probably not a big one but still. So even IF we fix this we would incurr a performance penalty for pretty much ALL haskell programs out there. So this seems like it's not worth it at the moment unless there are somehow a lot of "random" crashes out there which can be traced back to this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 22:46:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 22:46:54 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.1925b76bf9e75feaae78a8cbc7407833@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks, goldfire. With the push in comment:6, I was able to barf out this code: {{{#!diff diff --git a/compiler/typecheck/TcTyClsDecls.hs b/compiler/typecheck/TcTyClsDecls.hs index 5725cfd..438884b 100644 --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -483,6 +483,19 @@ kcTyClGroup :: [LTyClDecl GhcRn] -> TcM [TcTyCon] -- Third return value is Nothing if the tycon be unsaturated; otherwise, -- the arity kcTyClGroup decls + | [ldecl@(L _ decl@(SynDecl { tcdLName = L _ name + , tcdTyVars = ktvs + , tcdRhs = rhs }))] <- decls + , not (hsDeclHasCusk decl) + = do tycon <- kcLHsQTyVars name TypeSynonymFlavour False ktvs $ + snd <$> tcLHsType rhs + solveEqualities $ tcExtendKindEnvWithTyCons [tycon] $ kcLTyClDecl ldecl + candidates <- gather1 tycon + _ <- quantifyTyVars emptyVarSet candidates + poly_tycon <- generalise tycon + return [poly_tycon] + + | otherwise = do { mod <- getModule ; traceTc "---- kcTyClGroup ---- {" (text "module" <+> ppr mod $$ vcat (map ppr decls)) }}} Surprisingly, this actually seems to do the trick—`type C = B` actually typechecks with this! The code is a little messy in its current state, but it appears to get the job done. Surely this must be too good to be true? Well, it turns out it //is// too good to be true. With this patch, there are three test cases whose error messages degrade in quality. They are: * `ghc-e-fail2`: {{{#!diff diff -uw "ghc-e/should_fail/ghc-e-fail2.run/ghc-e-fail2.stderr.normalised" "ghc-e/should_fail/ghc-e-fail2.run/ghc-e-fail2.run.stderr.normalised" --- ghc-e/should_fail/ghc-e-fail2.run/ghc-e-fail2.stderr.normalised 2018-11-03 18:35:09.522096111 -0400 +++ ghc-e/should_fail/ghc-e-fail2.run/ghc-e-fail2.run.stderr.normalised 2018-11-03 18:35:09.522096111 -0400 @@ -1,4 +1,5 @@ -:0:1: - Cycle in type synonym declarations: - :0:1-10: type A = A +:0:10: + Type constructor ‘A’ cannot be used here + (it is defined and used in the same recursive group) + In the type ‘A’ }}} I think the reason this happens is because we're now calling `tcLHsType` before the code that perform the type-synonym cycle detection, and `tcLHsType` eventually invoked `promotionErr` when it sees `A` on the RHS (resulting in the "same recursive group" message). I think calling `tcExtendKindEnvWithTyCons` before `tcLHsType` would avoid `promotionErr` being invoked, but the problem is that the tycon that we need to pass `tcExtendKindEnvWithTyCons` is returned by `kcLHsQTyVars ... (tcLHsType rhs)` itself! So I'm stuck in a Catch-22 situation. * `T7433` and `T10451`: {{{#!diff diff -uw "polykinds/T7433.run/T7433.stderr.normalised" "polykinds/T7433.run/T7433.comp.stderr.normalised" --- polykinds/T7433.run/T7433.stderr.normalised 2018-11-03 18:39:39.494098330 -0400 +++ polykinds/T7433.run/T7433.comp.stderr.normalised 2018-11-03 18:39:39.494098330 -0400 @@ -3,4 +3,3 @@ Data constructor ‘Z’ cannot be used here (perhaps you intended to use DataKinds) In the type ‘ 'Z’ - In the type declaration for ‘T’ }}} {{{#!diff diff -uw "polykinds/T10451.run/T10451.stderr.normalised" "polykinds/T10451.run/T10451.comp.stderr.normalised" --- polykinds/T10451.run/T10451.stderr.normalised 2018-11-03 18:39:39.702098331 -0400 +++ polykinds/T10451.run/T10451.comp.stderr.normalised 2018-11-03 18:39:39.702098331 -0400 @@ -2,10 +2,10 @@ T10451.hs:22:12: Constraint tuple arity too large: 64 (max arity = 62) Instead, use a nested tuple - In the type ‘(Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, + In the type ‘(Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, - Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a)’ - In the type declaration for ‘T’ + Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, Eq a, + Eq a)’ }}} I'm not sure yet what is causing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 3 23:19:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Nov 2018 23:19:20 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.691d1d0be2b34fb2df9d8ddf11f1b49f@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): A few remarks about the code: - Put the `solveEqualities` around the first line, as the `tcLHsType` can emit constraints, and these will need to be solved. - Remove the second line. We don't need to run `kcTyClDecl` here. `kcTyClDecl`'s purpose in life is to generate constraints on the unification variables generates in `getInitialKind`. But we're not calling `getInitialKind`, so no need for `kcTyClDecl`. - Generalization looks about right. About the changed error messages: - The first will be hard to fix, for the reasons you describe. You could probably put some variant of `APromotionErr` in the env't to get a better message here. No, you can't just put the tycon in the env't, because you're making the tycon. Don't even think about `fixM` here. - The others just want for a `addTyConCtxt` around the call to `generalise`, which does a wee bit of validity checking. Otherwise, looks good! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 01:09:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 01:09:24 -0000 Subject: [GHC] #15832: fprintCCS_stderr (+RTS -xc) should be able to recurse into stacks that evaluated a given stack even if the latter does not come from a CAF (was: returnIO/bindIO destroys runtime explicit stack information in some cases) In-Reply-To: <048.4f171325e6580b41c039ea3becfab225@haskell.org> References: <048.4f171325e6580b41c039ea3becfab225@haskell.org> Message-ID: <063.3d0706f7ebbf0be994ec1cebe14bb50d@haskell.org> #15832: fprintCCS_stderr (+RTS -xc) should be able to recurse into stacks that evaluated a given stack even if the latter does not come from a CAF -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.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 infinity0): infinity0, have you considered simply using a more aggressive -fprof-* flag? bgamari: i'm already using "-fprof-auto -fprof-auto-calls -fprof-cafs" that seems to be the most aggressive available option ahh yes, so you are well then, that is indeed tricky can you describe where ideally you would like CCs to be inserted? i tried manually inserting CCs in the bad cases and couldn't get them working, so i don't really know but it seems to me that the logic that traverses different stacks to find subsequent "evaluated by" stacks, maybe can be expanded because it apparently only works when each stack except the last starts from a CAF i previously thought perhaps everything is supposed to start from a CAF but from what you're saying now it seems maybe not in which case, the "evaluated by" traversal logic ofc can't work for these latter cases * bgamari tries to work out what the stack looks like in the bad case infinity0, for what it's worth, I'm not sure this will just be a matter of expanding the existing stack printing logic infinity0, I suspect the information you need is actually not present at runtime oh :( afterall, in both cases we have tail-called so there is no stack frame to reconstruct execution from it just happens that in the good case we tail called into a CAF, which had a cost center I agree that this is an unfortunate behavior though I may be missing something but I think the right way to think about this may be from the perspective of finding a heuristic to use to insert the necessary CCs admittedly it's not immediately clear what that should look like, however yeah, going back to the original bad example, I tried changing it to {-# SCC test0 #-} ( {-# SCC test1 #-} \_ -> {-# SCC test2 #-} (print ... and this didn't fix the stack either I'll admit, that's a bit surprising oh, perhaps because it's non-updateable so you don't get an update frame -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 01:14:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 01:14:41 -0000 Subject: [GHC] #15832: fprintCCS_stderr (+RTS -xc) should be able to traverse into stacks that evaluated a given stack even if the latter does not come from a CAF (was: fprintCCS_stderr (+RTS -xc) should be able to recurse into stacks that evaluated a given stack even if the latter does not come from a CAF) In-Reply-To: <048.4f171325e6580b41c039ea3becfab225@haskell.org> References: <048.4f171325e6580b41c039ea3becfab225@haskell.org> Message-ID: <063.29d42e61aa274cf09a88c7e4a60ef899@haskell.org> #15832: fprintCCS_stderr (+RTS -xc) should be able to traverse into stacks that evaluated a given stack even if the latter does not come from a CAF -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 14:03:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 14:03:43 -0000 Subject: [GHC] #15857: Need for better warnings arising from StarIsType extension Message-ID: <042.ac2cb7754b32f4dedfcfabfb3e5b7bb2@haskell.org> #15857: Need for better warnings arising from StarIsType extension -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.6.1 Keywords: StarIsType | Operating System: Unknown/Multiple NoStarIsType | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I redefine `type (*) = (,)` I am given not given a warning that it doesn't do what I expect, when building with cabal new-repl or cabal new- build, because the `StarIsType` extension is now enabled by default. Instead or a warning, I get (correct but confusing) error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 14:04:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 14:04:19 -0000 Subject: [GHC] #15857: Need for better warnings arising from StarIsType extension In-Reply-To: <042.ac2cb7754b32f4dedfcfabfb3e5b7bb2@haskell.org> References: <042.ac2cb7754b32f4dedfcfabfb3e5b7bb2@haskell.org> Message-ID: <057.834be8d06b2e74618ce30d826cec883b@haskell.org> #15857: Need for better warnings arising from StarIsType extension -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: StarIsType | NoStarIsType 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 jrp: Old description: > If I redefine `type (*) = (,)` I am given not given a warning that it > doesn't do what I expect, when building with cabal new-repl or cabal new- > build, because the `StarIsType` extension is now enabled by default. > Instead or a warning, I get (correct but confusing) error messages. New description: If I redefine `type (*) = (,)` I am given not given a warning that it doesn't do what I expect, when building with cabal new-repl or cabal new- build, because the `StarIsType` extension is now enabled by default. Instead of a warning, I get (correct but confusing) error messages. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 14:12:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 14:12:56 -0000 Subject: [GHC] #15856: GhostScript not available for hp2ps tests In-Reply-To: <042.38af0a545c08ca985911b262b0de4318@haskell.org> References: <042.38af0a545c08ca985911b262b0de4318@haskell.org> Message-ID: <057.a396d1219f7d606ebd6f2875567e538e@haskell.org> #15856: GhostScript not available for hp2ps tests -------------------------------------+------------------------------------- Reporter: jrp | Owner: monoidal Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: ghostscript | gs hp2ps testsuite Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T7919 T14761c Blocked By: | Blocking: Related Tickets: #15736 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * owner: (none) => monoidal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 16:56:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 16:56:06 -0000 Subject: [GHC] #15611: scope errors lie about what modules are imported In-Reply-To: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> References: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> Message-ID: <059.68f485024a61a89ab04cb312481afeab@haskell.org> #15611: scope errors lie about what modules are imported -------------------------------------+------------------------------------- Reporter: dmwit | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST="T15611a T15611b" Blocked By: | Blocking: Related Tickets: #14225 | Differential Rev(s): Phab:D5284 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"1a3b9bd0b674ad16a41b942c738b8f34564bcd8d/ghc" 1a3b9bd0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1a3b9bd0b674ad16a41b942c738b8f34564bcd8d" Fix for Trac #15611: Scope errors lie about what modules are imported. Summary: For the error message: Not in scope X.Y Module X does not export Y No module named ‘X’ is imported: there are 2 cases, where we don't show the last "no module named is imported" line: 1. If the module X has been imported. 2. If the module X is the current module. There are 2 subcases: 2.1 If the unknown module name is in a input source file, then we can use the getModule function to get the current module name. 2.2 If the unknown module name has been entered by the user in GHCi, then the getModule function returns something like "interactive:Ghci1", and we have to check the current module in the last added entry of the HomePackageTable. Test Plan: make test TESTS="T15611a T15611b" Reviewers: monoidal, hvr, thomie, dfeuer, bgamari, DavidEichmann Reviewed By: monoidal, DavidEichmann Subscribers: rwbarton, carter GHC Trac Issues: #15611 Differential Revision: https://phabricator.haskell.org/D5284 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 17:15:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 17:15:24 -0000 Subject: [GHC] #15856: GhostScript not available for hp2ps tests In-Reply-To: <042.38af0a545c08ca985911b262b0de4318@haskell.org> References: <042.38af0a545c08ca985911b262b0de4318@haskell.org> Message-ID: <057.1464212430b65dd35d19a418db9acc80@haskell.org> #15856: GhostScript not available for hp2ps tests -------------------------------------+------------------------------------- Reporter: jrp | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: ghostscript | gs hp2ps testsuite Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T7919 T14761c Blocked By: | Blocking: Related Tickets: #15736 | Differential Rev(s): Phab:D5298 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => patch * differential: => Phab:D5298 Comment: I wrote a patch. Could you check if you see "GhostScript available" after applying it? It seems to me that hasn't been working for some time - I think I fixed GhostScript detection but other things might still be broken. One day, I'd like to simplify the Python runner - currently options are set via `-e`, then `config/ghc`, then `--config`; there are possible conflicts. Ideally, there should be one pass that reads the commandline and sets every option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 17:22:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 17:22:33 -0000 Subject: [GHC] #15611: scope errors lie about what modules are imported In-Reply-To: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> References: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> Message-ID: <059.c00b17ce4d62c3e9c1c6006039cb0397@haskell.org> #15611: scope errors lie about what modules are imported -------------------------------------+------------------------------------- Reporter: dmwit | Owner: RolandSenn Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST="T15611a T15611b" Blocked By: | Blocking: Related Tickets: #14225 | Differential Rev(s): Phab:D5284 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 22:35:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 22:35:41 -0000 Subject: [GHC] #15054: ghc internal error appeared in GHCI In-Reply-To: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> References: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> Message-ID: <060.72e5795a1856e7ea5de635d91c4e660b@haskell.org> #15054: ghc internal error appeared in GHCI -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger 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 ohhellojoe): I don't have much to add, but I saw a similar error message. In my case, it was a compiled binary that I left running for a long time and when I came back to it I saw that it had terminated with this error: {{{ dhtd: internal error: Unable to commit 1048576 bytes of memory (GHC version 8.4.4 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} This, of course, could have happened during idle GC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 23:20:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 23:20:56 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.960a2e0dc4c7787ab012a77572ca4158@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: gadt/T15009 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): I've worked through some interesting examples and distilled them into a first draft rule. CTRL+F for "Rule 20181104" on wiki:FloatMoreEqs2018. The page has dated entries, but today's should supersede all the older ones. I'm traveling on vacation for a couple weeks, so that will certainly derail me for a while. Today's entry was an effort to have something useful to come back to, but it has a couple TODOs. I think the first (Example 5) is a matter of finding the right presentation, while the second (Does RHS of {{{w}}} matter?) is something I just haven't thought much about yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 23:30:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 23:30:06 -0000 Subject: [GHC] #15858: Enabling a pure Plugin with existing build output never triggers recompilation Message-ID: <046.ba3058a9ee215deea2cba63e68e9aead@haskell.org> #15858: Enabling a pure Plugin with existing build output never triggers recompilation -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following compilation session: {{{ $ ghc -fplugin ImpurePlugin Foo.hs $ ghc Foo.hs }}} where ImpurePlugin is a `Plugin` which returns `ForceRecompile` in `pluginRecompile`. The second invocation of GHC doesn't recompile even though `ImpurePlugin` could have changed the generated build output which would now be out of date. The same thing happens when switching from an impure/fingerprinted plugin to a pure plugin. The problem is that `pluginRecompileToRecompileRequired` just assumes no compilation is required when the current plugin stack is pure, that is either only pure plugins or no plugins at all are registered: {{{ pluginRecompileToRecompileRequired :: Fingerprint -> PluginRecompile -> RecompileRequired pluginRecompileToRecompileRequired old_fp pr = case pr of NoForceRecompile -> UpToDate ForceRecompile -> RecompBecause "Plugin forced recompilation" MaybeRecompile fp -> if fp == old_fp then UpToDate }}} note the `UpToDate` in the `NoForceRecompile` case. Furthermore I would argue that even switching from having no plugin at all active to having a pure plugin active should trigger recompilation, even though the plugin might be pure it could still choose to affect the build output after all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 4 23:53:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Nov 2018 23:53:50 -0000 Subject: [GHC] #15858: Enabling a pure Plugin with existing build output never triggers recompilation In-Reply-To: <046.ba3058a9ee215deea2cba63e68e9aead@haskell.org> References: <046.ba3058a9ee215deea2cba63e68e9aead@haskell.org> Message-ID: <061.5fa96b8ff9a4701f33d6af7fef182806@haskell.org> #15858: Enabling a pure Plugin with existing build output never triggers recompilation -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5299 Wiki Page: | -------------------------------------+------------------------------------- Changes (by DanielG): * status: new => patch * differential: => Phab:D5299 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 00:10:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 00:10:43 -0000 Subject: [GHC] #15858: Enabling a pure Plugin with existing build output never triggers recompilation In-Reply-To: <046.ba3058a9ee215deea2cba63e68e9aead@haskell.org> References: <046.ba3058a9ee215deea2cba63e68e9aead@haskell.org> Message-ID: <061.8e5244fc87eb26c1867ee43557d306fc@haskell.org> #15858: Enabling a pure Plugin with existing build output never triggers recompilation -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5299 Wiki Page: | -------------------------------------+------------------------------------- Comment (by DanielG): For now I've not implemented recompilation when going from no plugins -> some plugins or the other way around. I'm waiting for feedback on the desired behaviour in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 01:33:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 01:33:18 -0000 Subject: [GHC] #15755: randomRIO panic on (GHC version 8.4.3 for x86_64-apple-darwin) In-Reply-To: <043.d99d803d2e9b59ef17275c0dcbc2174a@haskell.org> References: <043.d99d803d2e9b59ef17275c0dcbc2174a@haskell.org> Message-ID: <058.5b0da183bb0c8eb8ead9a87be4f161d6@haskell.org> #15755: randomRIO panic on (GHC version 8.4.3 for x86_64-apple-darwin) -------------------------------------+------------------------------------- Reporter: cmal | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: randomRIO Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by khanage): I've also encountered this on macos 10.13. Here's the logs from a ghci session: {{{ λ> :set -package random package flags have changed, resetting and loading new packages... λ> import System.Random (randomRIO) λ> randomRIO (10, 100) ghc: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-apple-darwin): nameModule system $dShow_a12oz Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug λ> r <- randomRIO (10, 100) λ> r 46 }}} Maybe ghci has a problem with showing unbound values? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 02:23:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 02:23:25 -0000 Subject: [GHC] #15859: Dependent quantification, GHC panic Message-ID: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> #15859: Dependent quantification, GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While exploring [https://gist.github.com/RyanGlScott/ded669b5ae3db1ce38c4b6021f144776 Ryan's gist for term-level] `f :: forall a -> a -> Type`. {{{#!hs {-# Language PolyKinds #-} {-# Language TypeApplications #-} {-# Language ImpredicativeTypes #-} import Data.Kind data A k :: k -> Type f :: KindOf A f a = undefined type KindOf (a :: k) = k a = f @Int }}} gives {{{ $ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot- ghci 630_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 630_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181029 for x86_64-unknown-linux): ASSERT failed! KindOf A forall k -> k -> * k_a1xQ[sk:0] k_a1xQ[sk:0] -> * k_a1xQ[sk:0] [req] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcExpr.hs:1336:94 in ghc:TcExpr Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 03:40:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 03:40:30 -0000 Subject: [GHC] #15859: Dependent quantification, GHC panic In-Reply-To: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> References: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> Message-ID: <066.14f82f1b4170c728beb902b4ab559a22@haskell.org> #15859: Dependent quantification, GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): minimized {{{#!hs {-# Language PolyKinds #-} {-# Language TypeApplications #-} {-# Language ImpredicativeTypes #-} import Data.Kind data A k :: k -> Type type KindOf (a :: k) = k a = (undefind :: KindOf A) @Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 09:23:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 09:23:15 -0000 Subject: [GHC] #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.3a1df78a05ad28b3191fd0d1b8511a13@haskell.org> #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): If anyone ever wants to pick this up since 8.6 there is also -fexternal- dynamic-refs which goes most of the way already. Currently building GHC with the flag fails with linker errors. But it seems like a good starting point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 10:02:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 10:02:50 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD Message-ID: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, I've tried a `hadrian/build.sh -j` on my FreeBSD machine and got greeted by a rather nasty looking error. {{{ Up to date shakeArgsWith 0.000s 0% Function shake 0.275s 80% ========================= Database read 0.000s 0% With database 0.000s 0% Running rules 0.065s 19% ===== Total 0.340s 100% Error when running Shake build system: * OracleQ (KeyValue ("hadrian/cfg/system.config","host-os")) * hadrian/cfg/system.config * hadrian/cfg/system.config settings mk/config.h compiler/ghc.cabal rts/rts.cabal Configuration file hadrian/cfg/system.config is missing. Run the configure script manually or let Hadrian run it automatically by passing the flag --configure. CallStack (from HasCallStack): error, called at src/Rules/Configure.hs:25:13 in main:Rules.Configure }}} I've tried this with commit `1a3b9bd0b674ad16a41b942c738b8f34564bcd8d` and my current system is `FreeBSD lain 12.0-BETA3 FreeBSD 12.0-BETA3 r340097 GENERIC amd64`. Building GHC with the old build system worked perfectly fine though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 10:52:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 10:52:39 -0000 Subject: [GHC] #15861: Cannot import (*) type operator Message-ID: <047.a3070fc796894bef9a262534f0a07d57@haskell.org> #15861: Cannot import (*) type operator -------------------------------------+------------------------------------- Reporter: pgujjula | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The (*) type operator cannot be imported from GHC.TypeLits. The following code compiles in GHC 8.4.4 but fails in GHC 8.6.1 with "error: parse error on input ‘*’" {{{#!hs {-# LANGUAGE TypeOperators #-} import GHC.TypeLits (type (*)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 13:24:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 13:24:21 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.5e76479636c1ae2e7cd893f4159eb71f@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 alpmestan): * cc: snowleopard (added) Comment: As stated in the #ghc IRC channel and as suggested by the error message, I suspect you have not run `./configure` (and maybe not even `./boot`?). You can run `./boot && ./configure` yourself or ask hadrian to do it by passing `--configure` or `-c`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 13:34:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 13:34:59 -0000 Subject: [GHC] #15862: Typeable panic with promoted rank-2 kind (initDs) Message-ID: <050.a59278de72961367e1dea424ce2860fa@haskell.org> #15862: Typeable panic with promoted rank-2 kind (initDs) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: Typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program panics on GHC 8.2 and later: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} module Bug where import Type.Reflection newtype Foo = MkFoo (forall a. a) foo :: TypeRep MkFoo foo = typeRep @MkFoo }}} {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) GHC error in desugarer lookup in Bug: attempting to use module ‘main:Bug’ (Bug.hs) which is not loaded ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-linux): initDs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 13:39:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 13:39:33 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.39a66d013c68d05e501da092c70f32b7@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 13:41:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 13:41:50 -0000 Subject: [GHC] #15855: Warn about incomplete NamedFieldPuns patterns In-Reply-To: <051.e93dcaca790961e76627949ac09c5501@haskell.org> References: <051.e93dcaca790961e76627949ac09c5501@haskell.org> Message-ID: <066.13f1408c88bbf0e8373bf2affe632b7d@haskell.org> #15855: Warn about incomplete NamedFieldPuns patterns -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): Can you be more precise about what you are asking for? I think it might be something like: * Warn about any record pattern that does not provide a pattern for every field of the record. What about {{{ g R{a,b} = a g R(a, ..} = a }}} Do those warn? Once we have a precise spec, I don't think this will be hard to implement (in the renamer). I can offer advice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 14:17:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 14:17:03 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.17c7f47ac4976befd622c532d6a21f65@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): is it ok to make a `joinpoints` directory in testsuite/tests/? if not, where should tests for this go? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 14:28:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 14:28:42 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.37faf555ad9aa54ade6f96a6aba07fbe@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 snowleopard): * cc: NeilMitchell (added) Comment: I guess the useful part of the error message is not easy to spot: > Configuration file hadrian/cfg/system.config is missing. > Run the configure script manually or let Hadrian run it automatically by passing the flag --configure. Or do the above two lines look nasty too? One thing we could improve is not show the stats when Hadrian terminates with a build error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 14:34:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 14:34:13 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.c990d23061cf39acaf84c147a2557362@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): There is already `testsuite/tests/perf/join_points` which you can use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 14:52:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 14:52:06 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.50fee7035e895c17a0d4cd744aeef6b4@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 raichoo): Getting a `CallStack` is IMHO a nasty error. It's not handling the situation gracefully, that's what I wanted to say. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 14:52:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 14:52:38 -0000 Subject: [GHC] #15862: Typeable panic with promoted rank-2 kind (initDs) In-Reply-To: <050.a59278de72961367e1dea424ce2860fa@haskell.org> References: <050.a59278de72961367e1dea424ce2860fa@haskell.org> Message-ID: <065.1ec29ebc4957db1a33778a4332651f5f@haskell.org> #15862: Typeable panic with promoted rank-2 kind (initDs) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I was surprised to see this, so I tried {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} module Bug where import Type.Reflection newtype Foo = MkFoo (forall a. a) foo :: TypeRep MkFoo foo = undefined }}} instead. And that program is accepted... but it really shouldn't be. The problem is that the type of `foo` is `TypeRep @((forall a. a) -> Foo) 'MkFoo`, which involves an impredicative instantiation of the kind variable of `TypeRep`. This is not currently allowed. I would fix the missing impredicativity check before worrying about `initDs`. However, with #12045, I suppose we'll want to start allowing impredicative kind instantiations... even then, we won't be able to deal with type representations involving foralls (at least, not without another rewrite of `TypeRep`). So, I suppose tackling the `initDs` bug directly is also a step forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 15:00:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 15:00:22 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.3833a2f2b75fc4796b93aec61c223317@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 snowleopard): I see, thanks! So far this has been our only way of handling errors in Hadrian, since this is what Shake recommends: > To raise a build error call error "error message". Shake will abort, showing the error message. (From https://github.com/ndmitchell/shake/blob/master/docs/Manual.md #tracing-and-debugging.) @NeilMitchell: Is there a more graceful way to report an error in Shake? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 15:06:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 15:06:46 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.5329bd7c47b513437a87a56843976e09@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 raichoo): I've tried what has been suggested on IRC but now I'm running into the following behavior: {{{ hadrian: '/usr/home/raichoo/Sources/ghc/ghc/_build/stage0/bin/ghc' exited with an error: ghc: missing -B option shakeArgsWith 0.000s 0% Function shake 0.275s 12% === Database read 0.125s 5% = With database 0.006s 0% Running rules 1.767s 81% ========================= Total 2.174s 99% Error when running Shake build system: * _build/stage1/lib/package.conf.d/rts-1.0.conf * OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Library, pkgName = "rts", pkgPath = "rts"}, way = v})) * _build/stage1/rts/setup-config ExitFailure 1 }}} Just running `/usr/home/raichoo/Sources/ghc/ghc/_build/stage0/bin/ghc` also reports `ghc: missing -B option`. Am I again missing something that's obvious here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 15:15:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 15:15:33 -0000 Subject: [GHC] #15863: Splcing a type class method selects the wrong instance Message-ID: <049.3c21fc110d711ef2aacc94971be8c9ed@haskell.org> #15863: Splcing a type class method selects the wrong instance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider these 4 modules as concocted by Csongor. The wrong instance is selected when you splice in `B.me` into `D`. https://gist.github.com/mpickering/959a95525647802414ab50e8e6ed490c {{{ module A where class C a where foo :: a -> String instance C Int where foo _ = "int" }}} {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoMonomorphismRestriction #-} module B where import A import Language.Haskell.TH instance C a => C [a] where foo _ = "list" me :: Q (TExp ([Int] -> String)) me = [|| foo ||] }}} {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoMonomorphismRestriction #-} module C where import A import Language.Haskell.TH instance {-# OVERLAPPING #-} C [Int] where foo _ = "list2" }}} {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE NoMonomorphismRestriction #-} module D where import A import B import C main2 = $$(me) [1 :: Int] }}} {{{ >>> main2 "list2" }}} In `B`, `B.me` is created by quoting `foo`. `B.me :: Q (TExp ([Int] -> String))` so in order to type check this quote we need to solve the instance `C [Int]` which we should do by using the instance defined in `B` (and `A`). In module `C` we define a different overlapping instance (note that this could be in a completely different library not under our control). When we then splice `B.me` into `D`, the instance from `C` is used and can be witnessed by printing `main2` which shows `"list2"` rather than `"list"` as expected. This is a symptom of the fact that the renamed rather than the typechecked AST is serialised I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 15:18:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 15:18:35 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.550054524771ba77ab7294df80af3378@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 snowleopard): No, this is not something obvious and does look like a bug. I haven't seen it before, and I have no idea what the `-B` option is for. I think this is related to wrapper scripts, which are not used on Windows (which I use). Perhaps @alpmestan has any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 15:44:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 15:44:38 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.13c2305345f8045514c5894056c09776@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: gadt/T15009 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): If I correctly understand what the "inert substitution" is, then I think I can summarize the intent of my draft rule as follows. > Let dis[i] be the domain of the inert substitution active in the wanteds of TcLevel i. We can safely float a wanted CTyEqCan {{{w : alpha[L] ~ }}} from level K to level L if dis[K] can never change (which implies dis[L] can never change -- ie no CTyEqCan might flip to reveal a new LHS) and if dis[K] - dis[L] does not include any metavars, any flattening skolems, or any skolems of level <= L. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 16:05:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 16:05:31 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.a26a9f72723ce65bdd5dcd0b3647caeb@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): ah, i didn't look in perf/. thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 17:01:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 17:01:28 -0000 Subject: [GHC] #15862: Typeable panic with promoted rank-2 kind (initDs) In-Reply-To: <050.a59278de72961367e1dea424ce2860fa@haskell.org> References: <050.a59278de72961367e1dea424ce2860fa@haskell.org> Message-ID: <065.5c3f66e2cb9c20b0f624726f2fde45e5@haskell.org> #15862: Typeable panic with promoted rank-2 kind (initDs) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:1 goldfire]: > I would fix the missing impredicativity check before worrying about `initDs`. In case you didn't notice this, I deliberately enabled `ImpredicativeTypes` in this program :) I, too, am surprised that this panics, though. Especially since `typeIsTypeable` appears to [http://git.haskell.org/ghc.git/blob/1a3b9bd0b674ad16a41b942c738b8f34564bcd8d:/compiler/typecheck/TcTypeable.hs#l440 already answer "no"] when a type contains a nested `forall` like this: {{{#!hs typeIsTypeable (ForAllTy{}) = False }}} It's possible that something else is going wrong, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 17:06:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 17:06:27 -0000 Subject: [GHC] #15861: Cannot import (*) type operator In-Reply-To: <047.a3070fc796894bef9a262534f0a07d57@haskell.org> References: <047.a3070fc796894bef9a262534f0a07d57@haskell.org> Message-ID: <062.f04f9b660a0c36801e343a805dba6697@haskell.org> #15861: Cannot import (*) type operator -------------------------------------+------------------------------------- Reporter: pgujjula | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: This is expected behavior. You have to enable the new `NoStarIsType` language extension. More details here: https://ghc.haskell.org/trac/ghc/wiki/Migration/8.6 I agree that it's unfortunate how this breaks, but it seemed better than other alternatives as we were preparing GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 17:21:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 17:21:11 -0000 Subject: [GHC] #15858: Enabling a pure Plugin with existing build output never triggers recompilation In-Reply-To: <046.ba3058a9ee215deea2cba63e68e9aead@haskell.org> References: <046.ba3058a9ee215deea2cba63e68e9aead@haskell.org> Message-ID: <061.30b99c2fa0f1f1512e812dcc5778a13a@haskell.org> #15858: Enabling a pure Plugin with existing build output never triggers recompilation -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5299 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: mpickering (added) * keywords: => Plugins -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 18:05:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 18:05:51 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.437631f08a968d21c36a65d0ad84dcd8@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 alpmestan): `-B` is used to point a given ghc executable to its associated "topdir" in GHC parlance, which corresponds to the `lib/` dir, which contains the `settings` file, the package db and all that. See [https://github.com/ghc/ghc/blob/master/compiler/main/SysTools/BaseDir.hs#L51 this note] for more. You can see that the error is thrown by [https://github.com/ghc/ghc/blob/master/compiler/main/SysTools/BaseDir.hs#L125 this piece of code], which tries to locate the topdir by looking up an env var and then by calling `getBaseDir`, whose implementations uses `getExecutablePath` on darwin/linux, does something else on Windows but returns `Nothing` the rest of the time. To put it another way, any GHC you build needs to be passed its topdir with `-B` (or to be used through a wrapper script), I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 18:52:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 18:52:03 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.164f57fc060c32dbb39225b2ec66b9bc@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 raichoo): I've adjusted the ifdefs to just go with the POSIX choices here, I currently don't see a reason why they shouldn't work on FreeBSD. However now I run into an issue where `libgmp` is not found by the linker even though I stated its location as an option to configure. {{{ Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: error: unable to find library -lgmp clang: error: linker command failed with exit code 1 (use -v to see invocati on) `clang' failed in phase `Linker'. (Exit code: 1) shakeArgsWith 0.000s 0% Function shake 0.781s 4% = Database read 0.692s 3% = With database 0.038s 0% Running rules 17.071s 91% ========================= Total 18.583s 100% Error when running Shake build system: * _build/stage1/lib/package.conf.d/rts-1.0.conf * _build/stage1/rts/build/libHSrts-1.0-ghc8.7.20181104_l.so user error (Development.Shake.cmd, system command failed Command: _build/stage0/bin/ghc -Wall -hisuf l_dyn_hi -osuf l_dyn_o -hcsuf l_ dyn_hc -fPIC -dynamic -eventlog -hide-all-packages -no-user-package-db '-pac kage-db _build/stage1/lib/package.conf.d' '-this-unit-id rts-1.0' -i -i_buil d/stage1/rts/build -i_build/stage1/rts/build/autogen -irts/. -Iincludes -I_b uild/generated -I_build/stage1/rts/build -I/usr/local/include -I/usr/local/i nclude -I_build/stage1/rts/build/build -I_build/stage1/rts/build/../includes -I_build/stage1/rts/build/includes -I_build/stage1/rts/build/includes/dist- derivedconstants/header -Irts/build -Irts/../includes -Irts/includes -Irts/i ncludes/dist-derivedconstants/header -I_build/generated -optc- I_build/genera ted -optP-include -optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcve rsion-file=_build/generated/ghcversion.h -optc-fno-stack-protector -odir _bu ild/stage1/rts/build -hidir _build/stage1/rts/build -stubdir _build/stage1/r ts/build -shared -dynamic -dynload deploy -no-auto-link-packages -rtsopts -o ptl-lgmp -Wnoncanonical-monad-instances -optc-Wno-unknown-pragmas _build/sta ge1/rts/build/c/Adjustor.l_dyn_o _build/stage1/rts/build/c/Arena.l_dyn_o _bu ild/stage1/rts/build/c/Capability.l_dyn_o _build/stage1/rts/build/c/CheckUnl oad.l_dyn_o _build/stage1/rts/build/c/ClosureFlags.l_dyn_o _build/stage1/rts /build/c/Disassembler.l_dyn_o _build/stage1/rts/build/c/FileLock.l_dyn_o _bu ild/stage1/rts/build/c/Globals.l_dyn_o _build/stage1/rts/build/c/Hash.l_dyn_ o _build/stage1/rts/build/c/Heap.l_dyn_o _build/stage1/rts/build/c/Hpc.l_dyn _o _build/stage1/rts/build/c/HsFFI.l_dyn_o _build/stage1/rts/build/c/Inlines .l_dyn_o _build/stage1/rts/build/c/Interpreter.l_dyn_o _build/stage1/rts/bui ld/c/LdvProfile.l_dyn_o _build/stage1/rts/build/c/Libdw.l_dyn_o _build/stage 1/rts/build/c/LibdwPool.l_dyn_o _build/stage1/rts/build/c/Linker.l_dyn_o _bu ild/stage1/rts/build/c/Messages.l_dyn_o _build/stage1/rts/build/c/OldARMAtom ic.l_dyn_o _build/stage1/rts/build/c/PathUtils.l_dyn_o _build/stage1/rts/bui ld/c/Pool.l_dyn_o _build/stage1/rts/build/c/Printer.l_dyn_o _build/stage1/rt s/build/c/ProfHeap.l_dyn_o _build/stage1/rts/build/c/ProfilerReport.l_dyn_o _build/stage1/rts/build/c/ProfilerReportJson.l_dyn_o _build/stage1/rts/build /c/Profiling.l_dyn_o _build/stage1/rts/build/c/Proftimer.l_dyn_o _build/stag e1/rts/build/c/RaiseAsync.l_dyn_o _build/stage1/rts/build/c/RetainerProfile. l_dyn_o _build/stage1/rts/build/c/RetainerSet.l_dyn_o _build/stage1/rts/buil d/c/RtsAPI.l_dyn_o _build/stage1/rts/build/c/RtsDllMain.l_dyn_o _build/stage 1/rts/build/c/RtsFlags.l_dyn_o _build/stage1/rts/build/c/RtsMain.l_dyn_o _bu ild/stage1/rts/build/c/RtsMessages.l_dyn_o _build/stage1/rts/build/c/RtsStar tup.l_dyn_o _build/stage1/rts/build/c/RtsSymbolInfo.l_dyn_o _build/stage1/rt s/build/c/RtsSymbols.l_dyn_o _build/stage1/rts/build/c/RtsUtils.l_dyn_o _bui ld/stage1/rts/build/c/STM.l_dyn_o _build/stage1/rts/build/c/Schedule.l_dyn_o _build/stage1/rts/build/c/Sparks.l_dyn_o _build/stage1/rts/build/c/StableNa me.l_dyn_o _build/stage1/rts/build/c/StablePtr.l_dyn_o _build/stage1/rts/bui ld/c/StaticPtrTable.l_dyn_o _build/stage1/rts/build/c/Stats.l_dyn_o _build/s tage1/rts/build/c/StgCRun.l_dyn_o _build/stage1/rts/build/c/StgPrimFloat.l_d yn_o _build/stage1/rts/build/c/Task.l_dyn_o _build/stage1/rts/build/c/Thread Labels.l_dyn_o _build/stage1/rts/build/c/ThreadPaused.l_dyn_o _build/stage1/ rts/build/c/Threads.l_dyn_o _build/stage1/rts/build/c/Ticky.l_dyn_o _build/s tage1/rts/build/c/Timer.l_dyn_o _build/stage1/rts/build/c/TopHandler.l_dyn_o _build/stage1/rts/build/c/Trace.l_dyn_o _build/stage1/rts/build/c/WSDeque.l _dyn_o _build/stage1/rts/build/c/Weak.l_dyn_o _build/stage1/rts/build/c/even tlog/EventLog.l_dyn_o _build/stage1/rts/build/c/eventlog/EventLogWriter.l_dy n_o _build/stage1/rts/build/c/hooks/FlagDefaults.l_dyn_o _build/stage1/rts/b uild/c/hooks/LongGCSync.l_dyn_o _build/stage1/rts/build/c/hooks/MallocFail.l _dyn_o _build/stage1/rts/build/c/hooks/OnExit.l_dyn_o _build/stage1/rts/buil d/c/hooks/OutOfHeap.l_dyn_o _build/stage1/rts/build/c/hooks/StackOverflow.l_ dyn_o _build/stage1/rts/build/c/linker/CacheFlush.l_dyn_o _build/stage1/rts/ build/c/linker/Elf.l_dyn_o _build/stage1/rts/build/c/linker/LoadArchive.l_dy n_o _build/stage1/rts/build/c/linker/M32Alloc.l_dyn_o _build/stage1/rts/buil d/c/linker/MachO.l_dyn_o _build/stage1/rts/build/c/linker/PEi386.l_dyn_o _bu ild/stage1/rts/build/c/linker/SymbolExtras.l_dyn_o _build/stage1/rts/build/c /linker/elf_got.l_dyn_o _build/stage1/rts/build/c/linker/elf_plt.l_dyn_o _bu ild/stage1/rts/build/c/linker/elf_plt_aarch64.l_dyn_o _build/stage1/rts/buil d/c/linker/elf_plt_arm.l_dyn_o _build/stage1/rts/build/c/linker/elf_reloc.l_ dyn_o _build/stage1/rts/build/c/linker/elf_reloc_aarch64.l_dyn_o _build/stag e1/rts/build/c/linker/elf_util.l_dyn_o _build/stage1/rts/build/c/sm/BlockAll oc.l_dyn_o _build/stage1/rts/build/c/sm/CNF.l_dyn_o _build/stage1/rts/build/ c/sm/Compact.l_dyn_o _build/stage1/rts/build/c/sm/Evac.l_dyn_o _build/stage1 /rts/build/c/sm/GC.l_dyn_o _build/stage1/rts/build/c/sm/GCAux.l_dyn_o _build /stage1/rts/build/c/sm/GCUtils.l_dyn_o _build/stage1/rts/build/c/sm/MBlock.l _dyn_o _build/stage1/rts/build/c/sm/MarkWeak.l_dyn_o _build/stage1/rts/build /c/sm/Sanity.l_dyn_o _build/stage1/rts/build/c/sm/Scav.l_dyn_o _build/stage1 /rts/build/c/sm/Storage.l_dyn_o _build/stage1/rts/build/c/sm/Sweep.l_dyn_o _ build/stage1/rts/build/c/xxhash.l_dyn_o _build/stage1/rts/build/c/fs.l_dyn_o _build/stage1/rts/build/c/posix/GetEnv.l_dyn_o _build/stage1/rts/build/c/po six/GetTime.l_dyn_o _build/stage1/rts/build/c/posix/Itimer.l_dyn_o _build/st age1/rts/build/c/posix/OSMem.l_dyn_o _build/stage1/rts/build/c/posix/OSThrea ds.l_dyn_o _build/stage1/rts/build/c/posix/Select.l_dyn_o _build/stage1/rts/ build/c/posix/Signals.l_dyn_o _build/stage1/rts/build/c/posix/TTY.l_dyn_o _b uild/stage1/rts/build/cmm/Apply.l_dyn_o _build/stage1/rts/build/cmm/Compact. l_dyn_o _build/stage1/rts/build/cmm/Exception.l_dyn_o _build/stage1/rts/buil d/cmm/HeapStackCheck.l_dyn_o _build/stage1/rts/build/cmm/PrimOps.l_dyn_o _bu ild/stage1/rts/build/cmm/StgMiscClosures.l_dyn_o _build/stage1/rts/build/cmm /StgStartup.l_dyn_o _build/stage1/rts/build/cmm/StgStdThunks.l_dyn_o _build/ stage1/rts/build/cmm/Updates.l_dyn_o _build/stage1/rts/build/cmm/AutoApply.l _dyn_o -o _build/stage1/rts/build/libHSrts-1.0-ghc8.7.20181104_l.so -O2 -H32 m -this-unit-id rts -XHaskell98 -ghcversion- file=/usr/home/raichoo/Sources/g hc/ghc/_build/generated/ghcversion.h -Irts -Wno-deprecated-flags -Wcpp- undef Exit code: 1 Stderr: Warning: -rtsopts and -with-rtsopts have no effect with -shared. Call hs_init_ghc() from your main() function to set these options. /usr/bin/ld: error: unable to find library -lgmp clang: error: linker command failed with exit code 1 (use -v to see invocati on) `clang' failed in phase `Linker'. (Exit code: 1) ) }}} {{{ ./configure LD=ld CC=clang --disable-large-address-space --with-gmp- includes=/usr/local/include --with-gmp-libraries=/usr/local/lib --with- iconv-includes=/usr/local/include --with-iconvlibraries=/usr/local/lib --prefix=/usr/home/raichoo/Local/ghc/HEAD }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 18:52:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 18:52:44 -0000 Subject: [GHC] #15859: Dependent quantification, GHC panic In-Reply-To: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> References: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> Message-ID: <066.3a35891135e51b2244d68ea3955ca300@haskell.org> #15859: Dependent quantification, GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"72b82343b79365dc74ffafb345dd33499a7fd394/ghc" 72b82343/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="72b82343b79365dc74ffafb345dd33499a7fd394" Fix #15859 by checking, not assuming, an ArgFlag We thought that visible dependent quantification was impossible in terms, but Iceland Jack discovered otherwise in #15859. This fixes an ASSERT failure that arose. test case: dependent/should_fail/T15859 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 18:53:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 18:53:39 -0000 Subject: [GHC] #15859: Dependent quantification, GHC panic In-Reply-To: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> References: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> Message-ID: <066.576f24c19f7b9a2d53c412d89c256c9e@haskell.org> #15859: Dependent quantification, GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T15859 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => dependent/should_fail/T15859 Comment: No reason not to merge, if we're still working on 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 18:55:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 18:55:19 -0000 Subject: [GHC] #15859: Dependent quantification, GHC panic In-Reply-To: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> References: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> Message-ID: <066.8eb80fec1a2961e12632e840410b9194@haskell.org> #15859: Dependent quantification, GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T15859 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 19:10:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 19:10:54 -0000 Subject: [GHC] #15864: Fix Int8#, Int16#, Word8#, Word16# tests under LLVM code generator Message-ID: <046.079da3a1ef7101f96f7646ad252afd59@haskell.org> #15864: Fix Int8#, Int16#, Word8#, Word16# tests under LLVM code generator -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 (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: -------------------------------------+------------------------------------- Unfortunately it looks like LLVM doesn't like that we use `bitcast` to narrow integers. E.g. `CmpWord8` currently fails with: {{{ =====> CmpWord8(llvm) 18 of 23 [0, 6, 0] cd "primops/should_run/CmpWord8.run" && "/mnt/work/ghc/ghc- compare-1/inplace/test spaces/ghc-stage2" -o CmpWord8 CmpWord8.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -Werror=compat -dno-debug-output -fllvm Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( CmpInt8.hs, CmpInt8.o ) opt: /run/user/1000/ghc32287_0/ghc_2.ll:14549:20: error: invalid cast opcode for cast from 'i64' to 'i8' %ln6uE = bitcast i64 %ln6uD to i8 ^ `opt' failed in phase `LLVM Optimiser'. (Exit code: 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 19:24:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 19:24:58 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack In-Reply-To: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> References: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> Message-ID: <061.faed2391e195a228d9b33ba2288a297a@haskell.org> #15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.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:D5256 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: fangyizhou may look into proposing adding more `HasCallStack`s elsewhere but this one is finished. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 19:25:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 19:25:05 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack In-Reply-To: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> References: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> Message-ID: <061.536fecea11a4589dceb10d5c0ca9e876@haskell.org> #15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.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:D5256 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 19:40:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 19:40:40 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.99bdca8eed8ba6e60468fa821ec07d78@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5301 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5301 * milestone: => 8.8.1 Comment: Alright, I've given it my best shot at Phab:D5301. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 19:55:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 19:55:02 -0000 Subject: [GHC] #15861: Cannot import (*) type operator In-Reply-To: <047.a3070fc796894bef9a262534f0a07d57@haskell.org> References: <047.a3070fc796894bef9a262534f0a07d57@haskell.org> Message-ID: <062.67ec1c4ecc479d588be0efea2bc1ec35@haskell.org> #15861: Cannot import (*) type operator -------------------------------------+------------------------------------- Reporter: pgujjula | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pgujjula): Ah thank you, my apologies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 21:24:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 21:24:41 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.f507e4142749709149155cdd78a75be1@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): I've applied the Phab:D5298 patch, and now get a bit further. The tests below fail on `validate -slow` but most of them run OK if I just `make TEST="..."` I'll leave the full trace of the latter below: {{{ ====> T15859(normal) 1 of 27 [0, 0, 0] cd "dependent/should_fail/T15859.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -c T15859.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -Werror=compat -dno-debug-output Actual stderr output differs from expected: diff -uw "dependent/should_fail/T15859.run/T15859.stderr.normalised" "dependent/should_fail/T15859.run/T15859.comp.stderr.normalised" --- dependent/should_fail/T15859.run/T15859.stderr.normalised 2018-11-05 21:16:05.108636964 +0000 +++ dependent/should_fail/T15859.run/T15859.comp.stderr.normalised 2018-11-05 21:16:05.108636964 +0000 @@ -1,6 +1 @@ - -T15859.hs:13:5: - Cannot apply expression of type ‘forall k -> k -> *’ - to a visible type argument ‘Int’ - In the expression: (undefined :: KindOf A) @Int - In an equation for ‘a’: a = (undefined :: KindOf A) @Int +: does not exist: T15859.hs *** unexpected failure for T15859(normal) =====> PrimFFIInt8(normal) 2 of 27 [0, 1, 0] cd "ffi/should_run/PrimFFIInt8.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o PrimFFIInt8 PrimFFIInt8.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output PrimFFIInt8_c.c cd "ffi/should_run/PrimFFIInt8.run" && ./PrimFFIInt8 =====> PrimFFIWord8(normal) 3 of 27 [0, 1, 0] cd "ffi/should_run/PrimFFIWord8.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o PrimFFIWord8 PrimFFIWord8.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output PrimFFIWord8_c.c cd "ffi/should_run/PrimFFIWord8.run" && ./PrimFFIWord8 =====> T12707(normal) 4 of 27 [0, 1, 0] cd "perf/compiler/T12707.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -c T12707.hs -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output +RTS -V0 -tT12707.comp.stats --machine-readable -RTS =====> T13379(normal) 5 of 27 [0, 1, 0] cd "perf/compiler/T13379.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -c T13379.hs -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output +RTS -V0 -tT13379.comp.stats --machine-readable -RTS =====> MultiLayerModules(normal) 6 of 27 [0, 1, 0] cd "perf/compiler/MultiLayerModules.run" && ./genMultiLayerModules cd "perf/compiler/MultiLayerModules.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" --make MultiLayerModules -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -Werror=compat -dno-debug-output -v0 +RTS -V0 -tMultiLayerModules.comp.stats --machine-readable -RTS =====> ManyConstructors(normal) 7 of 27 [0, 1, 0] cd "perf/compiler/ManyConstructors.run" && ./genManyConstructors cd "perf/compiler/ManyConstructors.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" --make ManyConstructors -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -Werror=compat -dno-debug-output -v0 +RTS -V0 -tManyConstructors.comp.stats --machine-readable -RTS =====> ManyAlternatives(normal) 8 of 27 [0, 1, 0] cd "perf/compiler/ManyAlternatives.run" && ./genManyAlternatives cd "perf/compiler/ManyAlternatives.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" --make ManyAlternatives -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -Werror=compat -dno-debug-output -v0 +RTS -V0 -tManyAlternatives.comp.stats --machine-readable -RTS =====> T13701(normal) 9 of 27 [0, 1, 0] cd "perf/compiler/T13701.run" && ./genT13701 cd "perf/compiler/T13701.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" --make T13701 -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -v0 +RTS -V0 -tT13701.comp.stats --machine-readable -RTS =====> T13719(normal) 10 of 27 [0, 1, 0] cd "perf/compiler/T13719.run" && ./genT13719 cd "perf/compiler/T13719.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" --make T13719 -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -v0 +RTS -V0 -tT13719.comp.stats --machine-readable -RTS =====> T14697(normal) 11 of 27 [0, 1, 0] cd "perf/compiler/T14697.run" && ./genT14697 cd "perf/compiler/T14697.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" --make T14697 -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output $(cat T14697-flags) -v0 +RTS -V0 -tT14697.comp.stats --machine-readable -RTS =====> T14683(normal) 12 of 27 [0, 1, 0] cd "perf/compiler/T14683.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" --make T14683 -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -v0 +RTS -V0 -tT14683.comp.stats --machine-readable -RTS =====> T9630(normal) 13 of 27 [0, 1, 0] cd "perf/compiler/T9630.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" --make T9630 -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -v0 -O +RTS -V0 -tT9630.comp.stats --machine-readable -RTS =====> T15164(normal) 14 of 27 [0, 1, 0] cd "perf/compiler/T15164.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -c T15164.hs -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -v0 -O +RTS -V0 -tT15164.comp.stats --machine-readable -RTS =====> T14936(normal) 15 of 27 [0, 1, 0] cd "perf/should_run/T14936.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o T14936 T14936.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -O2 cd "perf/should_run/T14936.run" && ./T14936 +RTS -V0 -tT14936.stats --machine-readable -RTS =====> space_leak_001(normal) 16 of 27 [0, 1, 0] cd "perf/space_leaks/space_leak_001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o space_leak_001 space_leak_001.hs -dcore-lint -dcmm-lint -no-user-package- db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output cd "perf/space_leaks/space_leak_001.run" && ./space_leak_001 +RTS -V0 -tspace_leak_001.stats --machine-readable -RTS =====> T4334(normal) 17 of 27 [0, 1, 0] cd "perf/space_leaks/T4334.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o T4334 T4334.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output cd "perf/space_leaks/T4334.run" && ./T4334 +RTS -V0 -tT4334.stats --machine-readable -RTS 1000000 2 t =====> ArithInt8(normal) 18 of 27 [0, 1, 0] cd "primops/should_run/ArithInt8.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o ArithInt8 ArithInt8.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "primops/should_run/ArithInt8.run" && ./ArithInt8 =====> ArithWord8(normal) 19 of 27 [0, 1, 0] cd "primops/should_run/ArithWord8.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o ArithWord8 ArithWord8.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "primops/should_run/ArithWord8.run" && ./ArithWord8 =====> CmpInt8(normal) 20 of 27 [0, 1, 0] cd "primops/should_run/CmpInt8.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o CmpInt8 CmpInt8.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "primops/should_run/CmpInt8.run" && ./CmpInt8 =====> CmpWord8(normal) 21 of 27 [0, 1, 0] cd "primops/should_run/CmpWord8.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o CmpWord8 CmpWord8.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "primops/should_run/CmpWord8.run" && ./CmpWord8 =====> ShowPrim(normal) 22 of 27 [0, 1, 0] cd "primops/should_run/ShowPrim.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o ShowPrim ShowPrim.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "primops/should_run/ShowPrim.run" && ./ShowPrim =====> T2783(normal) 23 of 27 [0, 1, 0] cd "rts/T2783.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc- stage2" -o T2783 T2783.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output cd "rts/T2783.run" && ./T2783 =====> T7919(normal) 24 of 27 [0, 1, 0] cd "rts/T7919.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc- stage2" -o T7919 T7919.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -dynamic cd "rts/T7919.run" && ./T7919 =====> T14761c(normal) 25 of 27 [0, 1, 0] cd "typecheck/should_compile/T14761c.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -c T14761c.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -Werror=compat -dno-debug-output -fno-warn- incomplete-patterns =====> user001(normal) 26 of 27 [0, 1, 0] cd "libraries/unix/tests/user001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o user001 user001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -package unix cd "libraries/unix/tests/user001.run" && ./user001 Actual stdout output differs from expected: diff -uw "libraries/unix/tests/user001.run/user001.stdout.normalised" "libraries/unix/tests/user001.run/user001.run.stdout.normalised" --- libraries/unix/tests/user001.run/user001.stdout.normalised 2018-11-05 21:18:01.037442648 +0000 +++ libraries/unix/tests/user001.run/user001.run.stdout.normalised 2018-11-05 21:18:01.037442648 +0000 @@ -6,6 +6,6 @@ getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK -getAllGroupEntries: OK +getAllGroupEntries: ERROR: getAllGroupEntries: does not exist (No such file or directory) getUserEntryForID: OK -getAllUserEntries: OK +getAllUserEntries: ERROR: getAllUserEntries: does not exist (No such file or directory) *** unexpected failure for user001(normal) =====> T3816(normal) 27 of 27 [0, 2, 0] cd "libraries/unix/tests/T3816.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o T3816 T3816.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -package unix cd "libraries/unix/tests/T3816.run" && ./T3816 Wrong exit code for T3816(normal)(expected 0 , actual 1 ) Stderr ( T3816 ): T3816: getAllGroupEntries: does not exist (No such file or directory) *** unexpected failure for T3816(normal) Unexpected results from: TEST="T15859 T3816 user001" SUMMARY for test run started at Mon Nov 5 21:16:04 2018 GMT 0:01:58 spent to go through 27 total tests, which gave rise to 161 test cases, of which 134 were skipped 0 had missing libraries 24 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 3 unexpected failures 0 unexpected stat failures Unexpected failures: dependent/should_fail/T15859.run T15859 [stderr mismatch] (normal) libraries/unix/tests/user001.run user001 [bad stdout] (normal) libraries/unix/tests/T3816.run T3816 [bad exit code] (normal) make[1]: *** [../mk/test.mk:330: test] Error 1 make[1]: Leaving directory '/home/jrp/Projects/ghc/testsuite/tests' make: *** [Makefile:224: test] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 5 22:19:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Nov 2018 22:19:50 -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.6e1b758dbca5ee838d93bb76b817b272@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) | Keywords: TypeInType, Resolution: | CUSKs 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, #15561, #15777 | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking| -------------------------------------+------------------------------------- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 00:09:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 00:09:49 -0000 Subject: [GHC] #15856: GhostScript not available for hp2ps tests In-Reply-To: <042.38af0a545c08ca985911b262b0de4318@haskell.org> References: <042.38af0a545c08ca985911b262b0de4318@haskell.org> Message-ID: <057.368c11bb6880e1b34a28de94150ec02e@haskell.org> #15856: GhostScript not available for hp2ps tests -------------------------------------+------------------------------------- Reporter: jrp | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: ghostscript | gs hp2ps testsuite Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T7919 T14761c Blocked By: | Blocking: Related Tickets: #15736 | Differential Rev(s): Phab:D5298 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): Seems to work now, I think. Thanks very much. (I cannot see any gs errors when I `validate --slow`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 02:43:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 02:43:38 -0000 Subject: [GHC] #15769: GHC 8.6 for macOS depends on homebrew In-Reply-To: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> References: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> Message-ID: <067.6f84297b14e03896e5efadbf3f4f2f7e@haskell.org> #15769: GHC 8.6 for macOS depends on homebrew -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kazu-yamamoto): I installed GHC 8.6.2. 1) The first problem ("sudo make install") is gone. 2) But the second problem remains. "ld: library not found for -lgmp" I cannot find what kind of assumption is made for libgmp on macOS from the manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 03:52:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 03:52:54 -0000 Subject: [GHC] #15859: Dependent quantification, GHC panic In-Reply-To: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> References: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> Message-ID: <066.4c6719eeeadfcf66da9413ebe739558e@haskell.org> #15859: Dependent quantification, GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T15859 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5693ddd071033516a1804420a903cb7e3677682b/ghc" 5693ddd0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5693ddd071033516a1804420a903cb7e3677682b" Actually add test for #15859. Oops. Forgot to `git add`. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 03:59:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 03:59:22 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.4a65c032d9f691fc3137342a2414214a@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmobile): I tried the absolute dumbest possible fix for this problem: inserting a fence before and after each atomic operation. Certainly many of these are superfluous, but I'm simply attempting an elephant gun solution that verifies the working hypothesis. It's up here https://github.com/traviswhitaker/ghc/tree/ghc843-wip/T15449 This seems to have no effect on this failure. When I inspected the machine code, I was surprised to find that very few dmb, dsb, and isb instructions were emitted. Only the RTS code (particularly for evacuation) and ghc-prim (particularly in the hs_atomic_* functions, no surprise there) seem to contain any dmb, dsb, or isb instructions. It seems as though none of the ldrex/strex style instructions are emitted at all. I'm in over my head when it comes to how GHC works here, so perhaps this is to be expected? Are things like std_takeMVar simply implemented with the handful of hs_atomic_* primitives? I'd be happy to attach a tarball of some or all of the completed build. Another thought: perhaps some architecture-specific assumptions have snuck into the Stg to Cmm pass or some Cmm to Cmm optimization that is performed. Perhaps it's just more trouble in StgCmmPrim, like https://ghc.haskell.org/trac/ghc/ticket/12469 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 10:12:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 10:12:39 -0000 Subject: [GHC] #15865: Typed template haskell and implicit parameters lead to incorrect results Message-ID: <049.50989e98ce3c53add7b90ce8ecb60b22@haskell.org> #15865: Typed template haskell and implicit parameters lead to incorrect results -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a similar vein to #15863 but this time with implicit parameters. https://gist.github.com/b6919b13abe0954fdad844e16e0edb48 {{{ {-# LANGUAGE ImplicitParams #-} {-# LANGUAGE TemplateHaskell #-} module A where import Language.Haskell.TH import Data.List (sortBy) sort :: (?cmp :: a -> a -> Ordering) => [a] -> [a] sort = sortBy ?cmp me :: Q (TExp ([Int] -> [Int])) me = let ?cmp = compare in [|| sort ||] }}} In module `A` we quote a value which has an implicit argument but in its context we bind the implicit so the type of the quote is the monomorphic type. {{{ {-# LANGUAGE ImplicitParams #-} {-# LANGUAGE TemplateHaskell #-} module B where import A foo :: [Int] -> [Int] foo = --let ?cmp = compare in $$(me) }}} When we splice in `me`, we get an error about an unbound implicit parameter which is totally bogus as we already bound it in `A`. There is also dynamic binding if another implicit parameter with the same name is in scope but the type of `me` mentions nothing about implicit parameters so this shouldn't be allowed. {{{ B.hs:8:10: error: • Unbound implicit parameter (?cmp::Int -> Int -> Ordering) arising from a use of ‘sort’ • In the expression: sort In the result of the splice: $me To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(me) | 8 | foo = $$(me) | ^^ Failed, one module loaded. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 10:30:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 10:30:58 -0000 Subject: [GHC] #15275: AArch64 validation fails with many invalid relocations In-Reply-To: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> References: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> Message-ID: <061.d99644cae6260b2dfb76a95e67de371d@haskell.org> #15275: AArch64 validation fails with many invalid relocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: 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 arrowd): * cc: arrowd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 12:20:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 12:20:54 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.320b43b256d39b89ecdb85c723f4ee9b@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 NeilMitchell): @snowleopard: I view printing the call stack when the build fails as very useful. Also note that it's not just printing the call stack of Haskell, some of those parts are the Shake build call stack. It's printed better in the latest version of Shake, as: {{{ Error when running Shake build system: at src/Test/Self.hs:27:5-26: * Depends on: Main.exe at src/Test/Self.hs:48:9-16: * Depends on: General/Wait.o * Depends on: General/Wait.o General/Wait.hi * Raised the exception: ... }}} Which hopefully improves things. I can see two further improvements: * Don't print timing information on an error. * If the exception is an {{{ErrorCallWithLocation}}} then grab the location information and put it in the rest of the stack trace - which then puts the stack traces together and the error at the end. You can of course override the Shake behaviour entirely by catching the {{{ShakeException}}} - but I think the call stack is super helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 12:35:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 12:35:36 -0000 Subject: [GHC] #15805: Bug in anyRewritableTyVar In-Reply-To: <047.87fb715ef5d84b486e63a473ac81c384@haskell.org> References: <047.87fb715ef5d84b486e63a473ac81c384@haskell.org> Message-ID: <062.9754c4061539c7dda8e22a8f41706dfe@haskell.org> #15805: Bug in anyRewritableTyVar -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: closed Priority: normal | Milestone: 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: #14363 | Differential Rev(s): Phab:D5263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ningning): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 14:46:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 14:46:01 -0000 Subject: [GHC] #15866: libiserv's version number is hard-coded Message-ID: <050.a6c32e24dcc226a38ba3ddc82a7fdbd6@haskell.org> #15866: libiserv's version number is hard-coded -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I recently discovered that GHC 8.6.2 was shipped with `libiserv-8.6.1`. Yes, you read that correctly—8.6.1, not 8.6.2. I was baffled at how this could possibly happen until I realized that we hard-code the version number for `libiserv` directly in its `.cabal` file. Needless to say, this is quite easy to forget to update. Let's let `autoconf` do the hard work for us and use `@ProjectVersionMunged@` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 14:48:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 14:48:20 -0000 Subject: [GHC] #15866: libiserv's version number is hard-coded In-Reply-To: <050.a6c32e24dcc226a38ba3ddc82a7fdbd6@haskell.org> References: <050.a6c32e24dcc226a38ba3ddc82a7fdbd6@haskell.org> Message-ID: <065.167a219b40593e6dd9543a667aa1db30@haskell.org> #15866: libiserv's version number is hard-coded -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5302 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5302 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 16:07:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 16:07:56 -0000 Subject: [GHC] #15867: STG scope error Message-ID: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- StgRhsClosure can contain duplicated names in its free variable and argument list. Example bug: libraries/integer-gmp/src/GHC/Integer/Type.hs GHC HEAD and 8.2.2 has this issue. I have not checked with other versions. I've extended the STG linter to do scope checking. See the patch attached. To reproduce: * patch GHC head: `git apply StgScopeCheck.patch` * make sure every compiled stg is linted: add `-dstg-lint` to GhcStage2HcOpts GhcLibHcOpts GhcRtsHcOpts config vars * compile GHC HEAD Background info: I've found this issue because I'm using GHC as a Haskell fronted for my whole program compiler project. I work on The GRIN Compiler (https://github.com/grin-tech) where GHC/GRIN compiles STG to GRIN. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 16:09:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 16:09:29 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.d2fd3b3cf11d4eb72f653c294d550726@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by csabahruska): * Attachment "StgScopeCheck.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 16:09:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 16:09:43 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.f6ab3a0c24f9fcc1a48b8eb69b56a1a3@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by csabahruska): * Attachment "stg-error.out.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 16:35:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 16:35:28 -0000 Subject: [GHC] #15805: Bug in anyRewritableTyVar In-Reply-To: <047.87fb715ef5d84b486e63a473ac81c384@haskell.org> References: <047.87fb715ef5d84b486e63a473ac81c384@haskell.org> Message-ID: <062.2e78da611e6e615634a75a249d1fe6b2@haskell.org> #15805: Bug in anyRewritableTyVar -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: closed Priority: normal | Milestone: 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: #14363 | Differential Rev(s): Phab:D5263 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ningning, is there a test case? Ideally we'd come up with one, knowing the bug. But not worth losing sleep over if it's hard to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 17:02:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 17:02:09 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.ca9902f70947ea98b9708b0336834ea8@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by csabahruska: Old description: > StgRhsClosure can contain duplicated names in its free variable and > argument list. > > Example bug: libraries/integer-gmp/src/GHC/Integer/Type.hs > > GHC HEAD and 8.2.2 has this issue. > > I have not checked with other versions. > > I've extended the STG linter to do scope checking. See the patch > attached. > > To reproduce: > * patch GHC head: `git apply StgScopeCheck.patch` > * make sure every compiled stg is linted: add `-dstg-lint` to > GhcStage2HcOpts GhcLibHcOpts GhcRtsHcOpts config vars > * compile GHC HEAD > > Background info: > I've found this issue because I'm using GHC as a Haskell fronted for my > whole program compiler project. I work on The GRIN Compiler > (https://github.com/grin-tech) where GHC/GRIN compiles STG to GRIN. New description: StgRhsClosure can contain duplicated names in its free variable and argument list. Example bug: libraries/integer-gmp/src/GHC/Integer/Type.hs GHC HEAD and 8.2.2 has this issue. I have not checked with other versions. I've extended the STG linter to do scope checking. See the patch attached. To reproduce: * patch GHC head: `git apply StgScopeCheck.patch` * make sure every compiled stg is linted: add the following to `mk/build.mk`\\ {{{ GhcStage2HcOpts += -dstg-lint GhcLibHcOpts += -dstg-lint GhcRtsHcOpts += -dstg-lint }}} * compile GHC HEAD Background info: I've found this issue because I'm using GHC as a Haskell fronted for my whole program compiler project. I work on The GRIN Compiler (https://github.com/grin-tech) where GHC/GRIN compiles STG to GRIN. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 18:10:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 18:10:11 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.e8517cd3cb48b2120f7ad8d0f77209b7@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by csabahruska): The interesting part for `libraries/integer-gmp/src/GHC/Integer/Type.hs` is: {{{ : warning: [in body of lambda with binders wild_sgiz :: Int#] ipv_sgiw :: Integer is duplicated (Uniq) : warning: [in body of lambda with binders wild_sgiz :: Int#] ipv1_sgix :: Integer is duplicated (Uniq) : warning: [in body of lambda with binders wild1_sgiB :: Int#] ipv_sgiw :: Integer is duplicated (Uniq) : warning: [in body of lambda with binders wild1_sgiB :: Int#] ipv1_sgix :: Integer is duplicated (Uniq) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 6 20:49:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Nov 2018 20:49:13 -0000 Subject: [GHC] #15864: Fix Int8#, Int16#, Word8#, Word16# tests under LLVM code generator In-Reply-To: <046.079da3a1ef7101f96f7646ad252afd59@haskell.org> References: <046.079da3a1ef7101f96f7646ad252afd59@haskell.org> Message-ID: <061.2d7b68575af3a894eb2ad60e58bbd5d2@haskell.org> #15864: Fix Int8#, Int16#, Word8#, Word16# tests under LLVM code generator -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.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 michalt): I thought that `validate` tests LLVM backend if LLVM is available, but this doesn't seem to be happening (despite testsuite is running with `-e ghc_with_llvm=True`)..? In any case, I'm testing fixes. Thanks for CCing me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 01:50:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 01:50:07 -0000 Subject: [GHC] #13080: Memory leak caused by nested monadic loops In-Reply-To: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> References: <048.4f7713b875928ea0a18ce51d5f94986c@haskell.org> Message-ID: <063.9b5418270144c579c39f5dd09de7d6fd@haskell.org> #13080: Memory leak caused by nested monadic loops -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harendra): * cc: harendra (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 01:52:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 01:52:23 -0000 Subject: [GHC] #12620: Allow the user to prevent floating and CSE In-Reply-To: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> References: <046.a53448d65079536b2a0eee2adcc7f49c@haskell.org> Message-ID: <061.f77398856a29934f2f4ca4549fde1f05@haskell.org> #12620: Allow the user to prevent floating and CSE -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #8457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harendra): * cc: harendra (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 09:25:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 09:25:54 -0000 Subject: [GHC] #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s In-Reply-To: <042.bdc5ad3927502391eb42801db38e8cb4@haskell.org> References: <042.bdc5ad3927502391eb42801db38e8cb4@haskell.org> Message-ID: <057.919960c767111132a7196857255f9eb8@haskell.org> #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: make test valid program | TEST=T11647 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5162 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 09:54:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 09:54:15 -0000 Subject: [GHC] #15611: scope errors lie about what modules are imported In-Reply-To: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> References: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> Message-ID: <059.29d7e6b57bb29127e42c88b3ce331db4@haskell.org> #15611: scope errors lie about what modules are imported -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST="T15611a T15611b" Blocked By: | Blocking: Related Tickets: #14225 | Differential Rev(s): Phab:D5284 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: RolandSenn => (none) * status: closed => new * resolution: fixed => Comment: While working on #14225 I discoverd that in patch Phab:D5284 I didn't respect the local naming conventions of module [https://github.com/ghc/ghc/blob/cad5d0b69bc039b635a6eb0e5c9ed47d7c5a38ed/compiler/rename/RnUnbound.hs]: - Top level functions names are in ''camelCase''. - Local function names in where clauses are ''hyphenated-names''. I reopen the ticket to fix this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 09:54:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 09:54:45 -0000 Subject: [GHC] #15611: scope errors lie about what modules are imported In-Reply-To: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> References: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> Message-ID: <059.aad3a53197826de2cd729322cba97ee6@haskell.org> #15611: scope errors lie about what modules are imported -------------------------------------+------------------------------------- Reporter: dmwit | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST="T15611a T15611b" Blocked By: | Blocking: Related Tickets: #14225 | Differential Rev(s): Phab:D5284 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 11:03:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 11:03:02 -0000 Subject: [GHC] #15856: GhostScript not available for hp2ps tests In-Reply-To: <042.38af0a545c08ca985911b262b0de4318@haskell.org> References: <042.38af0a545c08ca985911b262b0de4318@haskell.org> Message-ID: <057.e0ee6be2ccf411bd3d28523f765fc506@haskell.org> #15856: GhostScript not available for hp2ps tests -------------------------------------+------------------------------------- Reporter: jrp | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: ghostscript | gs hp2ps testsuite Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T7919 T14761c Blocked By: | Blocking: Related Tickets: #15736 | Differential Rev(s): Phab:D5298 Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): The same command that has shown the message `GhostScript not available`. If it's `validate`, the log of the last run should be present in a file called `testlog` in the top of the repository. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 11:55:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 11:55:21 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.5bdc02759ef65318ae61ea907b90a17e@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by csabahruska): Maybe my proposed STG scope checker is too strict. It does not allow name shadowing, but I can refine it further.\\ But the code above is definitely a bug as it contains duplicates in the closure binder list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 12:37:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 12:37:08 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.58cceb21b640b6a27269021fc5f6846f@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: | Keywords: 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 davide: Old description: > The ghc binary is dynamically linked via make in various flavors (e.g. > quick). Hadrian builds a static linked binary in these cases (this is a > bug). Various change are needed to fix this: > > 1. Add new .cabal file field extra-dynamic-library-flavours (see > [https://github.com/haskell/cabal/pull/5606 this PR]). > 2. Use .cabal extra-dynamic-library-flavours for the RTS (see > [https://github.com/snowleopard/hadrian/issues/695#issue-367436377 this > comment], depends on 1.) > 3. Hadrian: fix management of nontrivial dynamic flavours of libHSrts > (see [https://github.com/snowleopard/hadrian/pull/698 this PR]). > 4. Hadrian should build ghc with the `-fPIC -dynamic` options (see > [https://github.com/DavidEichmann/ghc/commit/752021f69f577b678630302b567fd712c565624b > #diff-408bbe46d4afae11991cbadb2c531b78 this comment], depends on 3.). > 5. Use the correct relative path to the dynamically linked libraries (see > [https://phabricator.haskell.org/D5281 this change], depends on 3. and > 4.). > 6. Build ghc-iserv-dyn, as it is will be required required by many tests > (see/depends on [https://phabricator.haskell.org/D5255 patch for ghc- > iserv-prof]) New description: The ghc binary is dynamically linked via make in various flavors (e.g. quick). Hadrian builds a static linked binary in these cases (this is a bug). Various change are needed to fix this: 1. Add new .cabal file field extra-dynamic-library-flavours (see [https://github.com/haskell/cabal/pull/5606 this PR]). 2. Use .cabal extra-dynamic-library-flavours for the RTS (see [https://github.com/snowleopard/hadrian/issues/695#issue-367436377 this comment], depends on 1.) 3. Hadrian: fix management of nontrivial dynamic flavours of libHSrts (see [https://github.com/snowleopard/hadrian/pull/698 this PR]). 4. Hadrian should build ghc with the `-fPIC -dynamic` options (see [https://github.com/DavidEichmann/ghc/commit/752021f69f577b678630302b567fd712c565624b #diff-408bbe46d4afae11991cbadb2c531b78 this comment], depends on 3.). 5. Use the correct relative path to the dynamically linked libraries (see [https://phabricator.haskell.org/D5281 patch D5281], depends on 3. and 4.). 6. Build ghc-iserv-dyn, as it is will be required required by many tests (see/depends on [https://phabricator.haskell.org/D5255 D5255 patch for ghc-iserv-prof]) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 12:43:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 12:43:48 -0000 Subject: [GHC] #15635: Implication introduction for quantified constraints In-Reply-To: <045.9730a55ea2e47eeaadddd9e4a6dedf50@haskell.org> References: <045.9730a55ea2e47eeaadddd9e4a6dedf50@haskell.org> Message-ID: <060.bbbf760eeb01da6789132d4a6d7a58d3@haskell.org> #15635: Implication introduction for quantified constraints -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bj0rn): This is the same as #14937. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 12:44:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 12:44:20 -0000 Subject: [GHC] #15635: Implication introduction for quantified constraints In-Reply-To: <045.9730a55ea2e47eeaadddd9e4a6dedf50@haskell.org> References: <045.9730a55ea2e47eeaadddd9e4a6dedf50@haskell.org> Message-ID: <060.dc5f41322e238f85bf2170969d0a7eba@haskell.org> #15635: Implication introduction for quantified constraints -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14937 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Bj0rn): * cc: Bj0rn (added) * related: => #14937 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 13:07:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 13:07:55 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.321ebdb911bc31070091b4615bef064d@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I am backing out both fixes on `master` as well until we have a fix. Kavon, if you could find the time it would be amazing if we could have this for 8.8; it would be a shame if we had to ship yet another release with a broken LLVM backend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 13:10:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 13:10:02 -0000 Subject: [GHC] #15864: Fix Int8#, Int16#, Word8#, Word16# tests under LLVM code generator In-Reply-To: <046.079da3a1ef7101f96f7646ad252afd59@haskell.org> References: <046.079da3a1ef7101f96f7646ad252afd59@haskell.org> Message-ID: <061.8695695f93e84eb5e1b3bb9460813663@haskell.org> #15864: Fix Int8#, Int16#, Word8#, Word16# tests under LLVM code generator -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.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 Ben Gamari ): In [changeset:"f424515fd8cbc2b7380cdf8427f972d062940bd5/ghc" f424515f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f424515fd8cbc2b7380cdf8427f972d062940bd5" [LlvmCodeGen] Fixes for Int8#/Word8# This fixes two isssues: - Using bitcast for MO_XX_Conv Arguments to a bitcast must be of the same size. We should be using `trunc` and `zext` instead. - Using unsupported MO_*_QuotRem for LLVM The two primops `MO_*_QuotRem` are not supported by the LLVM backend, so we shouldn't use them for `Int8#`/`Word8#` (just as we do not use them for `Int#`/`Word#`). Signed-off-by: Michal Terepeta Test Plan: manually run tests with WAY=llvm Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15864 Differential Revision: https://phabricator.haskell.org/D5304 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 13:13:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 13:13:05 -0000 Subject: [GHC] #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled Message-ID: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Exp where type family F a data T a = MkT (F a) deriving instance Eq (F a) => Eq (T a) data T2 a = T2 (T a) deriving (Eq) }}} results in a type error {{{ • No instance for (Eq (F a)) arising from the first field of ‘T2’ (type ‘T a’) }}} According the manual this is expected behaviour (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #inferred-context-for-deriving-clauses), but it is unfortunate; it seems to me that there is no deep reason that this instance should be rejected, other than an overly conservative check in the deriving machinery; I propose that this check is relaxed when the `UndecidableInstances` extension is enabled. Mind that I'm ''not'' proposing that it should also be able to infer the right constraints for `T` itself; but once I write such an explicit context myself once (for `T`), it seems to me that deriving the ''same'' constraints also for `T2` should be easy. Note that right now we can work-around this problem using {{{#!hs class Eq (F a) => EqF a deriving instance EqF a => Eq (T a) data T2 a = T2 (T a) deriving (Eq) }}} Normally however for such a class synonym we would then provide a single "authoritative" instance: {{{#!hs class Eq (F a) => EqF a instance Eq (F a) => EqF a }}} but if we do that then we are back at the same error for `T2`, because ghc will go from the `EqF a` constraint to the `Eq (F a)` constraint, and then refuse to add that constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 13:14:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 13:14:26 -0000 Subject: [GHC] #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled In-Reply-To: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> References: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> Message-ID: <059.f43b8592c27cdd8eca56535e49c70357@haskell.org> #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 13:48:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 13:48:36 -0000 Subject: [GHC] #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled In-Reply-To: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> References: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> Message-ID: <059.0a635584e20d2f6065be93dc80f1b50f@haskell.org> #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 14:13:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 14:13:20 -0000 Subject: [GHC] #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them In-Reply-To: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> References: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> Message-ID: <059.ecfba68f8d5a153f31d7892c4f91e0db@haskell.org> #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14822, #15635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Bj0rn): * related: #14822 => #14822, #15635 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 14:19:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 14:19:15 -0000 Subject: [GHC] #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them In-Reply-To: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> References: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> Message-ID: <059.8e5772703567183cf01b037ea81c9864@haskell.org> #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14822, #15635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bj0rn): #15635 Describes the same problem, perhaps in a clearer way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 15:59:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 15:59:54 -0000 Subject: [GHC] #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them In-Reply-To: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> References: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> Message-ID: <059.a4fed46bcca8faaebed982350a7f6f6e@haskell.org> #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14822, #15635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bj0rn): Here's a motivating example where I wish that I was able to show the compiler that one (quantified) constraint implies another. In this example, I'm using the `singletons` library. The `Data.Singletons.TypeLits` module contains {{{#!hs data instance Sing (n :: Nat) = KnownNat n => SNat instance KnownNat n => SingI n where sing = SNat }}} where the compiler learns of the implication `forall n. KnownNat n => SingI n`. However the reverse implication `forall n. SingI n => KnownNat n` is also true as evidenced by: {{{#!hs data Dict :: Constraint -> Type where Dict :: c => Dict c singIToKnownNat :: forall n. SingI n => Dict (KnownNat n) singIToKnownNat = case sing @n of SNat -> Dict }}} The crux is that there's is no way to rephrase `singIToKnownNat` in terms of constraint implication: {{{#!hs singIImpliesKnownNat :: forall r. ((forall n. SingI n => KnownNat n) => r) -> r singIImpliesKnownNat a = undefined -- Can't implement this? }}} What this ticket asks for is some way to write a correct definition of things like `singIImpliesKnownNat`. Something similar to the definition of `singIToKnownNat`, I would imagine. Here's the full example code: {{{#!hs -- GHC 8.6.2, Singletons 2.5 {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE QuantifiedConstraints #-} module ReifyImplications where import Data.Kind import GHC.TypeNats import Data.Singletons import Data.Singletons.TypeLits import Data.Type.Equality data EmptyVec :: Nat -> Type where EmptyVec :: EmptyVec 0 instance KnownNat n => Read (EmptyVec n) where readsPrec _ "EmptyVec" = case sameNat @n @0 Proxy Proxy of Just Refl -> [(EmptyVec, "")] Nothing -> [] data Some1 :: (k -> Type) -> Type where Some1 :: Sing a -> f a -> Some1 f readKnowingTypeIndex :: forall k (f :: k -> Type). (forall x. SingI x => Read (f x)) => SomeSing k -> String -> Some1 f readKnowingTypeIndex (SomeSing s) str = Some1 s $ withSingI s $ read str readKnowingNat :: forall (f :: Nat -> Type). (forall n. KnownNat n => Read (f n)) => SomeSing Nat -> String -> Some1 f readKnowingNat (SomeSing (SNat :: Sing a)) str = Some1 (SNat @a) $ read str -- Can't write this in terms of readKnowingTypeIndex? ev :: SomeSing Nat -> Some1 EmptyVec --ev s = readKnowingTypeIndex s "EmptyVec" -- Could not deduce (KnownNat x). --ev s = readKnowingNat s "EmptyVec" -- OK, but this doesn't work on every kind. Only Nat. singIImpliesKnownNat :: forall r. ((forall n. SingI n => KnownNat n) => r) -> r singIImpliesKnownNat a = undefined -- Can't implement this? ev s = singIImpliesKnownNat $ readKnowingTypeIndex s "EmptyVec" -- OK, if singIImpliesKnownNat was real. -- Now, this is easy to implement. But it's not practically usable in the definition of `ev`. data Dict :: Constraint -> Type where Dict :: c => Dict c singIToKnownNat :: forall n. SingI n => Dict (KnownNat n) singIToKnownNat = case sing @n of SNat -> Dict -- Bonus: readKnowingNat written in terms of readKnowingTypeIndex readKnowingNat' :: forall (f :: Nat -> Type). (forall n. KnownNat n => Read (f n)) => SomeSing Nat -> String -> Some1 f readKnowingNat' s str = singIImpliesKnownNat $ readKnowingTypeIndex s str }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 16:04:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 16:04:08 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family Message-ID: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind type KindOf1 (a :: k) = k type family KindOf2 (a :: k) :: Type where KindOf2 (a :: k) = k data A (a :: Type) :: a -> Type type family Apply1 (f :: KindOf1 A) (a :: Type) (x :: a) :: Type where Apply1 f a x = f a x }}} `Apply1` kind-checks, which is just peachy. Note that `Apply1` uses `KindOf1`, which is a type synonym. Suppose I wanted to swap out `KindOf1` for `KindOf2`, which is (seemingly) an equivalent type family. I can define this: {{{#!hs type family Apply2 (f :: KindOf2 A) -- (f :: forall a -> a -> Type) (a :: Type) (x :: a) :: Type where Apply2 f a x = f a x }}} However, GHC rejects this! {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:25:10: error: • Expecting two more arguments to ‘f’ Expected kind ‘KindOf2 A’, but ‘f’ has kind ‘* -> a -> *’ • In the first argument of ‘Apply2’, namely ‘f’ In the type family declaration for ‘Apply2’ | 25 | Apply2 f a x = f a x | ^ }}} I find this quite surprising, since I would have expected `KindOf1` and `KindOf2` to be functionally equivalent. Even providing explicit `forall`s does not make it kind-check: {{{#!hs type family Apply2 (f :: KindOf2 A) -- (f :: forall a -> a -> Type) (a :: Type) (x :: a) :: Type where forall (f :: KindOf2 A) (a :: Type) (x :: a). Apply2 f a x = f a x }}} Although the error message does change a bit: {{{ $ ~/Software/ghc3/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:26:20: error: • Expected kind ‘* -> a -> *’, but ‘f’ has kind ‘KindOf2 A’ • In the type ‘f a x’ In the type family declaration for ‘Apply2’ | 26 | Apply2 f a x = f a x | ^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 16:10:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 16:10:03 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family In-Reply-To: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> References: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> Message-ID: <065.8f14c84309e913bbed0fc08321435f52@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This isn't the only discrepancy I've encountered (although this is the most prominent example that I've uncovered). Another, slightly more minor discrepancy can be found in this program: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wall -fprint-explicit-foralls #-} module Bug where import Data.Kind type KindOf1 (a :: k) = k type family KindOf2 (a :: k) :: Type where KindOf2 (a :: k) = k data A (a :: Type) :: a -> Type f :: KindOf1 A f = undefined g = f h = g }}} Compiling this yields the following warnings: {{{ $ /opt/ghc/8.6.2/bin/ghci Bug.hs GHCi, version 8.6.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:19:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: g :: forall {a}. a -> * | 19 | g = f | ^ Bug.hs:20:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: h :: forall {a}. a -> * | 20 | h = g | ^ }}} Note the inferred type signatures for `g` and `h` (Side note: it's a bit weird that their inferred types are `forall {a}. a -> *` and not, say, `forall a -> a -> *`. But that's not the main issue here.) Now, if you redefine `f` to use `KindOf2` in its type signature: {{{#!hs f :: KindOf2 A f = undefined }}} Recompiling the module will instead yield these warnings: {{{ $ /opt/ghc/8.6.2/bin/ghci Bug.hs GHCi, version 8.6.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:19:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: g :: forall a -> a -> * | 19 | g = f | ^ Bug.hs:20:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: h :: forall {a}. a -> * | 20 | h = g | ^ }}} Notice that the inferred type of `g` is now `forall a -> a -> *`, whereas before it was `forall {a}. a -> *`! Quite strange. (And to make things stranger, the inferred type of `h` is different from that of `g`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 16:27:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 16:27:15 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family In-Reply-To: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> References: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> Message-ID: <065.2a12a7bb5d70b6f676b708533edfdcbe@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Lots of bugs here! 1. I would expect `Apply1` to be rejected without an explicit `forall` in the equation, giving the polytype of `f`. 2. The error message for `Apply2` shouldn't say that it expects for arguments to `f`. The rest of the error message is perhaps confusing, but it's not unreasonable. 3. The version of `Apply2` with the explicit `forall` in the equation should be accepted. 4. In the `g` and `h` with `KindOf1`: Their types should be `forall a -> a -> Type`, not what GHC is reporting. 5. Ditto for `h` in the `KindOf2` case. Note that the inferred nature (as opposed to specified) of `a` is a non- bug: when you don't write a type signature, you don't get specified variables. But of course these should be required, not invisible or specified. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:05:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:05:21 -0000 Subject: [GHC] #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them In-Reply-To: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> References: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> Message-ID: <059.a263b87a63cf77eeef71123d363e4045@haskell.org> #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14822, #15635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bj0rn): I end up wishing that I could put myself in some sort of context where I claim that "`n` could be anything, and suppose we have `SingI n`", so that I'm allowed to call `singIToKnownNat @n`. In this context, the fact that we're able to produce a `Dict (KnownNat n)`, should prove to the compiler that `forall n. SingI n => KnownNat n`. The expression that you provide in this context would get implicitly pattern matched, in order to learn the constraints that can result from the assumption made in the context. The compiler concludes that the assumed constraint implies the constraints found by the implicit pattern match. I'll make up some syntax for this. Imagine a `suppose ... in ...` keyword: {{{#!hs ev :: SomeSing Nat -> Some1 EmptyVec ev s = suppose forall (n :: Nat). SingI n => singIToKnownNat @n in readKnowingTypeIndex s "EmptyVec" }}} It's a funny mix of type level and expression level syntax. `singIToKnownNat @n` soundly returns a `Dict (KnownNat n)`, and pattern matching on the resulting `Dict` constructor would make us learn that for all `n`, `SingI n` (from the `suppose` context) implies `KnownNat n`. In fact this has nothing to do with `Dict`. The following would work equally well: {{{#!hs ev :: SomeSing Nat -> Some1 EmptyVec ev s = suppose forall (n :: Nat). SingI n => sing @n in readKnowingTypeIndex s "EmptyVec" }}} since, after all, `sing @n` returns an `SNat :: Sing n`, which when pattern matched brings `KnownNat n` into scope. I don't mean to pollute language syntax. If there's a way to avoid new syntax, like a magical built-in function, that's preferable. It also has to be able to quantify over various numbers of type variables, so I don't think the built-in function that I proposed in the description would even work in this practical case. I'm a bit curious. When I try to write {{{#!hs suppose1 :: forall a b r. (forall x. a x => Dict (b x)) -> ((forall x. a x => b x) => r) -> r suppose1 Dict a = a }}} GHC complains already on the type signature: `Could not deduce: b x`. What's going on there? I wouldn't be surprised if it's already possible today to write something magical using unsafeCoerce that works for specific cases, in the style of Edward Kmett's `reflection` package. But that's not a long-term solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:07:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:07:58 -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.7a5cd69346f608506fc71bca0bb64743@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.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: | Phab:D5059 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"932cd41d8c7984c767c1b3b58e05146f69cc5c15/ghc" 932cd41d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="932cd41d8c7984c767c1b3b58e05146f69cc5c15" testsuite: Save performance metrics in git notes. This patch makes the following improvement: - Automatically records test metrics (per test environment) so that the programmer need not supply nor update expected values in *.T files. - On expected metric changes, the programmer need only indicate the direction of change in the git commit message. - Provides a simple python tool "perf_notes.py" to compare metrics over time. Issues: - Using just the previous commit allows performance to drift with each commit. - Currently we allow drift as we have a preference for minimizing false positives. - Some possible alternatives include: - Use metrics from a fixed commit per test: the last commit that allowed a change in performance (else the oldest metric) - Or use some sort of aggregate since the last commit that allowed a change in performance (else all available metrics) - These alternatives may result in a performance issue (with the test driver) having to heavily search git commits/notes. - Run locally, performance tests will trivially pass unless the tests were run locally on the previous commit. This is often not the case e.g. after pulling recent changes. Previously, *.T files contain statements such as: ``` stats_num_field('peak_megabytes_allocated', (2, 1)) compiler_stats_num_field('bytes allocated', [(wordsize(64), 165890392, 10)]) ``` This required the programmer to give the expected values and a tolerance deviation (percentage). With this patch, the above statements are replaced with: ``` collect_stats('peak_megabytes_allocated', 5) collect_compiler_stats('bytes allocated', 10) ``` So that programmer must only enter which metrics to test and a tolerance deviation. No expected value is required. CircleCI will then run the tests per test environment and record the metrics to a git note for that commit and push them to the git.haskell.org ghc repo. Metrics will be compared to the previous commit. If they are different by the tolerance deviation from the *.T file, then the corresponding test will fail. By adding to the git commit message e.g. ``` # Metric (In|De)crease : Metric Increase ['bytes allocated', 'peak_megabytes_allocated'] \ (test_env='linux_x86', way='default'): Test012, Test345 Metric Decrease 'bytes allocated': Test678 Metric Increase: Test711 ``` This will allow the noted changes (letting the test pass). Note that by omitting metrics or options, the change will apply to all possible metrics/options (i.e. in the above, an increase for all metrics in all test environments is allowed for Test711) phabricator will use the message in the description Reviewers: bgamari, hvr Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #12758 Differential Revision: https://phabricator.haskell.org/D5059 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:10:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:10:33 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.0d149af3642481c12fa00cf9f077153a@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, the situation in comment:4 in which a visible, dependent kind is erroneously flagged as ambiguous can occur //today//, even without that patch. Take this program, for example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind type KindOf (a :: k) = k type family F a data A (a :: Type) :: F a -> Type data Ex (x :: KindOf A) }}} {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:13:1: error: • Couldn't match type ‘F a’ with ‘F a0’ Expected type: F a -> * Actual type: F a0 -> * NB: ‘F’ is a non-injective type family The type variable ‘a0’ is ambiguous • In the ambiguity check for the kind annotation on the type variable ‘x’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes | 13 | data Ex (x :: KindOf A) | ^^^^^^^^^^^^^^^^^^^^^^^ }}} I believe this should be accepted since `KindOf A` reduces to `forall a -> F a -> Type`, and the `forall a ->` //should// uniquely determine the `a` in `F a`. Alas, GHC doesn't currently recognize this. Thankfully, the workaround for the time being is simple: just enable `AllowAmbiguousTypes`. But I'll go ahead and post this here to make it clear that this is a problem in the present, and not just a problem for a future GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:20:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:20:25 -0000 Subject: [GHC] #15870: No skolem info panic Message-ID: <044.4ebde572f532e7733582e43832fd0055@haskell.org> #15870: No skolem info panic -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 (Type checker) | 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've been toying with some type-level lenses and running into some issues with kind unification, when I ran into a panic: {{{ bug.hs:30:34: error:ghc.exe: panic! (the 'impossible' happened) (GHC version 8.6.2 for x86_64-unknown-mingw32): No skolem info: [k_a1Hgj] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler\\typecheck\\TcErrors.hs:2891:5 in ghc:TcErrors }}} Here's a boiled down version (with a bit of extraneous code left in for context, as it's so short): {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} data Optic a where --Index :: Nat -> Optic a --Name :: Symbol -> Optic a (:.:) :: Optic a -> Optic b -> Optic a -- composition class Gettable a (optic :: Optic a) where type Get a (optic :: Optic a) {- some basic instances, e.g. instance Gettable (a,b) (Index 0) where type Get (a,b) (Index 0) = a ... -} instance forall a b (g1 :: Optic a) (g2 :: Optic b). ( Gettable a g1 , b ~ Get a g1 , Gettable b g2 ) => Gettable a (g1 :.: g2) where type Get a (g1 :.: g2) = Get a g2 }}} The program I am actually trying to write has the instance declaration changed to {{{#!hs instance forall a b (g1 :: Optic a) (g2 :: Optic (Get a g1)). ( Gettable a g1 , b ~ Get a g1 , Gettable b g2 ) => Gettable a (g1 :.: g2) where type Get a (g1 :.: g2) = Get (Get a g1) g2 }}} but GHC complains that it can't match kinds: {{{ • Expected kind ‘Optic b’, but ‘g2’ has kind ‘Optic (Get a g1)’ • In the second argument of ‘Gettable’, namely ‘g2’ In the instance declaration for ‘Gettable a (g1 :.: g2)’ | 20 | , Gettable b g2 | }}} I don't know if there is a way around that, and I'd be interested to hear any advice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:22:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:22:35 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.1f30caae7f040e14c8f55d7c6472ae0f@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): We have no business at all running today's type-oriented ambiguity check on kinds, as they have different subtyping relations. So we have task 3. Make sure not to ever run the type-ambiguity check on kinds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:23:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:23:16 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.2536c1bce0322c6c5591d83a63990e34@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by goldfire: Old description: > GHC does an ambiguity check on types. It should also do the same for > kinds. Here is a program that should be rejected: > > {{{#!hs > type family F a > data T :: F a -> Type > }}} > > `T`'s kind is ambiguous, and any occurrence of `T` will be rejected. > Instead of rejecting usage sites, let's just reject the definition site. > > This check would be disabled by `AllowAmbiguousTypes`. > > Happily, I think the implementation should be easy, and that the current > algorithm to check for ambiguous types should work for kinds, too. After > all, types and kinds are the same these days. > > This was inspired by #14203, but no need to read that ticket to > understand this one. New description: GHC does an ambiguity check on types. It should also do the same for kinds. Here is a program that should be rejected: {{{#!hs type family F a data T :: F a -> Type }}} `T`'s kind is ambiguous, and any occurrence of `T` will be rejected. Instead of rejecting usage sites, let's just reject the definition site. This check would be disabled by `AllowAmbiguousTypes`. Happily, I think the implementation should be easy, and that the current algorithm to check for ambiguous types should work for kinds, too. After all, types and kinds are the same these days. This was inspired by #14203, but no need to read that ticket to understand this one. EDIT: See comment:8 and comment:10 for the nub of what needs to be done here. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:26:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:26:11 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.a4fbf6a882d39b69cd4618819e806fef@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Make sure not to ever run the type-ambiguity check on kinds. Do we need to do anything else instead? Or are you saying simply drop it. And if so why do the ills of ambiguous types not apply to kinds? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:28:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:28:50 -0000 Subject: [GHC] #15871: Revamp -fprint-explicit-kinds Message-ID: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> #15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- With the imminent #12045, we will have type application in kinds. This ticket tracks mirroring this new behavior in the pretty-printer. To wit, when `-fprint-explicit-kinds` is enabled, we should 1. Print instantiations of specified variables like `@...`. 2. Print instantiations of inferred variables like `@{...}`. Examples: {{{#!hs data Proxy (a :: k) = Proxy -- Then, `Proxy Int` would be printed as `Proxy @Type Int` with -fprint- explicit-kinds data Proxy2 a = Proxy2 -- Then, `Proxy2 Int` would be printed as `Proxy2 @{Type} Int` with -fprint-explicit-kinds }}} In addition, sometimes error messages suggest enabling `-fprint-explicit- kinds`. Instead of doing this, we should just locally enable the flag. The existence of the `@` prefixes will alert the reader that these are not type arguments. (Without the `@` syntax, locally and silently enabling `-fprint-explicit-kinds` would be very confusing.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:31:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:31:13 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.bbd367cf6319f1c0a6bb4e884b6be74f@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): We ''do'' need an ambiguity check on kinds, but that's already accounted- for in task 2 in comment:8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:47:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:47:55 -0000 Subject: [GHC] #15870: No skolem info panic In-Reply-To: <044.4ebde572f532e7733582e43832fd0055@haskell.org> References: <044.4ebde572f532e7733582e43832fd0055@haskell.org> Message-ID: <059.06e520dc6a2dcd0cab114add39a1445d@haskell.org> #15870: No skolem info panic -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | 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): * priority: normal => highest * milestone: => 8.6.3 Comment: First, this appears to be a regression from GHC 8.4, which simply gives an error message: {{{ $ /opt/ghc/8.4.4/bin/ghci Bug.hs -XTypeInType GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:30:34: error: • Expected kind ‘Optic a’, but ‘g2’ has kind ‘Optic b’ • In the second argument of ‘Get’, namely ‘g2’ In the type ‘Get a g2’ In the type instance declaration for ‘Get’ | 30 | type Get a (g1 :.: g2) = Get a g2 | ^^ }}} So that's not good. I'll mark this as highest priority as a result. Second, the error message: {{{ • Expected kind ‘Optic b’, but ‘g2’ has kind ‘Optic (Get a g1)’ • In the second argument of ‘Gettable’, namely ‘g2’ In the instance declaration for ‘Gettable a (g1 :.: g2)’ | 20 | , Gettable b g2 | }}} Is actually expected behavior (at least, at the moment). Even though you've written `b ~ Get a g1`, GHC isn't able to make use of this fact at the type level yet. See #12677/#15710 for the tickets tracking this infelicity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:51:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:51:44 -0000 Subject: [GHC] #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) Message-ID: <051.a307612084bbe4f5b88300af043b1425@haskell.org> #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Maybe indicative of deeper issues: {{{#!hs {-# Language RankNTypes #-} {-# Language DataKinds #-} {-# Language PolyKinds #-} {-# Language GADTs #-} import Data.Kind data WHICH = OP | OPOP data Fun :: forall (a :: WHICH). a ~ OP => Type -> Type -> Type where MkFun :: (a -> b) -> Fun a b }}} There are some artifacts `Fun ('GHC.Type.Eq# <>)` in the type of `MkFun` that shouldn't be there {{{ $ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot- ghci ~/hs/655_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /home/baldur/hs/655_bug.hs, interpreted ) Ok, one module loaded. *Main> :t MkFun MkFun :: (a -> b) -> Fun ('GHC.Types.Eq# <>) a b *Main> :k Fun Fun :: (a ~ 'OP) => * -> * -> * *Main> }}} ---- Tangent: Omitting `{-# Language GADTs #-}` we get the term "equational constraint" which is not the term I have seen in the wild {{{ $ latestbug 655_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 655_bug.hs, interpreted ) 655_bug.hs:9:1: error: Illegal equational constraint a ~ 'OP (Use GADTs or TypeFamilies to permit this) | 9 | data Fun :: forall (a :: WHICH). a ~ OP => Type -> Type -> Type where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Failed, no modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:55:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:55:27 -0000 Subject: [GHC] #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled In-Reply-To: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> References: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> Message-ID: <059.a3e5f40951de10b655bcc8ded5099ff4@haskell.org> #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving Comment: I have mixed feelings on this. I'm reluctant to turn off this validity check entirely when `UndecidableInstances` is enabled since there are several situations where this can catch you when you're writing utterly bogus programs, such as this one: {{{#!hs data NotAShowInstance data Foo = MkFoo Int NotAShowInstance deriving Show }}} {{{ Bug.hs:2:48: error: • No instance for (Show NotAShowInstance) arising from the second field of ‘MkFoo’ (type ‘NotAShowInstance’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Show Foo) | 2 | data Foo = MkFoo Int NotAShowInstance deriving Show | ^^^^ }}} This is a relatively common mistake to make, and it's one that's caught by this validity check. If this check were relaxed, then GHC would generate this instance: {{{#!hs instance Show NotAShowInstance => Show Foo where ... }}} Which is almost surely //not// what you'd want. At the same time, I can certainly understand wanting to relax this restriction when type families or fancy types (e.g., `Show (f a b (g a b) (h a b))`) get involved. Perhaps there's a way to write up a specification that permits `T2` in your example but rejects `Foo` in my example. I'm not sure what such a specification would be yet, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:56:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:56:32 -0000 Subject: [GHC] #11008: Difficulties around inferring exotic contexts In-Reply-To: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> References: <047.f8044d540a2a7870b6d80881b5244312@haskell.org> Message-ID: <062.9a7a6e64f63c741660dabdd2b11b72c8@haskell.org> #11008: Difficulties around inferring exotic contexts -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15868 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving * related: => #15868 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 17:56:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 17:56:57 -0000 Subject: [GHC] #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled In-Reply-To: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> References: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> Message-ID: <059.38cf4f80115e1d5698edd5f40102d62a@haskell.org> #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11008 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11008 Comment: #11008 is a similar ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 18:23:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 18:23:55 -0000 Subject: [GHC] #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) In-Reply-To: <051.a307612084bbe4f5b88300af043b1425@haskell.org> References: <051.a307612084bbe4f5b88300af043b1425@haskell.org> Message-ID: <066.312b3fbf2e2360469b5b9c838e6790ee@haskell.org> #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeInType 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 goldfire): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 18:25:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 18:25:13 -0000 Subject: [GHC] #15710: Should GHC accept a type signature that needs coercion quantification? In-Reply-To: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> References: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> Message-ID: <061.dc9b6cdcfa60f811f7e07ec24245f691@haskell.org> #15710: Should GHC accept a type signature that needs coercion quantification? -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12677 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): #15870 is an example of someone actually trying this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 18:31:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 18:31:53 -0000 Subject: [GHC] #15856: GhostScript not available for hp2ps tests In-Reply-To: <042.38af0a545c08ca985911b262b0de4318@haskell.org> References: <042.38af0a545c08ca985911b262b0de4318@haskell.org> Message-ID: <057.c224a5720c7b2b5bb77ba37246baad79@haskell.org> #15856: GhostScript not available for hp2ps tests -------------------------------------+------------------------------------- Reporter: jrp | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: ghostscript | gs hp2ps testsuite Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T7919 T14761c Blocked By: | Blocking: Related Tickets: #15736 | Differential Rev(s): Phab:D5298 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): OK. Got that: {{{ "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE "/..../ghc/testsuite/config/good.ps" "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE "/..../ghc/testsuite/config/bad.ps" >/dev/null 2>&1 GhostScript available for hp2ps tests }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 18:33:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 18:33:44 -0000 Subject: [GHC] #13933: Support Typeable instances for types with coercions In-Reply-To: <047.2f51ec97795d85d670d1916471772452@haskell.org> References: <047.2f51ec97795d85d670d1916471772452@haskell.org> Message-ID: <062.527b0f4d3b67a62017969f6b30b0622d@haskell.org> #13933: Support Typeable instances for types with coercions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeInType, | Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13872, #15872 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13872 => #13872, #15872 Comment: See #15872 for a standalone ticket about the pretty-printing issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 18:34:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 18:34:17 -0000 Subject: [GHC] #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) In-Reply-To: <051.a307612084bbe4f5b88300af043b1425@haskell.org> References: <051.a307612084bbe4f5b88300af043b1425@haskell.org> Message-ID: <066.e43af3b0db5e77afb409b938a3d0dcd6@haskell.org> #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13933 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13933 Comment: See #13933 for another way to trigger the pretty-printing oddities uncovered here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 19:13:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 19:13:21 -0000 Subject: [GHC] #4020: Please consider adding support for local type synonyms In-Reply-To: <041.4d1fc687182926effba30be48457cbb9@haskell.org> References: <041.4d1fc687182926effba30be48457cbb9@haskell.org> Message-ID: <056.9d69bf553f94c7f9fc0bcdeaa0b5daca@haskell.org> #4020: Please consider adding support for local type synonyms -------------------------------------+------------------------------------- Reporter: nr | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 6.12.2 checker) | Resolution: | Keywords: type synonym Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andreas.abel): I just tried to declare a `type` synonym in a `where` clause and was surprised that there is no GHC extension enabling this. Rationale: If the type abbreviation is only used to simply type- signatures of local functions, it should not have to be lifted to the top- level. See the Agda language why there is in principle no problem with having local type definitions. In the worst case, the type definition will not be in scope when trying to print it, but this problem already exists for type synoyms that are not in scope because they have not been imported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 20:38:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 20:38:16 -0000 Subject: [GHC] #15870: No skolem info panic In-Reply-To: <044.4ebde572f532e7733582e43832fd0055@haskell.org> References: <044.4ebde572f532e7733582e43832fd0055@haskell.org> Message-ID: <059.237dac7209b3d3f18fc6906305ac76e4@haskell.org> #15870: No skolem info panic -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | 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 RyanGlScott): The regression was introduced in commit faec8d358985e5d0bf363bd96f23fe76c9e281f7 (`Track type variable scope more carefully.`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 20:40:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 20:40:34 -0000 Subject: [GHC] #15873: move to llvm 7 for 8.8.1 Message-ID: <045.eb24c323c15fc6ee3b2438976dc5b650@haskell.org> #15873: move to llvm 7 for 8.8.1 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 Wed Nov 7 20:43:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 20:43:00 -0000 Subject: [GHC] #15611: scope errors lie about what modules are imported In-Reply-To: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> References: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> Message-ID: <059.43fa64bad491b73802fcc7f433b70d9f@haskell.org> #15611: scope errors lie about what modules are imported -------------------------------------+------------------------------------- Reporter: dmwit | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST="T15611a T15611b" Blocked By: | Blocking: Related Tickets: #14225 | Differential Rev(s): Phab:D5284 Wiki Page: | Phab:D5308 -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * differential: Phab:D5284 => Phab:D5284 Phab:D5308 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 20:50:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 20:50:15 -0000 Subject: [GHC] #15874: Data families with higher-rank kinds Message-ID: <051.72eddd9af5815eb989f802af554eb1bb@haskell.org> #15874: Data families with higher-rank kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes #-} {-# Language DataKinds #-} {-# Language PolyKinds #-} {-# Language GADTs #-} {-# Language TypeFamilies #-} import Data.Kind data Var where Op :: Var Id :: Var -- type family -- Flip (var :: Var) = (res :: Var) | res -> var where -- Flip Op = Id -- Flip Id = Op type Varianced = (forall (var :: Var). Type) -- data A :: Varianced where -- MkA :: Int -> A @Id -- data OpA :: Varianced where -- MkOpA :: Int -> OpA @Op -- data Exp :: Varianced -> Varianced where -- X :: forall (ext::Varianced) (var :: Var). Exp ext @var -- OpExp1 :: forall (var :: Varianced). var @op -> Exp var @(Flip op) data family Parser :: Varianced data instance Parser = P }}} {{{ $ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot- ghci 656.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 656.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181029 for x86_64-unknown-linux): ASSERT failed! kind axiom D:R:Parservar0 :: Parser = R:Parservar -- Defined at 656.hs:31:15 forall (var :: Var). * Var -> * Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/FamInst.hs:158:61 in ghc:FamInst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 21:10:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 21:10:22 -0000 Subject: [GHC] #15874: Data families with higher-rank kinds In-Reply-To: <051.72eddd9af5815eb989f802af554eb1bb@haskell.org> References: <051.72eddd9af5815eb989f802af554eb1bb@haskell.org> Message-ID: <066.68fea68a57a67d47a986d39ec8fdd5a9@haskell.org> #15874: Data families with higher-rank kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 goldfire): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 22:45:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 22:45:01 -0000 Subject: [GHC] #15870: No skolem info panic In-Reply-To: <044.4ebde572f532e7733582e43832fd0055@haskell.org> References: <044.4ebde572f532e7733582e43832fd0055@haskell.org> Message-ID: <059.9cea166aa0dca208d4600f51763aa232@haskell.org> #15870: No skolem info panic -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | 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): I know why the crash happens. * In the instance decl we bring into scope the skolems of the instance * Then, we process the local family instance equation. In doing so we call the dreaded `tcFamTyPats` -- and it calls `solveEqualities` (wrongly I believe) * This `solveEqualities` tries to report an error; but it can't see the skolems, hence the panic. Really `solveEqualities` should only be called in an empty type environment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 22:47:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 22:47:37 -0000 Subject: [GHC] #15871: Revamp -fprint-explicit-kinds In-Reply-To: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> References: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> Message-ID: <062.66e7b2008b140a6e90e753f59c2da848@haskell.org> #15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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): Yes! Let's do it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 23:14:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 23:14:01 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.b033505cc8994e74db464a7e7e733679@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: sgraf (added) Comment: Sebastian, would you feel up to looking into this? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 23:14:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 23:14:58 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.3db906b28462591a211897c99d8efe3d@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: CodeGen 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: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 7 23:17:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Nov 2018 23:17:06 -0000 Subject: [GHC] #15862: Typeable panic with promoted rank-2 kind (initDs) In-Reply-To: <050.a59278de72961367e1dea424ce2860fa@haskell.org> References: <050.a59278de72961367e1dea424ce2860fa@haskell.org> Message-ID: <065.d97f67decb902af4595db2c82dce3daa@haskell.org> #15862: Typeable panic with promoted rank-2 kind (initDs) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Typeable, | ImpredicativeTypes 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 simonpj): * keywords: Typeable => Typeable, ImpredicativeTypes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 02:01:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 02:01:24 -0000 Subject: [GHC] #15875: Detection of ranlib by binary distribution is broken Message-ID: <046.b6e27acc1336ece3a6d2d7b8c747c824@haskell.org> #15875: Detection of ranlib by binary distribution is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 `configure` shipped with binary distributions fails to set `RanlibCmd` which therefore means that we end up installing `settings` with an empty `ranlib command` configuration field. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 03:58:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 03:58:37 -0000 Subject: [GHC] #15769: GHC 8.6 for macOS depends on homebrew In-Reply-To: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> References: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> Message-ID: <067.2c29f21dfa292ab1fa9a9247a61380fa@haskell.org> #15769: GHC 8.6 for macOS depends on homebrew -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kazu-yamamoto): I would like to suggest to ship GHC 8.6.3 with integer-simple for macOS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 09:32:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 09:32:32 -0000 Subject: [GHC] #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them In-Reply-To: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> References: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> Message-ID: <059.4bf4601b4f85c07cf767bbeb9f8692ee@haskell.org> #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14822, #15635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bj0rn): I just realized that the "implicit pattern match" is nonsense, as it's not indicated at compile time which constructor the pattern match resulted in. So something more like: {{{#!hs ev :: SomeSing Nat -> Some1 EmptyVec ev s = case forall (n :: Nat). SingI n => singIToKnownNat @n of Dict -> readKnowingTypeIndex s "EmptyVec" }}} Also makes it clear that the expression is being evaluated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 12:10:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 12:10:21 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.20518eb4d522cd835c8b5d3c98875a70@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: CodeGen 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): * owner: (none) => sgraf Comment: Sure will do! I could reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 12:24:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 12:24:54 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.d74803119701a2329e860d2d12174717@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: CodeGen Operating System: 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): The `Void# is redefined` errors are related to shadowing. As you pointed out, that's a little too strict. The other errors, due to duplicated occs, are more concerning. This happens after unarisation. This is the offending STG before unarise: {{{ case GHC.Integer.Type.quotRemInteger n_sf5G d_sf5H of qr_sf5I [Occ=Once] { (#,#) ipv_sf5J [Occ=Once] ipv1_sf5K -> let-no-escape { $j3_sf5L [Occ=Once*!T[1], Dmd=] :: GHC.Prim.Int# -> (# GHC.Integer.Type.Integer, GHC.Integer.Type.Integer #) [LclId[JoinId(1)], Arity=1, Str=, Unf=OtherCon []] = sat-only [d_sf5H qr_sf5I ipv_sf5J ipv1_sf5K] \r [wild_sf5M] -> ... }}} Unarise splits the occurrence of `qr_sf5I` into its constituents `ipv_sf5J` and `ipv1_sf5K` without looking for duplicates: {{{ case quotRemInteger n_sf5G d_sf5H of qr_sf5I [Occ=Once] { (#,#) ipv_sf5J [Occ=Once] ipv1_sf5K -> let-no-escape { $j3_sf5L [Occ=Once*!T[1], Dmd=] :: Int# -> (# Integer, Integer #) [LclId[JoinId(1)], Arity=1, Str=, Unf=OtherCon []] = sat-only [d_sf5H ipv_sf5J ipv1_sf5K ipv_sf5J ipv1_sf5K] \r [wild_sf5M] ... }}} Let's see where... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 12:49:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 12:49:18 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.469325bf74d0a2ab648552036f84da27@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5310 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => patch * differential: => Phab:D5310 Comment: Fixed this with a tiny patch in Phab:D5310 by a call to `nub` in `unariseFreeVars`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 13:01:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 13:01:21 -0000 Subject: [GHC] #15876: Function versioning instead of compilation flags... Message-ID: <050.687e46bbf749169d23d59f0ecea89286@haskell.org> #15876: Function versioning instead of compilation flags... -------------------------------------+------------------------------------- Reporter: MichalGajda | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (Linking) | Keywords: simd, | Operating System: Unknown/Multiple flavors, speed | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Wanting to take advantage of SIMD, we need to compile a different implementation of certain core libraries functions (like `ByteString` c_memchr to make it 16x faster). This would require recompiling most of the libraries for new flags. Instead, it would be much simpler to add function versioning a la GCC: https://lwn.net/Articles/691932/ This would allow us to write code like this: {-# target(avx512) #-} c_memchr = ...SIMD code... {-# !target(avx512) #-} c_memchr = ...current code... We currently use special libraries for these kind of speedups, but it would be much better to use SIMD across few key functions in all libraries to get 16x speedups across the board (`c_memchr` for parsing.) Ideally we could also use it to remove some of _flavoring_ in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 13:04:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 13:04:45 -0000 Subject: [GHC] #15877: --flavour=quick followed by --flavour=prof fails Message-ID: <049.2c7f5c96cfaf8ffe2a60dc4dc965d33c@haskell.org> #15877: --flavour=quick followed by --flavour=prof fails -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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: -------------------------------------+------------------------------------- Starting from a clean tree I first built successfully with `--flavour=quick`, I then changed to `--flavour=prof` and the build failed as follows: {{{ /root/ghc/_build/stage1/rts/build/libCffi_p.a: copyFile: does not exist (No such file or directory) shakeArgsWith 0.010s 0% Function shake 0.435s 0% Database read 0.670s 0% With database 0.035s 0% Running rules 123.401s 99% ========================= Total 124.551s 100% Error when running Shake build system: at src/Rules.hs:(32,19)-(45,17): at src/Rules.hs:45:5-17: * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf * Raised the exception: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 13:19:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 13:19:52 -0000 Subject: [GHC] #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled In-Reply-To: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> References: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> Message-ID: <059.170583fe0c7f9eabbb51fa5033fca160@haskell.org> #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11008 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Would simply refusing to add constraints without any type variables be sufficient to rule out examples like the one you are worried about? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 13:58:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 13:58:17 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.3c2044eb613b2c7405b1f63b8c3f042a@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5310 Wiki Page: | -------------------------------------+------------------------------------- Changes (by csabahruska): * Attachment "StgScopeCheck2.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 14:00:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 14:00:04 -0000 Subject: [GHC] #15878: Unused data type with a "deriving" clause is falsely considered used Message-ID: <048.4e0fbddff1e0925254814a03b6083867@haskell.org> #15878: Unused data type with a "deriving" clause is falsely considered used -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- module M () where data Foo = Bar deriving (Eq) If there are no explicit references to Foo and none to Bar, the data-type is necessarily unused, so I expect a warning about an unused data-type. Even if it is referenced, but only from instance declarations, it is necessarily unused in the program. One potential exception is functional dependencies, where the instance declaration itself has an effect. But even then, perhaps it is worth warning that the *type* is unused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 14:07:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 14:07:26 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.68f8c828ae66e483d50a981fc0d37522@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5310 Wiki Page: | -------------------------------------+------------------------------------- Comment (by csabahruska): I've improved the scope checking: - allows unique name shadowing (nested scopes) - checks OccName duplications only for exported top-level names - check Unique duplications for StgRhsClosure, StgRec, DataAlt I've attached the improved linter patch. (StgScopeCheck2.patch). It requires the `nub` fix. Using this improvements I've got new errors: {{{ buggy source: libraries/base/Data/Type/Equality.hs *** Stg Lint ErrMsgs: in Unarise *** : warning: [in body of lambda with binders void_0E :: Void#, void_0E :: Void#] void_0E :: Void# is duplicated (Uniq) *** Offending Program *** HRefl :: forall k2 k2 (a :: k2) (b :: k2). (k2 ~# k2) -> (b ~# a) -> a :~~: b [GblId[DataCon], Arity=2, Caf=NoCafRefs, Str=m, Unf=OtherCon []] = [] \r [void_0E void_0E] HRefl []; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 14:08:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 14:08:45 -0000 Subject: [GHC] #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled In-Reply-To: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> References: <044.46f83695133b124b8bb87b3c7eee5407@haskell.org> Message-ID: <059.3e36e90d702cf8a712ed8b82e0b5491e@haskell.org> #15868: Standard deriving should be less conservative when `UndecidableInstances` is enabled -------------------------------------+------------------------------------- Reporter: edsko | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11008 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:5 edsko]: > Would simply refusing to add constraints without any type variables be sufficient to rule out examples like the one you are worried about? Not necessarily. Imagine if `NotAShowInstance` had a type parameter, for instance. Under your proposed scheme, we'd still allow `data Foo a = MkFoo Int (NotAShowInstance a) deriving Show`. I think the right way to frame the discussion is to permit constraints that involve non–type constructors (such as type families or higher-kinded type variables) in certain ways. That's still not anything resembling a specification, but it's closer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 14:25:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 14:25:03 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.0359b387880058f9039ae84c93d196eb@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5310 Wiki Page: | -------------------------------------+------------------------------------- Comment (by csabahruska): Or do we want to accept this as some kind of name shadowing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 14:40:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 14:40:57 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.6cd71f2dbd0e300cb53c413576f933c1@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5310 Wiki Page: | -------------------------------------+------------------------------------- Comment (by csabahruska): Another one: `libraries/containers/Data/Sequence/Internal.hs` {{{ *** Stg Lint ErrMsgs: in StgCse *** : warning: [in body of lambda with binders eta2_s1rRb :: Int] n_s1rR0 :: (Seq a_afnp, Seq a_afnp) is duplicated (Uniq) *** Offending Program *** let { sat_s1rUG [Occ=OnceT[0]] :: Int -> (Seq a_afnp, Seq a_afnp) [LclId] = [n_s1rR0 wild_s1rR1 dt_s1rR4 n_s1rR0 lvl175_s1rR9 lvl176_s1rTS lvl177_s1rTT lvl178_s1rTU lvl179_s1rTV] \r [i_s1rTW] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 15:07:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 15:07:31 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.c3e8d5063019322dfe418852905e79b4@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5310 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Hmm. I'm inclined to accept the shadowing, it's like nested lambdas, after all. Also, since free var occurrences never were a problem before (presumably because `StgToCmm` nubs them anyway) and since there are plans in #15754 to get rid of that field altogether, I'm not sure if this really is a sensible thing to lint for. No doubt, the STG is extremely fishy, but if we are going to remove FV occs from `StgRhsClosure` anyway, I don't see great value in fixing these non-severe bugs. Simon is free to overrule me here, in which case I'd be happy to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 15:14:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 15:14:08 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.98323bc95c359ea779575ca2b808a05a@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5310 Wiki Page: | -------------------------------------+------------------------------------- Comment (by csabahruska): I did the linter to understand the semantics. Because it's clearly unintuitive with the unique name shadowing in the free var and binder list and in general. Anyway with this insight now I can write my STG to GRIN transformation. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 15:17:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 15:17:33 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.4f1d8286a5737756b20a6d681fcce7a7@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 #15867 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: #9718 => #9718 #15867 Comment: #15867 has shown that there are at least `StgUnarise` and `StgCse` that are a little careless wrt. duplicates in the FV list. So removing the field altogether makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 15:17:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 15:17:44 -0000 Subject: [GHC] #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) In-Reply-To: <051.a307612084bbe4f5b88300af043b1425@haskell.org> References: <051.a307612084bbe4f5b88300af043b1425@haskell.org> Message-ID: <066.0ba1918d378cd144d532d60ad785bb3a@haskell.org> #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13933 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I wonder if these `('GHC.Types.Eq# <>)` coercion arguments should just be suppressed by default unless `-fprint-explicit-coercions` is enabled? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 15:25:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 15:25:14 -0000 Subject: [GHC] #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) In-Reply-To: <047.806baf8de1314a2dee16052aba8af5c1@haskell.org> References: <047.806baf8de1314a2dee16052aba8af5c1@haskell.org> Message-ID: <062.12584f64508bae329d33d179b9cef867@haskell.org> #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: libraries | Version: 7.8.3 (other) | Resolution: fixed | Keywords: array Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5156 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 Comment: Fixed in http://git.haskell.org/packages/array.git/commit/28454638ca681c4625f7c2fcf127821399d9ded3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 15:38:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 15:38:22 -0000 Subject: [GHC] #14179: "Conflicting family instance" error pretty prints data family instances poorly In-Reply-To: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> References: <050.3b34f958a96d53100d1cde9c870ee0f4@haskell.org> Message-ID: <065.63013a087de8eca94f0271ff1e21ccb0@haskell.org> #14179: "Conflicting family instance" error pretty prints data family instances poorly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: indexed- error message | types/should_fail/T14179 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4711 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"63a817074a8d49798bfd46a6545906fff143e924/ghc" 63a81707/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="63a817074a8d49798bfd46a6545906fff143e924" Fix #15845 by defining etaExpandFamInstLHS and using it Summary: Both #9692 and #14179 were caused by GHC being careless about using eta-reduced data family instance axioms. Each of those tickets were fixed by manually whipping up some code to eta-expand the axioms. The same sort of issue has now caused #15845, so I figured it was high time to factor out the code that each of these fixes have in common. This patch introduces the `etaExpandFamInstLHS` function, which takes a family instance's type variables, LHS types, and RHS type, and returns type variables and LHS types that have been eta-expanded if necessary, in the case of a data family instance. (If it's a type family instance, `etaExpandFamInstLHS` just returns the supplied type variables and LHS types unchanged). Along the way, I noticed that many references to `Note [Eta reduction for data families]` (in `FamInstEnv`) had slightly bitrotted (they either referred to a somewhat different name, or claimed that the Note lived in a different module), so I took the liberty of cleaning those up. Test Plan: make test TEST="T9692 T15845" Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15845 Differential Revision: https://phabricator.haskell.org/D5294 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 15:38:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 15:38:22 -0000 Subject: [GHC] #15845: TH eta-reduces away explicit foralls in data family instances In-Reply-To: <050.2b4d3ff964c54112b15d955f9b5c5215@haskell.org> References: <050.2b4d3ff964c54112b15d955f9b5c5215@haskell.org> Message-ID: <065.ef19d3fddeab0cb1a8399f97a7a49f84@haskell.org> #15845: TH eta-reduces away explicit foralls in data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9692, #14179 | Differential Rev(s): Phab:D5294 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"63a817074a8d49798bfd46a6545906fff143e924/ghc" 63a81707/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="63a817074a8d49798bfd46a6545906fff143e924" Fix #15845 by defining etaExpandFamInstLHS and using it Summary: Both #9692 and #14179 were caused by GHC being careless about using eta-reduced data family instance axioms. Each of those tickets were fixed by manually whipping up some code to eta-expand the axioms. The same sort of issue has now caused #15845, so I figured it was high time to factor out the code that each of these fixes have in common. This patch introduces the `etaExpandFamInstLHS` function, which takes a family instance's type variables, LHS types, and RHS type, and returns type variables and LHS types that have been eta-expanded if necessary, in the case of a data family instance. (If it's a type family instance, `etaExpandFamInstLHS` just returns the supplied type variables and LHS types unchanged). Along the way, I noticed that many references to `Note [Eta reduction for data families]` (in `FamInstEnv`) had slightly bitrotted (they either referred to a somewhat different name, or claimed that the Note lived in a different module), so I took the liberty of cleaning those up. Test Plan: make test TEST="T9692 T15845" Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15845 Differential Revision: https://phabricator.haskell.org/D5294 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 15:38:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 15:38:22 -0000 Subject: [GHC] #9692: Template Haskell reification for Data Families is buggy? In-Reply-To: <047.c908a871df417674fd29671ed5adc70e@haskell.org> References: <047.c908a871df417674fd29671ed5adc70e@haskell.org> Message-ID: <062.2f8f186eb1f7d4bce93539b1b74cc45a@haskell.org> #9692: Template Haskell reification for Data Families is buggy? -------------------------------------+------------------------------------- Reporter: hpacheco | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: fixed | Keywords: | TemplateHaskell Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T9692 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D355 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"63a817074a8d49798bfd46a6545906fff143e924/ghc" 63a81707/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="63a817074a8d49798bfd46a6545906fff143e924" Fix #15845 by defining etaExpandFamInstLHS and using it Summary: Both #9692 and #14179 were caused by GHC being careless about using eta-reduced data family instance axioms. Each of those tickets were fixed by manually whipping up some code to eta-expand the axioms. The same sort of issue has now caused #15845, so I figured it was high time to factor out the code that each of these fixes have in common. This patch introduces the `etaExpandFamInstLHS` function, which takes a family instance's type variables, LHS types, and RHS type, and returns type variables and LHS types that have been eta-expanded if necessary, in the case of a data family instance. (If it's a type family instance, `etaExpandFamInstLHS` just returns the supplied type variables and LHS types unchanged). Along the way, I noticed that many references to `Note [Eta reduction for data families]` (in `FamInstEnv`) had slightly bitrotted (they either referred to a somewhat different name, or claimed that the Note lived in a different module), so I took the liberty of cleaning those up. Test Plan: make test TEST="T9692 T15845" Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15845 Differential Revision: https://phabricator.haskell.org/D5294 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 15:40:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 15:40:03 -0000 Subject: [GHC] #15845: TH eta-reduces away explicit foralls in data family instances In-Reply-To: <050.2b4d3ff964c54112b15d955f9b5c5215@haskell.org> References: <050.2b4d3ff964c54112b15d955f9b5c5215@haskell.org> Message-ID: <065.bcf4e56733de70b0a3e68ddd703f3b95@haskell.org> #15845: TH eta-reduces away explicit foralls in data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15845 Blocked By: | Blocking: Related Tickets: #9692, #14179 | Differential Rev(s): Phab:D5294 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => th/T15845 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 16:01:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 16:01:05 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.e1ad389b3cebea30a42080411379ebc0@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: wontfix | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5310 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: patch => closed * resolution: => wontfix Comment: Great! Have fun and re-open if this doesn't work for you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 16:40:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 16:40:41 -0000 Subject: [GHC] #15871: Revamp -fprint-explicit-kinds In-Reply-To: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> References: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> Message-ID: <062.914f3a902e35d7f459eff0d4b8f6d7da@haskell.org> #15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 RyanGlScott): I'd be willing to give this a shot (assuming that no one else is working on this at the moment). Design question: in order to be able to tell when we should print `@(...)` versus `@{...}`, we'll need to store whether an argument is specified or inferred. Unfortunately, the data structure that we currently use to pretty-print type applications, `IfaceAppArgs`, is not suited for this task in its current design: {{{#!hs data IfaceAppArgs = IA_Nil | IA_Vis IfaceType IfaceAppArgs | IA_Invis IfaceType IfaceAppArgs }}} `IfaceAppArgs` lets you distinguish between visible and invisible arguments, but it doesn't give you the ability to tell whether an invisible argument is specified or inferred. Here are various solutions that I've considered that would address this: 1. Add an `ArgFlag` field to `IA_Invis`. This would give you the ability to tell whether an invisible thing is specified or inferred without much additional fuss. The downside is that there's a bit of an impedance mismatch since `ArgFlag` also has the `Required` constructor, but an inferred argument can never be required. 2. Create a custom data type for `IA_Invis`'s purposes. Something like: {{{#!hs data IfaceInvisibility = II_Inferred | II_Specified }}} This solves the impedance mismatch, at the expense of having yet another data type to represent visibility. 3. Change `IfaceAppArgs` itself. Instead of having separate `IA_Vis` and `IA_Invis` constructors, combine them into a single `IA_Arg` constructor: {{{#!hs data IfaceAppArgs = IA_Nil | IA_Arg IfaceType ArgFlag IfaceAppArgs }}} Today's `IA_Vis` would correspond to a `Required` `IA_Arg`, and today's `IA_Invis` would correspond to a `Specified`/`Inferred` `IA_Arg`. I'm inclined to go with option 3, but I'll wait until I hear others' opinions on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 16:45:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 16:45:43 -0000 Subject: [GHC] #15871: Revamp -fprint-explicit-kinds In-Reply-To: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> References: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> Message-ID: <062.5a918a3ac1c9d75baf77480eb791e6a4@haskell.org> #15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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): I vote for (3) in comment:2. I think that's a general improvement over the status quo, regardless of the behavior change proposed in this ticket. Is it ever the case that we print invisible arguments in terms? We should perhaps mirror the treatment in types in terms, as well. But maybe that's better in a separate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 17:06:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 17:06:56 -0000 Subject: [GHC] #15871: Revamp -fprint-explicit-kinds In-Reply-To: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> References: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> Message-ID: <062.a85605867b814d114b3c38ca1a2df5d6@haskell.org> #15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 vote for (3) too. Much nicer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 17:08:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 17:08:39 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.88f943da4b1d6c085bffd26d329ae8ba@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: wontfix | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5310 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, let's execute on #15754. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 17:12:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 17:12:34 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.f47043d0d4bf66920c174426bdffe5fc@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 #15867 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Another invariant that the code generator needs is (I believe) that every let-binder has a distinct unique. We can't re-use the same unique, even in a different scope, let alone shadowing. Why? Because (I believe) that the code generator uses these uniques to generate unique top level labels for the entry code and info table for the closure. Now, it's probably the case that they are unique anyway; but we should either * Write this down as a invariant of STG, or * Establish this invariant in the immediately-before-codegen pass that gets the free vars right, or * Not assume it in the code generator Sebastian, are you planning to work on this free-var change? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 17:33:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 17:33:51 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.54010b58f147aef5b1cef7be4174a644@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Changes (by sgraf): * Attachment "nofib.txt" added. Runtime measurements, ignoring all with <200ms runtime, LLVM backend with -Os -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 17:34:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 17:34:48 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.8003569c2c4821cf08517fc4313ab329@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): I'm currently trying to find the right configuration for Runtime benchmarking. When using the NCG on the architecture I benchmark on, there are seemingly random outliers performance-wise, even when ignoring benchmarks with less than 200ms running time. Take `CSD` from `real/eff` for example. On the target architecture (i7-6700), things consistently are 4.5% slower, yet ''there isn't a single lifted function in that benchmark''. It's basically just a counting loop. To make matters worse, I can't reproduce this on my local PC, quite the contrary there. Altogether this makes for a very meager improvement of -0.2% in runtime. This leads me to believe that the (relatively minor) benefits are obscured by code size and layout concerns. If I only include benchmarks that ran at least 500ms, things look much better (-0.4%), but that's probably because I excluded the `eff` 'microbenchmarks'. I tried another configuration that probably does better justice to the optimisation: I re-ran the benchmarks with `-fllvm -optlo -Os` to have the LLVM optimise for size concerns which IME yields less code layout dependent results. Anyway, ignoring benchmarks with <200ms runtime yields an improvement of -1.0% (result: https://ghc.haskell.org/trac/ghc/attachment/ticket/9476/nofib.txt), while ignoring all benchmarks with <500ms runtime yields an -1.2% improvement. Ironically, runtime of `CSD` ''improved'' by -7.1%. Notable is also that while `n-body` allocates 20% less (heap space!), it got slower by a non-meaningful margin of 0.1%. Maybe watching out for allocations isn't the be all end all here. I really think we should flag benchmarks for being eligible for runtime measurements. I get hung up on what are architectural wibbles ''all the time''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 17:37:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 17:37:13 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.a6a6d2ae7e3b4069867bc5537ba298b8@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: NoFib benchmark | Version: 8.4.3 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 #9476 | Differential Rev(s): Phab:D4989 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: #5793 => #5793 #9476 Comment: C.f. https://ghc.haskell.org/trac/ghc/ticket/9476#comment:52. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 18:28:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 18:28:33 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.4f8a3a170fc827be6b39bbb2fa09fb5a@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by davide): I've submitted some PRs to fix the impending unused import warnings: * https://github.com/haskell/cabal/pull/5673 * https://github.com/kolmodin/binary/pull/159 * https://github.com/haskell/bytestring/pull/168 * https://github.com/haskell/containers/pull/576 * https://github.com/haskell/text/pull/240 I've also added a new ghc patch here: https://phabricator.haskell.org/D5312 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 19:35:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 19:35:58 -0000 Subject: [GHC] #15864: Fix Int8#, Int16#, Word8#, Word16# tests under LLVM code generator In-Reply-To: <046.079da3a1ef7101f96f7646ad252afd59@haskell.org> References: <046.079da3a1ef7101f96f7646ad252afd59@haskell.org> Message-ID: <061.dc640b1726231b4d05c51dec4b513f1f@haskell.org> #15864: Fix Int8#, Int16#, Word8#, Word16# tests under LLVM code generator -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.6.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 michalt): * status: new => closed * resolution: => fixed Comment: I think this should be fixed. :) Please reopen if there's still something wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 20:54:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 20:54:10 -0000 Subject: [GHC] #15867: STG scope error In-Reply-To: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> References: <050.5f6b1c4b7186e0b6a95bc86090440cf9@haskell.org> Message-ID: <065.a0230b2a410550db8fc5e10fe4132d79@haskell.org> #15867: STG scope error -------------------------------------+------------------------------------- Reporter: csabahruska | Owner: sgraf Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: wontfix | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5310 Wiki Page: | -------------------------------------+------------------------------------- Changes (by csabahruska): * Attachment "StgScopeCheck3.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 21:02:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 21:02:28 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.93cf0e2359d04dfb491c3cd79499de08@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Urgh. I know what's going on. It has nothing to do with #12045, but perhaps changes there affected code paths in such a way that this surfaced. The problem is that we have a constraint `b <= a`. Note that `(<=) :: ty1 -> ty2 -> Type` -- that is, `b <= a` is ill-kinded as a constraint. So GHC processes it and dutifully wraps it up by casting by a coercion hole; we get `(b <= a) |> co`, where `co :: Type ~ Constraint`. Then, we zonk (with `zonkTcType`). The zonker uses `mapType` with `tcm_smart` set to `True`. This means that casts are reconstructed with `mkCastTy`, which, of course, does a reflexivity check. And, lo, the reflexivity check decides that `Type` and `Constraint` are equal and thus drops the cast. Later, we try to treat `b <= a` as an predicate, and GHC falls over when `isPredTy (b <= a)` returns `False`. What to do? My first instinct was to add a new setting to `tcm_smart`: sometimes we want to use raw constructors (in `nakedSubstMapper`), sometimes we want core smart constructors (in `zonkTcTypeToType`), and now sometimes we want type-checker smart constructors (newly discovered for `zonkTcType`). We'll also need a `mkTcCastTy` which is like `mkCastTy` but calls `isTcReflexiveCo` instead of `isReflexiveCo`, so that `Type` can be known to be distinct from `Constraint`. (Actually, `mkTcCastTy` can probably skip some of the steps in `mkCastTy`, as we know we'll get another crack at establishing invariants, etc., in `zonkTcTypeToType`.) This is a mess! So my second instinct was to post here for help. Help? Does anyone see a way out? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 8 22:23:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Nov 2018 22:23:26 -0000 Subject: [GHC] #15877: --flavour=quick followed by --flavour=prof fails In-Reply-To: <049.2c7f5c96cfaf8ffe2a60dc4dc965d33c@haskell.org> References: <049.2c7f5c96cfaf8ffe2a60dc4dc965d33c@haskell.org> Message-ID: <064.4153894f967342e5d0e2ff2a47634a9e@haskell.org> #15877: --flavour=quick followed by --flavour=prof fails -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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 mpickering): * status: new => closed * resolution: => fixed Comment: Turns out I was using an old version of hadrian. No problems with an up- to-date version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 02:02:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 02:02:35 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.ee564f4b3c2fbf0af75796b818e0c0f4@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmobile): * Attachment "ioref-inc.hs" added. IORef test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 02:02:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 02:02:49 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.03f09b444bc89cce49c857638f288598@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmobile): * Attachment "mvar-inc.hs" added. MVar test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 02:06:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 02:06:36 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.add960e3effbf85fd53347054f3b560f@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmobile): For what it's worth, the two attached programs work just fine with -N on my TX2, compiled with unmodified GHC 8.4.3. They're both classic "start n threads that increment a shared variable m times" tests, one with MVar and one with IORef. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 04:16:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 04:16:51 -0000 Subject: [GHC] #15769: GHC 8.6 for macOS depends on homebrew In-Reply-To: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> References: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> Message-ID: <067.bd0c6b37e31e8155198528aca9efdd60@haskell.org> #15769: GHC 8.6 for macOS depends on homebrew -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): did ben forget to build with an intree-gmp? my GHC OSX builds do in-tree properly ... this sounds like a failure of packaging rather than anything else -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 09:09:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 09:09:57 -0000 Subject: [GHC] #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" In-Reply-To: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> References: <042.fa7a07707731c06a3e0a81fbce9dad11@haskell.org> Message-ID: <057.a2d8562d55d32a415c70ed757fe0d758@haskell.org> #8040: installed include/HsVersions.h wants to #include "../includes/ghcautoconf.h" -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.6.3 (make) | 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:D2530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * cc: juhpetersen (added) Comment: Just noting that this issue prevents me from build ghc-8.6 on s390x Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 09:16:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 09:16:11 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.3f62b2e838bd0e1c8ce1ab8b4413e7a2@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Phab:D4244 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Sebastian says that this patch got parked because of a few reasons. Anyone interested in picking up this ticket can see a source of ideas in the linked differential. https://phabricator.haskell.org/D4244 He says: * I wasn't sure I understood everything that was going in that patch * There were several 'improvements' that were independent of nested CPR that we wanted to test in isolation (#15001, D4563, D4565) * I felt strongly against complicating demand analysis any further. I remember there was this horrible special case for `case` expressions ([https://phabricator.haskell.org/D4244#inline-35408 klick]) that IMO shows that CPR analysis, as opposed to Usage/Strictness analysis, is a forward analysis. Also there's this 'virgin run', which basically means we run the demand analyser twice anyway, because CPR relies on strictness info being available. That's why I strongly argue that we should split off CPR analysis first before implementing nested CPR. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 09:58:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 09:58:47 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.7fbe0b22c792a59951db49bec8712828@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by davide: Old description: > With a simple package: > > issue.cabal: > {{{ > name: issue > version: 0 > cabal-version: >= 1.10 > build-type: Simple > > library > build-depends: base, binary, binary-orphans==0.1.5.2 > exposed-modules: Issue > }}} > > Issue.hs: > {{{ > {-# LANGUAGE DeriveGeneric #-} > {-# OPTIONS_GHC -Wall #-} > module Issue (T (..)) where > > import Prelude () > import Data.Binary.Orphans > import Data.Binary (Binary (..)) > import GHC.Generics (Generic) > import Data.Aeson (Value) > > data T = T Value deriving (Generic) > > instance Binary T > }}} > > GHC 7.10.3 correctly reports: > {{{ > Issue.hs:7:1: Warning: > The import of ‘Data.Binary’ is redundant > except perhaps to import instances from ‘Data.Binary’ > To import instances alone, use: import Data.Binary() > }}} > > GHC 8.0.1 incorrectly (!!!) reports: > > {{{ > Issue.hs:6:1: warning: [-Wunused-imports] > The import of ‘Data.Binary.Orphans’ is redundant > except perhaps to import instances from ‘Data.Binary.Orphans’ > To import instances alone, use: import Data.Binary.Orphans( > }}} > > but `Binary Value` instance is imported from `Data.Binary.Orphans`. > > --- > > In real life while compiling https://github.com/futurice/haskell-mega- > repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- > github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't > reported, as `Futurice.Prelude` exports other stuff, which is used. See > https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for > minimal imports reported with `-ddump-minimal-imports`. New description: With a simple package: issue.cabal: {{{ name: issue version: 0 cabal-version: >= 1.10 build-type: Simple library build-depends: base, binary, binary-orphans==0.1.5.2 exposed-modules: Issue }}} Issue.hs: {{{ {-# LANGUAGE DeriveGeneric #-} {-# OPTIONS_GHC -Wall #-} module Issue (T (..)) where import Prelude () import Data.Binary.Orphans import Data.Binary (Binary (..)) import GHC.Generics (Generic) import Data.Aeson (Value) data T = T Value deriving (Generic) instance Binary T }}} GHC 7.10.3 correctly reports: {{{ Issue.hs:7:1: Warning: The import of ‘Data.Binary’ is redundant except perhaps to import instances from ‘Data.Binary’ To import instances alone, use: import Data.Binary() }}} GHC 8.0.1 incorrectly (!!!) reports: {{{ Issue.hs:6:1: warning: [-Wunused-imports] The import of ‘Data.Binary.Orphans’ is redundant except perhaps to import instances from ‘Data.Binary.Orphans’ To import instances alone, use: import Data.Binary.Orphans( }}} but `Binary Value` instance is imported from `Data.Binary.Orphans`. --- In real life while compiling https://github.com/futurice/haskell-mega- repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't reported, as `Futurice.Prelude` exports other stuff, which is used. See https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for minimal imports reported with `-ddump-minimal-imports`. ## Status I've submitted some PRs to fix the impending unused import warnings: * https://github.com/haskell/cabal/pull/5673 * https://github.com/kolmodin/binary/pull/159 * MERGED https://github.com/haskell/bytestring/pull/168 * https://github.com/haskell/containers/pull/576 * MERGED https://github.com/haskell/text/pull/240 I've also added a new ghc patch here: * https://phabricator.haskell.org/D5312 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 10:51:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 10:51:00 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.355854eaaf0968998a931dc91b686dfc@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by davide: Old description: > With a simple package: > > issue.cabal: > {{{ > name: issue > version: 0 > cabal-version: >= 1.10 > build-type: Simple > > library > build-depends: base, binary, binary-orphans==0.1.5.2 > exposed-modules: Issue > }}} > > Issue.hs: > {{{ > {-# LANGUAGE DeriveGeneric #-} > {-# OPTIONS_GHC -Wall #-} > module Issue (T (..)) where > > import Prelude () > import Data.Binary.Orphans > import Data.Binary (Binary (..)) > import GHC.Generics (Generic) > import Data.Aeson (Value) > > data T = T Value deriving (Generic) > > instance Binary T > }}} > > GHC 7.10.3 correctly reports: > {{{ > Issue.hs:7:1: Warning: > The import of ‘Data.Binary’ is redundant > except perhaps to import instances from ‘Data.Binary’ > To import instances alone, use: import Data.Binary() > }}} > > GHC 8.0.1 incorrectly (!!!) reports: > > {{{ > Issue.hs:6:1: warning: [-Wunused-imports] > The import of ‘Data.Binary.Orphans’ is redundant > except perhaps to import instances from ‘Data.Binary.Orphans’ > To import instances alone, use: import Data.Binary.Orphans( > }}} > > but `Binary Value` instance is imported from `Data.Binary.Orphans`. > > --- > > In real life while compiling https://github.com/futurice/haskell-mega- > repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- > github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't > reported, as `Futurice.Prelude` exports other stuff, which is used. See > https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for > minimal imports reported with `-ddump-minimal-imports`. > > ## Status > > I've submitted some PRs to fix the impending unused import warnings: > > * https://github.com/haskell/cabal/pull/5673 > * https://github.com/kolmodin/binary/pull/159 > * MERGED https://github.com/haskell/bytestring/pull/168 > * https://github.com/haskell/containers/pull/576 > * MERGED https://github.com/haskell/text/pull/240 > > I've also added a new ghc patch here: > * https://phabricator.haskell.org/D5312 New description: With a simple package: issue.cabal: {{{ name: issue version: 0 cabal-version: >= 1.10 build-type: Simple library build-depends: base, binary, binary-orphans==0.1.5.2 exposed-modules: Issue }}} Issue.hs: {{{ {-# LANGUAGE DeriveGeneric #-} {-# OPTIONS_GHC -Wall #-} module Issue (T (..)) where import Prelude () import Data.Binary.Orphans import Data.Binary (Binary (..)) import GHC.Generics (Generic) import Data.Aeson (Value) data T = T Value deriving (Generic) instance Binary T }}} GHC 7.10.3 correctly reports: {{{ Issue.hs:7:1: Warning: The import of ‘Data.Binary’ is redundant except perhaps to import instances from ‘Data.Binary’ To import instances alone, use: import Data.Binary() }}} GHC 8.0.1 incorrectly (!!!) reports: {{{ Issue.hs:6:1: warning: [-Wunused-imports] The import of ‘Data.Binary.Orphans’ is redundant except perhaps to import instances from ‘Data.Binary.Orphans’ To import instances alone, use: import Data.Binary.Orphans( }}} but `Binary Value` instance is imported from `Data.Binary.Orphans`. --- In real life while compiling https://github.com/futurice/haskell-mega- repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't reported, as `Futurice.Prelude` exports other stuff, which is used. See https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for minimal imports reported with `-ddump-minimal-imports`. ## Status I've submitted some PRs to fix the impending unused import warnings: * MERGED https://github.com/haskell/cabal/pull/5673 * https://github.com/kolmodin/binary/pull/159 * MERGED https://github.com/haskell/bytestring/pull/168 * https://github.com/haskell/containers/pull/576 * MERGED https://github.com/haskell/text/pull/240 I've also added a new ghc patch here: * https://phabricator.haskell.org/D5312 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 13:47:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 13:47:54 -0000 Subject: [GHC] #15879: Make UniqDSet a newtype Message-ID: <044.d015b93ddf01ab30fec5e94dbe79cede@haskell.org> #15879: Make UniqDSet a newtype -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13114 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For the same reasons as in #13114 and Phab:D3146 we should make `UniqDSet` a newtype of `UniqDFM`. I wonder if we can also have a prettier `Outputable` instance this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 14:10:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 14:10:56 -0000 Subject: [GHC] #15880: GHC.Stats: Add info on amount of pinned memory Message-ID: <042.9d78ca0973e77e7163814c454c8c3fd9@haskell.org> #15880: GHC.Stats: Add info on amount of pinned memory -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Runtime | Version: 8.6.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: -------------------------------------+------------------------------------- https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Stats.html `GHC.Stats`'s `GCDetails` tells us, separately, the amount of * total heap data (including large objects and compact data) * large ojects * compact data * "Total amount of memory in use by the RTS" (`gcdetails_mem_in_use_bytes`) There currently doesn't seem to be a way to get the amount of pinned memory in use. So some questions: * Is pinned memory accounted for in `gcdetails_mem_in_use_bytes`? * If yes, is it pretty much that value minus `gcdetails_live_bytes`, or are there other memory uses that count to the latter? * If I wanted to add the amount of pinned memory directly to `GHC.Stats`, where would I take that value from? In general, my goal is to collect _all_ easily (cheaply) collectable memory info so that I can add it to `ekg`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 14:14:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 14:14:20 -0000 Subject: [GHC] #1600: Optimisation: CPR the results of IO In-Reply-To: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> References: <047.6bf35585590f6b4632c8ba79805f0623@haskell.org> Message-ID: <062.4db3baafc9598032480d9a7e25da45bd@haskell.org> #1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Phab:D4244 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks Matthew. If anyone wants to pick this up I'd be happy to help. But I'm too swamped to lead on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 14:22:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 14:22:25 -0000 Subject: [GHC] #15881: GHC Panic: data A n (a :: n) :: a -> Type Message-ID: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> #15881: GHC Panic: data A n (a :: n) :: a -> Type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{#!hs {-# Language KindSignatures #-} {-# Language PolyKinds #-} import Data.Kind data A n (a :: n) :: a -> Type }}} causes a panic on 8.7.20181017 {{{ $ ~/code/headghc/inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci 665_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 665_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_a1xR} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} and an assertion failure in 8.7.20181029 {{{ $ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot- ghci 665_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 665_bug.hs, interpreted ) *** Exception: ASSERT failed! file compiler/types/TyCon.hs, line 420 > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 14:24:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 14:24:21 -0000 Subject: [GHC] #15881: GHC Panic: data A n (a :: n) :: a -> Type In-Reply-To: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> References: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> Message-ID: <066.313a767f81bc6c7def5c1eaf70a275b7@haskell.org> #15881: GHC Panic: data A n (a :: n) :: a -> Type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 Iceland_jack): goes away if `a` is unused `data A n (a :: n) :: Type` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 14:27:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 14:27:01 -0000 Subject: [GHC] #15881: GHC Panic: data A n (a :: n) :: a -> Type In-Reply-To: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> References: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> Message-ID: <066.789b7c0632841fa4faf7ca6f99d7ed03@haskell.org> #15881: GHC Panic: data A n (a :: n) :: a -> Type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 Iceland_jack): Ah I forgot to say, `headghc` has the [https://phabricator.haskell.org/D5229 visible kind application] patch but `unmodified` is HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 14:32:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 14:32:30 -0000 Subject: [GHC] #15881: GHC Panic: data A n (a :: n) :: a -> Type In-Reply-To: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> References: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> Message-ID: <066.643ad299a3f7e29c090c6be177b1da7a@haskell.org> #15881: GHC Panic: data A n (a :: n) :: a -> Type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 Iceland_jack): Same happens with {{{#!hs {-# Language KindSignatures #-} {-# Language PolyKinds #-} import Data.Kind data A n (a :: n n) :: Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 15:17:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 15:17:53 -0000 Subject: [GHC] #15879: Make UniqDSet a newtype In-Reply-To: <044.d015b93ddf01ab30fec5e94dbe79cede@haskell.org> References: <044.d015b93ddf01ab30fec5e94dbe79cede@haskell.org> Message-ID: <059.2f46465e0ee62c1cb7e9bfb50d24b605@haskell.org> #15879: Make UniqDSet a newtype -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13114 | Differential Rev(s): Phab:D5313 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => patch * differential: => Phab:D5313 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 15:22:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 15:22:11 -0000 Subject: [GHC] #15881: GHC Panic: data A n (a :: n) :: a -> Type In-Reply-To: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> References: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> Message-ID: <066.2447e8fdf44ab43768d536f0363679d4@haskell.org> #15881: GHC Panic: data A n (a :: n) :: a -> Type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 RyanGlScott): I'm fairly confident that this is a duplicate of #15881. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 15:30:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 15:30:09 -0000 Subject: [GHC] #15881: GHC Panic: data A n (a :: n) :: a -> Type In-Reply-To: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> References: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> Message-ID: <066.6767fb1f3188bf037d1eb772f459b553@haskell.org> #15881: GHC Panic: data A n (a :: n) :: a -> Type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 Iceland_jack): #15881 is this ticket. Did you mean #15804? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 15:43:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 15:43:53 -0000 Subject: [GHC] #15871: Revamp -fprint-explicit-kinds In-Reply-To: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> References: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> Message-ID: <062.1526223404ae3e2cc3f7609b16945c96@haskell.org> #15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5314 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5314 * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 15:44:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 15:44:51 -0000 Subject: [GHC] #15881: GHC Panic: data A n (a :: n) :: a -> Type In-Reply-To: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> References: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> Message-ID: <066.9223592c33be1aa3df011a7623e35323@haskell.org> #15881: GHC Panic: data A n (a :: n) :: a -> Type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 RyanGlScott): Oops. Yes, I meant #15804. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 15:51:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 15:51:51 -0000 Subject: [GHC] #15804: GHC panic: data T :: (a :: k) -> * In-Reply-To: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> References: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> Message-ID: <066.4aaa2be145f4591997081bb4e4304066@haskell.org> #15804: GHC panic: data T :: (a :: k) -> * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15881 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #15881 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 18:11:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 18:11:05 -0000 Subject: [GHC] #15862: Panic with promoted types that Typeable doesn't support (was: Typeable panic with promoted rank-2 kind (initDs)) In-Reply-To: <050.a59278de72961367e1dea424ce2860fa@haskell.org> References: <050.a59278de72961367e1dea424ce2860fa@haskell.org> Message-ID: <065.8bc881579070b8486f9f444590a90290@haskell.org> #15862: Panic with promoted types that Typeable doesn't support -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: Typeable, ImpredicativeTypes => Typeable Comment: It turns out that this problem is more general than just this one example (which happens to use `ImpredicativeTypes`). Here is //another// program which triggers the same panic: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Type.Reflection type family F a type instance F Int = Type data Bar = forall (a :: F Int). MkBar a bar :: TypeRep (MkBar True) bar = typeRep }}} This time, the culprit is likely the fact that `MkBar True` contains a cast/coercion somewhere, which is another thing that `Typeable` doesn't support. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 18:18:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 18:18:02 -0000 Subject: [GHC] #15882: :load in ghci should expose the entire namespace of a module Message-ID: <048.6a2e149d17b2fdb2cdd8b7fb78fbd1d6@haskell.org> #15882: :load in ghci should expose the entire namespace of a module -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: GHCi | Version: 8.6.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: -------------------------------------+------------------------------------- When using "import" in ghci, only exported names are available. When using :load, the use case is typically for "toying around" or testing a module. In that case, the export list restrictions are much less useful. There is currently no way to just expose the same namespace context of the code in a module in ghci, and having :load do that sounds like it would be very useful. The ordinary "import" namespace semantics are after all available too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 18:18:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 18:18:36 -0000 Subject: [GHC] #15882: :load in ghci should expose the entire namespace of a module In-Reply-To: <048.6a2e149d17b2fdb2cdd8b7fb78fbd1d6@haskell.org> References: <048.6a2e149d17b2fdb2cdd8b7fb78fbd1d6@haskell.org> Message-ID: <063.0c9caaa0e2f94dfc9f3153911d5e890f@haskell.org> #15882: :load in ghci should expose the entire namespace of a module -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: GHCi | Version: 8.6.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 EyalLotem): Another way to put this is: * :load of a Haskell file should be roughly equivalent to copy&pasting the code of that module in ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 19:56:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 19:56:19 -0000 Subject: [GHC] #15319: Configurable/overridable settings file In-Reply-To: <044.ba7ad8d95aa9a6958eb5b0890b79f3ba@haskell.org> References: <044.ba7ad8d95aa9a6958eb5b0890b79f3ba@haskell.org> Message-ID: <059.6f81ce62ebbe348c9a7b8f5f82708730@haskell.org> #15319: Configurable/overridable settings file -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5317 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * differential: => Phab:D5317 Comment: Phab:D5317 implements [[comment:1|comment:1]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 20:16:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 20:16:34 -0000 Subject: [GHC] #15862: Panic with promoted types that Typeable doesn't support In-Reply-To: <050.a59278de72961367e1dea424ce2860fa@haskell.org> References: <050.a59278de72961367e1dea424ce2860fa@haskell.org> Message-ID: <065.7c43194e6d828be4e00b493b4f7f4944@haskell.org> #15862: Panic with promoted types that Typeable doesn't support -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Unboxed sums, too: {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE UnboxedSums #-} module Bug where import Type.Reflection data Quux = MkQuux (# Bool | Int #) bar :: TypeRep MkQuux bar = typeRep }}} {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) GHC error in desugarer lookup in Bug: attempting to use module ‘main:Bug’ (Bug.hs) which is not loaded ghc: panic! (the 'impossible' happened) (GHC version 8.6.2 for x86_64-unknown-linux): initDs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 20:35:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 20:35:34 -0000 Subject: [GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags In-Reply-To: <042.e68200604de67ef001a98aff36406689@haskell.org> References: <042.e68200604de67ef001a98aff36406689@haskell.org> Message-ID: <057.1dd2b05b55127c462b992792e559cd91@haskell.org> #14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: 8.8.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 RolandSenn): * owner: (none) => RolandSenn * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 20:46:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 20:46:21 -0000 Subject: [GHC] #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) Message-ID: <051.8c8f3c0ace71ad8ecb6463da73c07735@haskell.org> #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes #-} {-# Language KindSignatures #-} {-# Language PolyKinds #-} import GHC.Exts newtype Foo rep = MkFoo (forall (a :: TYPE rep). a) }}} {{{ $ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot- ghci /tmp/U.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/U.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181029 for x86_64-unknown-linux): isUnliftedType forall (a :: TYPE rep_a1AA[sk:0]). a :: TYPE rep_a1AA[sk:0] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:2332:10 in ghc:Type isUnliftedType, called at compiler/typecheck/TcTyClsDecls.hs:3055:25 in ghc:TcTyClsDecls Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 20:46:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 20:46:42 -0000 Subject: [GHC] #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) In-Reply-To: <051.8c8f3c0ace71ad8ecb6463da73c07735@haskell.org> References: <051.8c8f3c0ace71ad8ecb6463da73c07735@haskell.org> Message-ID: <066.aa802970d5edb334b51a556661c22554@haskell.org> #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 Iceland_jack): Relate to #13929? At least similar error -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 20:51:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 20:51:05 -0000 Subject: [GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags In-Reply-To: <042.e68200604de67ef001a98aff36406689@haskell.org> References: <042.e68200604de67ef001a98aff36406689@haskell.org> Message-ID: <057.19a24109d45e548e72ef9f220acd64c4@haskell.org> #14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5318 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * testcase: => make test TEST=T14452 * status: new => patch * differential: => Phab:D5318 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 21:13:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 21:13:31 -0000 Subject: [GHC] #15884: Completeness of View Patterns With a Complete Set of Output Patterns Message-ID: <050.695bd937a87ad0c3efa7472cecf34a10@haskell.org> #15884: Completeness of View Patterns With a Complete Set of Output Patterns -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- For example, the code {{{#!hs {-# OPTIONS_GHC -Wall #-} {-# LANGUAGE ViewPatterns #-} f :: Maybe a -> Bool f (id->Nothing) = False f (id->(Just _)) = True }}} mistakenly returns the warning {{{ warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘f’: Patterns not matched: _ | 4 | f (id->Nothing) = False | ^^^^^^^^^^^^^^^^^^^^^^^^... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 21:16:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 21:16:31 -0000 Subject: [GHC] #15862: Panic with promoted types that Typeable doesn't support In-Reply-To: <050.a59278de72961367e1dea424ce2860fa@haskell.org> References: <050.a59278de72961367e1dea424ce2860fa@haskell.org> Message-ID: <065.1f2f55e9ca0c1cb4b9438ffae134f97f@haskell.org> #15862: Panic with promoted types that Typeable doesn't support -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This also fails {{{#!hs data Bar where MkBar :: forall (a :: F Int). a -> Bar }}} but this succeeds {{{#!hs data Bar where MkBar :: (a :: F Int) -> Bar }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 21:19:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 21:19:49 -0000 Subject: [GHC] #15495: Handling Source Locations via TTG In-Reply-To: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> References: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> Message-ID: <065.dbf48b111b96a2430b567e1c004f38f6@haskell.org> #15495: Handling Source Locations via TTG -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new 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:D5036 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Shayan-Najd): The latest validated version is at `wip/shnajd-TTG-SrcLocs` in both [[https://github.com/shayan-najd/ghc]] and [[https://github.com/shayan-najd/haddock]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 9 21:46:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Nov 2018 21:46:34 -0000 Subject: [GHC] #15884: Completeness of View Patterns With a Complete Set of Output Patterns In-Reply-To: <050.695bd937a87ad0c3efa7472cecf34a10@haskell.org> References: <050.695bd937a87ad0c3efa7472cecf34a10@haskell.org> Message-ID: <065.f3c21992d0bd3d3bd3da62a41b19d4d9@haskell.org> #15884: Completeness of View Patterns With a Complete Set of Output Patterns -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 01:17:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 01:17:11 -0000 Subject: [GHC] #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types Message-ID: <050.dcd9c09929690220037b43a75f3ae198@haskell.org> #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- On our work on the [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow new front-end AST for GHC] based on [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance TTG], we would like to use [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations a pattern synonym] similar to the following: {{{#!hs pattern LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a pattern LL s m <- (decomposeSrcSpan -> (m , s)) where LL s m = composeSrcSpan (m , s) }}} We know that any match on `LL` patterns, makes the pattern matching total, as it uses a view pattern with a total output pattern (i.e., in `decomposeSrcSpan -> (m , s)`, the pattern `(m , s)` is total). As far as I understand, currently COMPLETE pragmas cannot be used with such a polymorphic pattern synonym. I believe we need to enhance COMPLETE pragmas to support such pattern synonyms. This can be done either syntactically, or (preferably) type-directed. For example, we should be able to write `{-# COMPLETE LL #-}` or `{-# COMPLETE LL :: HasSrcSpan a => a #-}`. In the type-directed approach a. the totality checker *may* need to track, at least, the set of required constraints of pattern synonyms mentioned in a COMPLETE pragma; and b. the order of pattern synonyms mentioned in a pragma should be taken into account (as noted by @carter). For example, in the case of `LL`, `HasSrcSpan a` is a required type constraint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 01:17:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 01:17:46 -0000 Subject: [GHC] #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types In-Reply-To: <050.dcd9c09929690220037b43a75f3ae198@haskell.org> References: <050.dcd9c09929690220037b43a75f3ae198@haskell.org> Message-ID: <065.b99abf15a82ac0bd3e411f1f6d40be76@haskell.org> #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 Shayan-Najd): It is worth mentioning that the combination of the ordered set of pattern synonym names in the pragma and the type of the pattern synonyms themselves often guarantees abstraction (currently, I don't know of any situation that does not): the pattern matching totality checker does not need to know the implementation details of pattern synonyms (e.g., such details can be omitted from the interface files). I noticed the required type constraints guarantee that a pattern synonym mentioned in a COMPLETE ordered set is always used in a setting where, well, the required constraints hold. This fact immediately implies that, for example in `{-# COMPLETE LL :: HasSrcSpan a => a #-}`, `a` always satisfies `HasSrcSpan`, hence checking the completeness of a matching on `LL` does not need to consider types at all; all types match `a` and `HasSrcSpan a` is already guaranteed to hold by the pattern synonym type checking. I might be wrong about this observation though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 01:20:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 01:20:16 -0000 Subject: [GHC] #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types In-Reply-To: <050.dcd9c09929690220037b43a75f3ae198@haskell.org> References: <050.dcd9c09929690220037b43a75f3ae198@haskell.org> Message-ID: <065.9bd9b0913077f1a025b16c7f43248502@haskell.org> #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 Shayan-Najd): * keywords: => PatternMatchWarnings * cc: alanz, bgamari, RyanGlScott, goldfire, carter, mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 04:26:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 04:26:11 -0000 Subject: [GHC] #15886: Spurious warning about incomplete pattern with PatternSynonyms Message-ID: <047.982b8cd6c6924b286d997c8f65068fc4@haskell.org> #15886: Spurious warning about incomplete pattern with PatternSynonyms -------------------------------------+------------------------------------- Reporter: selinger | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect (amd64) | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE PatternSynonyms #-} module Test where f :: Int -> Bool f (id -> a) = True pattern X a <- (id -> a) g :: Int -> Bool g (X a) = True }}} When compiling with -Wincomplete-patterns, this code produces an (incorrect) warning for `g`, but not for `f`. The only difference is that `g` uses a pattern synonym. {{{ K.hs:12:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘g’: Patterns not matched: _ | 12 | g (X a) = True | ^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 11:04:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 11:04:05 -0000 Subject: [GHC] #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types In-Reply-To: <050.dcd9c09929690220037b43a75f3ae198@haskell.org> References: <050.dcd9c09929690220037b43a75f3ae198@haskell.org> Message-ID: <065.b06909880407e68772ecc6e36afe4c2a@haskell.org> #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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 => PatternMatchWarnings, PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 11:07:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 11:07:33 -0000 Subject: [GHC] #15884: Completeness of View Patterns With a Complete Set of Output Patterns In-Reply-To: <050.695bd937a87ad0c3efa7472cecf34a10@haskell.org> References: <050.695bd937a87ad0c3efa7472cecf34a10@haskell.org> Message-ID: <065.60a1f50bb556742687039a401dd046b6@haskell.org> #15884: Completeness of View Patterns With a Complete Set of Output Patterns -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: duplicate | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15753 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #15753 Comment: This is a duplicate of #15753 (see https://ghc.haskell.org/trac/ghc/ticket/15753#comment:3), so closing. In particular, note that this bug has nothing to do with `ViewPatterns`, as you can achieve the same erroneous warning with just ordinary `PatternGuards`: {{{#!hs {-# OPTIONS_GHC -Wall #-} module Bug where f :: Maybe a -> Bool f x | Nothing <- id x = False | Just _ <- id x = True }}} {{{ $ /opt/ghc/8.6.2/bin/ghci Bug.hs GHCi, version 8.6.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:5:2: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘f’: Patterns not matched: _ | 5 | f x | ^^^... }}} Removing the use of the `id` function, however, makes the warnings go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 11:07:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 11:07:54 -0000 Subject: [GHC] #15753: Inconsistent pattern-match warnings when using guards versus case expressions In-Reply-To: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> References: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> Message-ID: <065.db7eea5578c1dee85c4fef83fc156da3@haskell.org> #15753: Inconsistent pattern-match warnings when using guards versus case expressions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: #15884 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15884 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 11:13:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 11:13:16 -0000 Subject: [GHC] #15886: Spurious warning about incomplete pattern with PatternSynonyms In-Reply-To: <047.982b8cd6c6924b286d997c8f65068fc4@haskell.org> References: <047.982b8cd6c6924b286d997c8f65068fc4@haskell.org> Message-ID: <062.0d3dbc86d2e175a0f544937d1da9bf5b@haskell.org> #15886: Spurious warning about incomplete pattern with PatternSynonyms -------------------------------------+------------------------------------- Reporter: selinger | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1 Resolution: invalid | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => PatternSynonyms, PatternMatchWarnings * status: new => closed * resolution: => invalid Comment: This is expected behavior. Refer to the [https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/glasgow_exts.html?highlight=patternsynonyms #complete-pragmas users' guide section] on `COMPLETE` sets: > The `COMPLETE` pragma is used to inform the pattern match checker that a certain set of patterns is complete and that any function which matches on all the specified patterns is total. > > The most common usage of `COMPLETE pragmas` is with //Pattern synonyms//. On its own, the checker is very naive and assumes that any match involving a pattern synonym will fail. As a result, any pattern match on a pattern synonym is regarded as incomplete unless the user adds a catch-all case. As this suggests, you need to declare a `COMPLETE` set for `X` in order for the coverage checker to reason about it. This variant of your program, for instance, does not emit any warnings when compiled with `-Wincomplete- patterns`: {{{#!hs {-# LANGUAGE ViewPatterns #-} {-# LANGUAGE PatternSynonyms #-} module Test where f :: Int -> Bool f (id -> a) = True pattern X a <- (id -> a) {-# COMPLETE X :: Int #-} g :: Int -> Bool g (X a) = True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 11:15:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 11:15:03 -0000 Subject: [GHC] #15881: GHC Panic: data A n (a :: n) :: a -> Type In-Reply-To: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> References: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> Message-ID: <066.412d84a44f94fc35c01f5082f318bb32@haskell.org> #15881: GHC Panic: data A n (a :: n) :: a -> Type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15804 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15804 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 11:16:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 11:16:14 -0000 Subject: [GHC] #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) In-Reply-To: <051.8c8f3c0ace71ad8ecb6463da73c07735@haskell.org> References: <051.8c8f3c0ace71ad8ecb6463da73c07735@haskell.org> Message-ID: <066.51b0e963813cc8bd63c1d4516562e0df@haskell.org> #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: Resolution: | LevityPolymorphism, TypeInType 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): * keywords: => LevityPolymorphism, TypeInType * failure: None/Unknown => Compile-time crash or panic * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 13:06:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 13:06:52 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.d4c2adbddb112f1aeb9432a3a428070e@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer 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 JulianLeviston): Thanks for the direction. Apologies for taking so long to get back; I've had the flu. `-v3` output is fascinating (thanks, I wasn't aware of it), because nothing is marked as slow. I'll look into building a profiled compiler. The pause happens immediately before `1e100000000 :: Fractional p => p` is output. Here's the output for anyone following along's interest: {{{ Expanse:ghc julian$ ./inplace/bin/ghc-stage2 -v3 -Rghc-timing -e ':t 1e100000000' Glasgow Haskell Compiler, Version 8.7.20181012, stage 2 booted by GHC version 8.4.3 Using binary package database: /Users/julian/code/haskell/ghc/inplace/lib/package.conf.d/package.cache package flags [] loading package database /Users/julian/code/haskell/ghc/inplace/lib/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.3 wired-in package integer-wired-in mapped to integer-gmp-1.0.2.0 wired-in package base mapped to base-4.12.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.14.0.0 wired-in package ghc mapped to ghc-8.7 *** Parser [source]: !!! Parser [source]: finished in 0.83 milliseconds, allocated 0.489 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.64 milliseconds, allocated 0.367 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 5.45 milliseconds, allocated 5.770 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.52 milliseconds, allocated 0.488 megabytes Loading package ghc-prim-0.5.3 ... linking ... done. Loading package integer-gmp-1.0.2.0 ... linking ... done. *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name libiconv.dylib *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name liblibiconv.dylib *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name iconv.lib *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name libiconv.lib *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name libiconv.dll.a *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name iconv.dll.a *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name libiconv.a *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name iconv.a *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name libiconv *** gcc: gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -B/Users/julian/code/haskell/ghc/libraries/base/dist-install/build --print-file-name iconv Loading package base-4.12.0.0 ... linking ... done. Search directories (user): Search directories (gcc): *** Parser [source]: !!! Parser [source]: finished in 0.15 milliseconds, allocated 0.153 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.32 milliseconds, allocated 0.203 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.16 milliseconds, allocated 0.112 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.31 milliseconds, allocated 0.299 megabytes *** Parser [source]: !!! Parser [source]: finished in 0.20 milliseconds, allocated 0.215 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.35 milliseconds, allocated 0.224 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.15 milliseconds, allocated 0.089 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.36 milliseconds, allocated 0.351 megabytes *** Parser [source]: !!! Parser [source]: finished in 0.09 milliseconds, allocated 0.043 megabytes 1e100000000 :: Fractional p => p Leaving GHCi. *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: <> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 16:07:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 16:07:09 -0000 Subject: [GHC] #15886: Spurious warning about incomplete pattern with PatternSynonyms In-Reply-To: <047.982b8cd6c6924b286d997c8f65068fc4@haskell.org> References: <047.982b8cd6c6924b286d997c8f65068fc4@haskell.org> Message-ID: <062.8f54719f0efe9799b5b280c1254592ca@haskell.org> #15886: Spurious warning about incomplete pattern with PatternSynonyms -------------------------------------+------------------------------------- Reporter: selinger | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1 Resolution: invalid | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by selinger): Interesting. Thanks for pointing this out. I assumed (wrongly, it turns out) that since pattern synonyms are just syntactic sugar, the checker could desugar it for the purposes of coverage checking. Are there good reasons for "the checker is very naive"? For sure, there are good uses cases for COMPLETE pragmas, because there are cases (even without using pattern synonyms) that's aren't readily decidable. I'm just surprised that the checker can't solve obvious cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 16:13:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 16:13:50 -0000 Subject: [GHC] #15886: Spurious warning about incomplete pattern with PatternSynonyms In-Reply-To: <047.982b8cd6c6924b286d997c8f65068fc4@haskell.org> References: <047.982b8cd6c6924b286d997c8f65068fc4@haskell.org> Message-ID: <062.c8b349807f673944fb45a4325a9deea1@haskell.org> #15886: Spurious warning about incomplete pattern with PatternSynonyms -------------------------------------+------------------------------------- Reporter: selinger | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1 Resolution: invalid | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The rationale for requiring `COMPLETE` signatures to coverage-check pattern synonyms can be found in [https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/CompleteSigs?version=15 the corresponding GHC wiki page]: > The exhaustiveness checker currently chokes on pattern synonyms. > They are marked as always fallible patterns which means that we must also always include a catch-all case in order to avoid a warning. > > {{{#!hs > data A = A > > pattern :: A > pattern P = A > > foo :: A -> A > foo P = A > }}} > > leads to the warning that pattern matches for `foo` are non-exhaustive. > > {{{ > simpletest.hs:7:1: warning: [-Wincomplete-patterns] > Pattern match(es) are non-exhaustive > In an equation for ‘foo’: Patterns not matched: _ > }}} > > Inspecting the definition of `P` we can see that the matches for `foo` are indeed exhaustive as `A` is a unary data type but the pattern match checker does not make use of this information. > > And neither should it! Pattern synonyms are a means of *abstraction*, if the exhaustiveness checker could look through a definition then the implementation of `P` would leak into error messages. > We want users to be able to replace bona-fide data constructors with pattern synonyms without consumers noticing. > To that end, we allow users to specify a complete set of pattern synonyms in order to sate the pattern match checker. If a complete pragma is not provided then we keep the same behaviour as in previous releases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 17:15:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 17:15:40 -0000 Subject: [GHC] #15886: Spurious warning about incomplete pattern with PatternSynonyms In-Reply-To: <047.982b8cd6c6924b286d997c8f65068fc4@haskell.org> References: <047.982b8cd6c6924b286d997c8f65068fc4@haskell.org> Message-ID: <062.9b21d7a6ac32631e857bddcf262e4108@haskell.org> #15886: Spurious warning about incomplete pattern with PatternSynonyms -------------------------------------+------------------------------------- Reporter: selinger | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1 Resolution: invalid | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by selinger): OK, this makes sense. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 20:45:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 20:45:33 -0000 Subject: [GHC] #15852: Bad axiom produced for polykinded data family In-Reply-To: <047.481c46c837c01249db862f276fa4c502@haskell.org> References: <047.481c46c837c01249db862f276fa4c502@haskell.org> Message-ID: <062.08950398517f7f66478e9eee00c6e360@haskell.org> #15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies, | 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): `IfaceTyConInfo` or `IfaceTyConSort` might be possible candidates for storing this information. Currently, these are defined as: {{{#!hs data IfaceTyConInfo -- Used to guide pretty-printing -- and to disambiguate D from 'D (they share a name) = IfaceTyConInfo { ifaceTyConIsPromoted :: IsPromoted , ifaceTyConSort :: IfaceTyConSort } -- | The various types of TyCons which have special, built-in syntax. data IfaceTyConSort = IfaceNormalTyCon -- ^ a regular tycon | IfaceTupleTyCon !Arity !TupleSort -- ^ e.g. @(a, b, c)@ or @(#a, b, c#)@. | IfaceSumTyCon !Arity -- ^ e.g. @(a | b | c)@ | IfaceEqualityTyCon -- ^ A heterogeneous equality TyCon }}} (The Haddocks for `IfaceTyConSort` are misleading, since //every// `IfaceTyCon` has one, not just those with special, built-in syntax. Regardless of how we fix this bug, we should change that documentation to reflect reality.) My vote would be to extend one of these data types with an extra field of type `IfaceTyConParent`, which would be sufficient to tell if a `TyCon` came from a data family instance or not. Then it would just be a matter of plumbing this information to `pprAxBranch` from its call sites. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 20:46:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 20:46:35 -0000 Subject: [GHC] #15820: Document the proposals process in the GHC manual In-Reply-To: <047.f26a3edc97953dc3d8f97d5632ba8107@haskell.org> References: <047.f26a3edc97953dc3d8f97d5632ba8107@haskell.org> Message-ID: <062.ca6e8a2a4d37af50a968d698323f90e8@haskell.org> #15820: Document the proposals process in the GHC manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 23:46:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 23:46:46 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.191ab6a4311def908ee0a75c9e423de1@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): What exactly does 'moving out of "merge"' mean? Initially I understood it to mean 'reverted', but does this instead refer to something else, such as moving the commit out of a release version of GHC? The reason I ask is that cdsmith and I just checked out HEAD and saw that the change was not reverted, so my interpretation of what you meant needs to be updated. Thanks, chessai -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 10 23:47:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Nov 2018 23:47:47 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.24e18dc05e723b0dfccd6d5fd9dbbe29@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: chessai Type: feature request | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by chessai): * owner: (none) => chessai -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 00:13:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 00:13:04 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.49448a0772f74e704baf14f8a3a57e7f@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer 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 JulianLeviston): I've been trying to build a profiled compiler. I adjusted `build.mk` by changing the `BuildFlavour` thusly: `BuildFlavour = prof` and commented out the `stage = 2`setting I had. I also added this to the bottom, to put profiling hooks across the typechecker: {{{ define add_mods_flag = $(foreach mod,$(2),$(eval $(basename $(mod))_HC_OPTS += $(1))) endef $(call add_mods_flag,-fprof-auto,$(wildcard compiler/typecheck/*.hs)) }}} I keep getting this error after `make clean && make -j4` in either the `ghc/compiler` or `ghc/` directories: {{{ GHC error in desugarer lookup in GHC.Real: Can't find interface-file declaration for type constructor or class mkRational 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 ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181012 for x86_64-apple-darwin): initDs Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} What should I do next? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 00:23:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 00:23:29 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.83835e64229cd8b0a02ea13b60cb0f1a@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: chessai Type: feature request | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): The commit was pushed to ghc master branch (that will become 8.8 in the future). Initially, I marked this ticket as 'merge' which means it would be a candidate for cherrypicking to the ghc-8.6 branch (at that time, that was the branch that would become 8.6.2). However, before the commit was pushed to ghc-8.6, #15702 was reported. Seeing that we might have a potentially breaking regression, I removed the 'merge' status so that the commit won't be put in 8.6.2. I didn't revert the commit, as there was no hurry and I hoped there would be a larger discussion about solutions at #15702. If nothing happens, I'll revert the commit; please speak up if you're interested in a different solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 01:03:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 01:03:59 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.8d844448e64523d12409a10a52a90f9e@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: chessai Type: feature request | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cdsmith): chessai@ and I are working right now on a version of the patch that avoids the error in #15702. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 02:57:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 02:57:10 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.fb76a78b9463141fc34713093c890f77@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: chessai Type: feature request | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): Replying to [comment:10 monoidal]: > The commit was pushed to ghc master branch (that will become 8.8 in the future). > > Initially, I marked this ticket as 'merge' which means it would be a candidate for cherrypicking to the ghc-8.6 branch (at that time, that was the branch that would become 8.6.2). However, before the commit was pushed to ghc-8.6, #15702 was reported. Seeing that we might have a potentially breaking regression, I removed the 'merge' status so that the commit won't be put in 8.6.2. > > I didn't revert the commit, as there was no hurry and I hoped there would be a larger discussion about solutions at #15702. If nothing happens, I'll revert the commit; please speak up if you're interested in a different solution. Ah, okay, thank you. This clears up our confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 07:01:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 07:01:48 -0000 Subject: [GHC] #15887: It would be very nice to have a better GHCi editing experience Message-ID: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> #15887: It would be very nice to have a better GHCi editing experience -------------------------------------+------------------------------------- Reporter: Anchpop | Owner: (none) Type: feature | Status: new request | Priority: high | Milestone: Research needed Component: Compiler | Version: 8.6.2 Keywords: QoL | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a two annoyances when writing Haskell code in GHCi which I will enumerate here. While minor, I think if these were fixed there would be a marked improvement of the GHCi editing experience. 1) Syntax/Keyword Highlighting. Haskell has some very common keywords. Simply writing `if`, `then`, `else`, `where`, `do`, etc. in some color other than the default when not inside a string literal would be a huge improvement in my opinion, and might not be very difficult. 2) Multiline editing Writing multiline expressions in Haskell is somewhat difficult for four reasons. Firstly, to even start a multiline expression you must enter `:{` end end it with `:}`. Secondly, GHCi does not attempt to automatically indent your code, which is usually (always?) required when writing a multiline expression. Thirdly, you cannot navigate the curor to previous lines to edit them. Lastly, pressing the up arrow on the keyboard shows the last line of the multiline expression which is useless because it's almost always `:}`. My proposal is as follows. 1) The issue of how to enter multiline mode without needing to enter `:{` and exit it without needing `:}`. Instead of entering multiline mode only when the user enters `:{`, we add the following additional criteria. When I discuss haskell keywords in here, assume I mean "while not in a string literal". a) When the input code contains an odd number of unescaped quotation marks and ends in a backslash. b) When the input code ends with `where`, `let`, `in`, `if`, `then`, `else`, `do`, `of`, `case`, or `->` preceeded by and in the same level of parenthetical nesting of `case`. c) When the input code contains a `let` that is not eventually followed by `in`, an `if` not followed by `then`, or a `then` not followed by `else`. d) When the input code contains a `case` followed by `of`, not enclosed by parentheses. e) When the input code contains a `[` that is not followed by a `]`, or an `(` that is not followed by a `)`. f) When the input starts with two or more consecutive space- seperated tokens that do not contain haskell keywords (other than the backtick) followed by `=`. g) i) When the input contains a single token that is not a haskell keyword, followed by `::`, ending in `=>` or `->`. ii) When the input contains a single token that is not a haskell keyword, followed by `::`, not ending in `=>` or `->`. e) When the user hits `shift-return` instead of simply `return`, or hits `return` when there are non-whitespace characters after the cursor. This should cover the majority of cases where it can be safely assumed one would want to enter multiline mode. Criterion f is intended to enter multiline mode when defining any function, to make it simple to define functions that use pattern matching. Criterion g is to make it simple to place a function signature right above a function definition. In situations where multiline mode was not entered with `:{`, you should be able to exit it and submit your code to GHCi for execution by pressing `return` twice, or `meta-return`. 2) The issue of GHCi not attempting to indent your code. How to indent depends on the reason GHCi entered multiline mode. If GHCi entered multiline mode because the user entered `:{`, no indentation should take place. If the user is in multiline mode but their code does not match criteria a-f, the default indentation should be the same as the indentation on the previous line. If the line is just whitespace and the user presses enter, indentation should be the same as the previous line. For criteria a-f, here is how to respond (I've ordered these from greatest to least precedence I think they should take, but I could be entirely wrong here). a) Indent to the same column as the last unescaped quotation mark. For bonus points add a backslash too. b) Indent to two columns as the token that caused the activation of multiline mode. c) Indent to the same column as the token that caused the activation of multiline mode. d) Indent to the character after the final `of` not contained in parentheses e) Indent to the column of the next non-whitespace character after `(` or `[`, if one exists. Otherwise, indent one column farther than the `(`/`[`. f) No indentation. g) i) Indent to the column of the first non- whitespace character after the `::` ii) No indentation. e) No indentation If the user is not editing the last line, use the code up to the point of their cursor for advice on how to indent. 3) The issue of not being able to navigate the curor to previous lines in order to edit them when in multiline editing mode. I think this would require a complete rewrite of the user interface for multiline editing, and I anticipate it would be the hardest part of this whole endevor. I don't have the knowledge to suggest how one might go about implementing it, though. If possible, pressing ctrl-c should cancel the current code and make a new `Prelude> ` prompt. 4) The issue of pressing `up` only displaying one line at a time. See above. I would be happy to try to implement some of these, but I have never contributed to GHC or GHCi before and would need some pointers on where to start (Either in here or in the #ghc irc channel). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 07:02:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 07:02:04 -0000 Subject: [GHC] #15887: Ideas for a better GHCi editing experience (was: It would be very nice to have a better GHCi editing experience) In-Reply-To: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> References: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> Message-ID: <061.72216e0736b41c6548bdbdc0c515f196@haskell.org> #15887: Ideas for a better GHCi editing experience -------------------------------------+------------------------------------- Reporter: Anchpop | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Research | needed Component: Compiler | Version: 8.6.2 Resolution: | Keywords: QoL 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 Sun Nov 11 13:04:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 13:04:12 -0000 Subject: [GHC] #12525: Internal identifiers creeping into :show bindings In-Reply-To: <044.1bd8a372e3005251359006b86de7988e@haskell.org> References: <044.1bd8a372e3005251359006b86de7988e@haskell.org> Message-ID: <059.a4b3d0a6d88f116daf282592d997351e@haskell.org> #12525: Internal identifiers creeping into :show bindings -------------------------------------+------------------------------------- Reporter: mniip | Owner: RolandSenn Type: bug | Status: new Priority: low | Milestone: Component: GHCi | 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 13:30:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 13:30:19 -0000 Subject: [GHC] #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s In-Reply-To: <042.bdc5ad3927502391eb42801db38e8cb4@haskell.org> References: <042.bdc5ad3927502391eb42801db38e8cb4@haskell.org> Message-ID: <057.b3bd86095bd29708b4384474009a9e56@haskell.org> #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: make test valid program | TEST=T11647 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5162 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"400f3ed8ca830513ac6870d28bf46ed6b6bb720b/ghc" 400f3ed/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="400f3ed8ca830513ac6870d28bf46ed6b6bb720b" GHCi does not need a main function Summary: In GHCi we don't check anymore, whether a main function is exported. Test Plan: make test TEST=T11647 Reviewers: hvr, osa1, monoidal, mpickering, bgamari Reviewed By: osa1, mpickering Subscribers: rwbarton, carter GHC Trac Issues: #11647 Differential Revision: https://phabricator.haskell.org/D5162 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 13:30:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 13:30:19 -0000 Subject: [GHC] #15611: scope errors lie about what modules are imported In-Reply-To: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> References: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> Message-ID: <059.b91623617b6fa06cc00a114278407178@haskell.org> #15611: scope errors lie about what modules are imported -------------------------------------+------------------------------------- Reporter: dmwit | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST="T15611a T15611b" Blocked By: | Blocking: Related Tickets: #14225 | Differential Rev(s): Phab:D5284 Wiki Page: | Phab:D5308 -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"98f8e1c2454b8c99cbb225e4a8a544288eeb082a/ghc" 98f8e1c2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="98f8e1c2454b8c99cbb225e4a8a544288eeb082a" Respect naming conventions in module RnUnbound.hs in fix for #15611 Summary: The patch https://phabricator.haskell.org/D5284 didn't respect the local naming conventions in module compiler/rename/RnUnbound.hs: - Top level functions names are written in camelCase. - Local function names in where clauses are written as names_with_underscores. This patch restores these conventions. Test Plan: make test TESTS="T15611a T15611b" Reviewers: DavidEichmann, monoidal, hvr, mpickering, bgamari Reviewed By: mpickering Subscribers: rwbarton, carter GHC Trac Issues: #15611 Differential Revision: https://phabricator.haskell.org/D5308 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 13:33:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 13:33:28 -0000 Subject: [GHC] #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s In-Reply-To: <042.bdc5ad3927502391eb42801db38e8cb4@haskell.org> References: <042.bdc5ad3927502391eb42801db38e8cb4@haskell.org> Message-ID: <057.3dadd9cf7816c51c89a06640e5a57069@haskell.org> #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: make test valid program | TEST=T11647 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5162 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 13:33:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 13:33:59 -0000 Subject: [GHC] #15611: scope errors lie about what modules are imported In-Reply-To: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> References: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> Message-ID: <059.4c64af4b6bbc1b15bd227e27777bc449@haskell.org> #15611: scope errors lie about what modules are imported -------------------------------------+------------------------------------- Reporter: dmwit | Owner: RolandSenn Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST="T15611a T15611b" Blocked By: | Blocking: Related Tickets: #14225 | Differential Rev(s): Phab:D5284 Wiki Page: | Phab:D5308 -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 14:38:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 14:38:32 -0000 Subject: [GHC] #15854: PPC: Panic in native code generator In-Reply-To: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> References: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> Message-ID: <062.4eda1e266d7c6c379e0d811f755ef9f8@haskell.org> #15854: PPC: Panic in native code generator ----------------------------------------+--------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:5300 Wiki Page: | ----------------------------------------+--------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:5300 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 14:44:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 14:44:10 -0000 Subject: [GHC] #15887: Ideas for a better GHCi editing experience In-Reply-To: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> References: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> Message-ID: <061.1d15568883d4ef2be0e772393d4346ad@haskell.org> #15887: Ideas for a better GHCi editing experience -------------------------------------+------------------------------------- Reporter: Anchpop | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Research | needed Component: Compiler | Version: 8.6.2 Resolution: | Keywords: QoL Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Can you show an interactive interpreter for some other language that does what you want? Navigating a multi-line text - that's the task of an editor. Syntax highlighting and indentation - that's the task of an IDE. It sounds as if you're suggesting to build a terminal based IDE, and include it with ghci. I think it's more manageable to do this the other way around (some editor connects to ghci) - and there are projects that do this, e.g., https://github.com/alanz/haskell-lsp When I use ghci, and I notice that lines get too long, I first try to break them up by using (one-line) definitions (let foo = expression) in ghci, and if I'm collecting too many of these, I write them into a file. That way, I can edit them better, and I can keep them. Your proposal would improve on "edit them better", but not on extra functionality (write to file). Oh, and I never really need syntax highlighting, There are not that many keywords, and I rarely use them. First-order languages rely on keywords (e.g., while) for control flow. But this is Haskell, and I more often use map, fold, traverse, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 15:21:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 15:21:28 -0000 Subject: [GHC] #15887: Ideas for a better GHCi editing experience In-Reply-To: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> References: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> Message-ID: <061.b0c7a187dc5251982706fc16c2463774@haskell.org> #15887: Ideas for a better GHCi editing experience -------------------------------------+------------------------------------- Reporter: Anchpop | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Research | needed Component: Compiler | Version: 8.6.2 Resolution: | Keywords: QoL Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Anchpop): https://github.com/prompt-toolkit/ptpython has all the features I described here (video at https://youtu.be/XDgIDslyAFM?t=4 ). While the features might be common in IDEs, that doesn't mean they would be useless in GHCi. I miss having these features every time I use GHCi. Another benefit is that it would be easier for beginners to learn. Imagine a beginner enters the following: Prelude> myHead [] = Nothing Prelude> myHead (x:xs) = Just x They'll be left scratching their head after their program crashes when they enter `myHead []`! My suggestion would have their `myHead` first definition automatically trigger multiline mode, so they could easily continue pattern matching. Teaching beginners about `:{` adds complexity and clutter to a language as simple and intuitive as Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 16:42:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 16:42:05 -0000 Subject: [GHC] #15854: PPC: Panic in native code generator In-Reply-To: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> References: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> Message-ID: <062.a7342bac4166bc433ab0c505c3ce4263@haskell.org> #15854: PPC: Panic in native code generator ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5300 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by potato44): * differential: Phab:5300 => Phab:D5300 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 18:13:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 18:13:27 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.006186af32d65eb538ef23a915e5618a@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 #15867 | Differential Rev(s): Phab:D5324 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => patch * differential: => Phab:D5324 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 20:12:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 20:12:42 -0000 Subject: [GHC] #15887: Ideas for a better GHCi editing experience In-Reply-To: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> References: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> Message-ID: <061.68bd5d4978ce007c3fe889c7642f51f4@haskell.org> #15887: Ideas for a better GHCi editing experience -------------------------------------+------------------------------------- Reporter: Anchpop | Owner: (none) Type: feature request | Status: closed Priority: high | Milestone: Research | needed Component: Compiler | Version: 8.6.2 Resolution: invalid | Keywords: QoL Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Thanks, Anchpop, for a detailed description of how you see this feature working. While one can always debate minutiae, I agree that a design such as you suggest would be nice to use and would aid beginners. However, I agree with comment:2 that these features are better suited to tools outside of GHCi. Furthermore, implementing these would be quite an engineering challenge, as it fundamentally changes the way that GHCi interacts with the user. In the end, the GHC API is expressive enough that you (or anyone) could write an alternative to GHCi, with all the features GHCi has, but with this (or other) interface. If you're keen to pursue this, the best avenue is to make an official proposal at https://github.com/ghc-proposals/ghc-proposals (indeed, a little tweaking of your original message could form such a proposal), as that's the place where any changes to the way GHC works are considered. My guess is that you'll receive a negative reaction there (not to the interaction design itself, but to the fact that it would be in GHCi), but I could well be wrong. In the meantime, I will close this ticket, as this really would need to go through the proposals process before we take action on it. If a proposal is accepted, perhaps this ticket can be reopened. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 20:17:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 20:17:17 -0000 Subject: [GHC] #15810: Kind inference error in classes In-Reply-To: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> References: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> Message-ID: <062.b6c0ce1ecb01c5bc9274f59a860ed6bf@haskell.org> #15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 RyanGlScott): That change does indeed appear to fix the issue when I tried it. Only one test case seems to regress with this change: {{{#!diff diff -uw "polykinds/T7328.run/T7328.stderr.normalised" "polykinds/T7328.run/T7328.comp.stderr.normalised" --- polykinds/T7328.run/T7328.stderr.normalised 2018-11-11 15:15:40.843707612 -0500 +++ polykinds/T7328.run/T7328.comp.stderr.normalised 2018-11-11 15:15:40.843707612 -0500 @@ -1,6 +1,6 @@ T7328.hs:8:34: - Occurs check: cannot construct the infinite kind: k1 ~ k0 -> k1 + Occurs check: cannot construct the infinite kind: k00 ~ k0 -> k00 In the first argument of ‘Foo’, namely ‘f’ In the first argument of ‘Proxy’, namely ‘(Foo f)’ In the type signature: foo :: a ~ f i => Proxy (Foo f) }}} I can't tell if this is expected behavior or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 20:31:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 20:31:42 -0000 Subject: [GHC] #15810: Kind inference error in classes In-Reply-To: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> References: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> Message-ID: <062.896973fcdce6cef91f88597bf4051fa1@haskell.org> #15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): Very strange output. But I wouldn't put much effort here. Simon has a Big Patch (Phab:D5305) that may include this fix, as it's utterly rewriting all the functions involved in this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 21:17:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 21:17:37 -0000 Subject: [GHC] #12525: Internal identifiers creeping into :show bindings In-Reply-To: <044.1bd8a372e3005251359006b86de7988e@haskell.org> References: <044.1bd8a372e3005251359006b86de7988e@haskell.org> Message-ID: <059.174052c1886f15f9bcea782629a67172@haskell.org> #12525: Internal identifiers creeping into :show bindings -------------------------------------+------------------------------------- Reporter: mniip | Owner: RolandSenn Type: bug | Status: patch Priority: low | Milestone: 8.8.1 Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: make test performance bug | TEST=T12525 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5326 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => make test TEST=T12525 * differential: => Phab:D5326 * milestone: => 8.8.1 Comment: @simonpj: Many thanks for your kind and helpful hint in [https://ghc.haskell.org/trac/ghc/ticket/12525#comment:1 comment 1]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 11 23:51:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Nov 2018 23:51:02 -0000 Subject: [GHC] #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types In-Reply-To: <050.dcd9c09929690220037b43a75f3ae198@haskell.org> References: <050.dcd9c09929690220037b43a75f3ae198@haskell.org> Message-ID: <065.0c1d8adc53b0fd51887d0f44dd9c726b@haskell.org> #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: | -------------------------------------+------------------------------------- Comment (by carter): reproducing my remarks from email off hand, once we're in in viewpattern/ pattern synonym land, ORDER of the abstracted constructors matters! consider `foo,bar,baz,quux,boom :: Nat -> String` plus some pattern synonyms i name "PowerOfTwo", "Even" and "Odd" {{{ foo (PowerOfTwo x) = "power of two" foo (Even x) = "even" foo (Odd x) = "odd" bar (Even x) = "even" bar (Odd x) = "odd" baz (PowerOfTwo x) = "power of two" baz (Odd x) = "odd" quux (Even x) = "even" quux (Odd x) = "odd" quux (PowerOfTwo) = "power of two" boom (Even x) = "even" boom (PowerOfTwo x) = "power of two" boom (Odd x) = "odd" }}} `foo` and `bar` are both total definitions with unambiguous meanings, even though `bar`'s patterns are a suffix of `foos`! `baz` is partial! both boom and quux have a redudant overlapping case, power of two! so some thoughts 1) order matters! 2) pattern synonyms at type T are part of an infinite lattice, Top element == accept everything, Bottom element = reject everything 3) `PowerOfTwo` <= `Even` in the Lattice of patterns for `Natural`, both are "incomparable" with `Odd` 4) {{{ for a simple case on a single value at type T, assume c1 <= c2 , then if c1 x -> ... is before c2 x -> in the cases, then both are useful/computationally meaningful / not irrelevant OTHERWISE when its roughly case x :: T of c2 x -> ... c1 x -> ... then the 'c1 x' is redundant }}} this is slightly orthogonal to other facets of this discussion so far, but i realized that Richard's Set of Sets of patterns model misses some useful/ meaningful examples/extra structure from a) the implicit lattice of different patterns possibly being super/subsets (which is still something of an approximation, but with these example I shared above I hope i've sketched out some motivation ) b) we can possibly model HOW ordering of clauses impacts coverage/totality / redundancy of clauses I'm not sure if it'd be pleasant/good from a user experience perspective to have this sort of partial ordering modelling stuff, but certainly seems like it would help distinguish some useful examples where the program meaning / coverage is sensitive to clause ordering i can try to spell this out more if theres interest, but I wanted to share while the iron was hot best! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 02:30:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 02:30:40 -0000 Subject: [GHC] #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types In-Reply-To: <050.dcd9c09929690220037b43a75f3ae198@haskell.org> References: <050.dcd9c09929690220037b43a75f3ae198@haskell.org> Message-ID: <065.d390840531c70349aae4e75b82130309@haskell.org> #15885: Enhancing COMPLETE pragma to support pattern synonyms with polymorphic (output) types -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: | -------------------------------------+------------------------------------- Comment (by goldfire): I think this would have to be a [https://github.com/ghc-proposals/ghc- proposals ghc-proposal], no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 03:38:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 03:38:36 -0000 Subject: [GHC] #15852: Bad axiom produced for polykinded data family In-Reply-To: <047.481c46c837c01249db862f276fa4c502@haskell.org> References: <047.481c46c837c01249db862f276fa4c502@haskell.org> Message-ID: <062.e496f0561cbee8d2620d273d0486e794@haskell.org> #15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies, | 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): My pointing to `pprCoAxiom` was from its use in `TcRnDriver.ppr_tycons`. Given the appearance of `"COERCION AXIOMS"` in `ppr_tycons`, I thought it was what produced the output I saw, which also contains that string. Maybe I missed a beat somewhere, but I think you may be barking up the wrong tree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 03:39:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 03:39:54 -0000 Subject: [GHC] #15594: --abi-hash with Backpack incorrectly loads modules from dependent packages In-Reply-To: <045.e21f2218ffe754afd2fc42b07fceb19f@haskell.org> References: <045.e21f2218ffe754afd2fc42b07fceb19f@haskell.org> Message-ID: <060.31ecfd3fecc6f49e62b4ac1ca2dc8194@haskell.org> #15594: --abi-hash with Backpack incorrectly loads modules from dependent packages -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D5123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"13ff0b7ced097286e0d7b054f050871effe07f86/ghc" 13ff0b7c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13ff0b7ced097286e0d7b054f050871effe07f86" Fix #15594 (--abi-hash with Backpack sometimes fails) Summary: For holes, its necessary to "see through" the instantiation of the hole to get accurate family instance dependencies. For example, if B imports , and is instantiated with F, we must grab and include all of the dep_finsts from F to have an accurate transitive dep_finsts list. However, we MUST NOT do this for regular modules. First, for efficiency reasons, doing this bloats the the dep_finsts list, because we *already* had those modules in the list (it wasn't a hole module, after all). But there's a second, more important correctness consideration: we perform module renaming when running --abi-hash. In this case, GHC's contract to the user is that it will NOT go and read out interfaces of any dependencies (https://github.com/haskell/cabal/issues/3633); the point of --abi-hash is just to get a hash of the on-disk interfaces for this *specific* package. If we go off and tug on the interface for /everything/ in dep_finsts, we're gonna have a bad time. (It's safe to do do this for hole modules, though, because the hmap for --abi-hash is always trivial, so the interface we request is local. Though, maybe we ought not to do it in this case either...) Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: alexbiehl, goldfire, bgamari Subscribers: ppk, shlevy, rwbarton, carter GHC Trac Issues: #15594 Differential Revision: https://phabricator.haskell.org/D5123 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 03:45:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 03:45:12 -0000 Subject: [GHC] #15886: Spurious warning about incomplete pattern with PatternSynonyms In-Reply-To: <047.982b8cd6c6924b286d997c8f65068fc4@haskell.org> References: <047.982b8cd6c6924b286d997c8f65068fc4@haskell.org> Message-ID: <062.96c13d1db6a62d2603581b22ec72df9b@haskell.org> #15886: Spurious warning about incomplete pattern with PatternSynonyms -------------------------------------+------------------------------------- Reporter: selinger | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1 Resolution: invalid | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Is it worth pondering the utility of inferring a `COMPLETE` for an obviously-total pattern synonym? That is, GHC looks at the patsyn definition, sees that it's total (by doing its normal pattern-match completeness check) and then marks the patsyn as complete. This doesn't violate abstraction -- it's just a little more inference magic. Indeed, this idea could be expanded, allowing you to tell GHC that you expect a certain set of pattern synonyms to be complete, asking GHC to check for you. For example: {{{#!hs patterns where -- silly hypothetical syntax Some x = Just x None = Nothing }}} GHC would check these, notice that they're complete, and then pretend as if someone had said `{-# COMPLETE Some, None #-}`. If they're not complete, and we're warning about patterns, then issue a warning. I don't care enough about this to write, defend, etc., a proposal on the subject, but perhaps you (for any value of "you") do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 04:04:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 04:04:55 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.9ee2907e30cfa0408ff768a3a7b25ca0@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer 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 osa1): I think profiled GHC may not help that much because we already have a good idea of what's going wrong. I'd print `litI` and `litE` in the desugaring code you showed in comment:46 and see if any of the integers are huge. Remember that the root cause is that we build huge integers in compile time and we're trying to avoid that. If this is still taking too long then we somehow still build huge integers in compile time. Given that we only build two integers, one them them should be the culprit. Printing would show us which one, and then we can figure out the rest. Can you push your code on a git repo and give us the remote/branch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 04:13:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 04:13:23 -0000 Subject: [GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags In-Reply-To: <042.e68200604de67ef001a98aff36406689@haskell.org> References: <042.e68200604de67ef001a98aff36406689@haskell.org> Message-ID: <057.40bf66f35fda6f5e8d84c9d1316f82c3@haskell.org> #14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5318 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Phab:D5318 implements (2) by passing user-provided flags last, which I think is a good way to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 04:17:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 04:17:32 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.4d11b39bc86f26515bbe805beb877136@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new 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:D5232 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"d30352add1da67dd0346613853cd423c7becbaeb/ghc" d30352a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d30352add1da67dd0346613853cd423c7becbaeb" Remove StgBinderInfo and related computation in CoreToStg - The StgBinderInfo type was never used in the code gen, so the type, related computation in CoreToStg, and some comments about it are removed. See #15770 for more details. - Simplified CoreToStg after removing the StgBinderInfo computation: removed StgBinderInfo arguments and mfix stuff. The StgBinderInfo values were not used in the code gen, but I still run nofib just to make sure: 0.0% change in allocations and binary sizes. Test Plan: Validated locally Reviewers: simonpj, simonmar, bgamari, sgraf Reviewed By: sgraf Subscribers: AndreasK, sgraf, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5232 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 04:27:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 04:27:53 -0000 Subject: [GHC] #15888: Quantified constraints can be loopy Message-ID: <047.742c06cb927e886373872952efcc0dda@haskell.org> #15888: Quantified constraints can be loopy -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this abuse: {{{#!hs {-# LANGUAGE QuantifiedConstraints, UndecidableInstances #-} module Bug where data T1 a data T2 a class C a where meth :: a instance (forall a. C (T2 a)) => C (T1 b) where meth = error "instance T1" instance (forall a. C (T1 a)) => C (T2 b) where meth = error "instance T2" example :: T1 Int example = meth }}} GHC says {{{ • Reduction stack overflow; size = 201 When simplifying the following type: C (T1 a) 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 expression: meth In an equation for ‘example’: example = meth }}} Of course, I've taken on some responsibility for my actions here by saying `UndecidableInstances`, but GHC really should be able to figure this out. Here's what's happening: 1. We get a Wanted `C (T1 Int)`. 2. GHC chooses the appropriate instance, emitting a Wanted `forall a. C (T2 a)`. 3. GHC skolemizes the `a` to `a1` and tries solve a Wanted `C (T2 a1)`. 4. GHC chooses the appropriate instance, emitting a Wanted `forall a. C (T1 a)`. 5. GHC skolemizes the `a` to `a2` and tries to solve a Wanted `C (T1 a2)`. And around and around we go. (This loop is guessed at from knowing GHC's algorithms in general. I did not look at a trace.) We ''could'' get this one, though. Before skolemizing, we could stash the Wanted in the `inert_solved_dicts`, which is where we record uses of top- level instances. (See `Note [Solved dictionaries]` in TcSMonad.) Then, later, when we see the same Wanted arise again, we would just use the cached value, making a well-formed recursive dictionary. This deficiency was discovered in `singletons` (https://github.com/goldfirere/singletons/issues/371). Perhaps that's not "the wild", but it's not quite contrived either. Note that we don't need two datatypes to trigger this, but having one recursive instance like this seems awfully silly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 04:29:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 04:29:36 -0000 Subject: [GHC] #15880: GHC.Stats: Add info on amount of pinned memory In-Reply-To: <042.9d78ca0973e77e7163814c454c8c3fd9@haskell.org> References: <042.9d78ca0973e77e7163814c454c8c3fd9@haskell.org> Message-ID: <057.5cead2339476147cb41a4f9fa2e16ee3@haskell.org> #15880: GHC.Stats: Add info on amount of pinned memory -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Runtime System | Version: 8.6.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 osa1): To answer the questions: - `gcdetails_mem_in_use_bytes` is simply `mblocks_allocated * MBLOCK_SIZE`. Because pinned memory is also allocated via the block allocator `gcdetails_mem_in_use_bytes` includes pinned memory too. - I don't understand this question. - You'd need to compute this. In the GC once a pinned object block is filled we only distinguish a pinned object block from a large object block in one place, to avoid scavenging pinned blocks. So there's no special accounting for pinned objects. Perhaps you could implement something like `calcTotalLargeObjectsW` by checking if a `BF_LARGE` block is also `BF_PINNED`. If it is then add number of blocks to a counter. Then `num_of_blocks * BLOCK_SIZE` gives you the bytes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 04:37:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 04:37:21 -0000 Subject: [GHC] #15887: Ideas for a better GHCi editing experience In-Reply-To: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> References: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> Message-ID: <061.f55ea086d1709d398a72cda1b650397a@haskell.org> #15887: Ideas for a better GHCi editing experience -------------------------------------+------------------------------------- Reporter: Anchpop | Owner: (none) Type: feature request | Status: closed Priority: high | Milestone: Research | needed Component: Compiler | Version: 8.6.2 Resolution: invalid | Keywords: QoL Operating System: 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): Another good repl that you may want to look at as an inspiration is utop (for OCaml). It has syntax highlighting (disabled by default) and good multi-line support (although the support for multi-line is mostly thanks to OCaml's syntax, not entirely something the utop solves). It also shows possible completions as you type always, which is a feature unique to utop, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 04:41:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 04:41:16 -0000 Subject: [GHC] #15054: ghc internal error appeared in GHCI In-Reply-To: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> References: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> Message-ID: <060.6c2025517ef382674697ca3e382403dc@haskell.org> #15054: ghc internal error appeared in GHCI -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger 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 osa1): > Is it possible that this happened during idle GC ("while no query was being evaluated")? You can check this by disabling idle GC (`+RTS -I0`), but I don't know how relevant this information is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 05:11:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 05:11:28 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.d4e215c364c9abc2dfde36ea5d91d977@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 #15867 | Differential Rev(s): Phab:D5324 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Note that Phab:D5324 does not address comment:10, which we may want to track in another ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 07:47:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 07:47:39 -0000 Subject: [GHC] #15852: Bad axiom produced for polykinded data family In-Reply-To: <047.481c46c837c01249db862f276fa4c502@haskell.org> References: <047.481c46c837c01249db862f276fa4c502@haskell.org> Message-ID: <062.8a7c1a17ca8159963bfaf9b83300a210@haskell.org> #15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies, | 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): Oh dear. Yes, I //was// barking up the wrong tree—thank you for setting me straight. Now that I dig closer into `ppr_co_axiom_branch` (which is the real culprit), I now understand what went wrong. When implementing `etaExpandFamInstLHS`, I left [http://git.haskell.org/ghc.git/blob/d30352add1da67dd0346613853cd423c7becbaeb:/compiler/types/Type.hs#l3067 this comment]: {{{#!hs -- @Note [Eta reduction for data families]@ in "FamInstEnv". Because the -- right-hand side is where the eta-reduced variables are obtained from, it -- is not returned from this function (as there is never a need to modify it). }}} In retrospect, I have no idea what I was smoking when I wrote this comment, because it's completely wrong. The right-hand side //is// eta- reduced, and that's what we're seeing in `-ddump-tc`. (Moreover, we aren't obtaining the eta-reduced variables from the RHS at all. They're actually being taken from the `tyConTyVars` of the representation `TyCon`.) This suggests a straightforward fix: just eta expand the RHS as well, and return that from `etaExpandFamInstLHS` (or really, it just should be called `etaExpandFamInst`). I'll give that a shot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 08:34:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 08:34:16 -0000 Subject: [GHC] #15832: fprintCCS_stderr (+RTS -xc) should be able to traverse into stacks that evaluated a given stack even if the latter does not come from a CAF In-Reply-To: <048.4f171325e6580b41c039ea3becfab225@haskell.org> References: <048.4f171325e6580b41c039ea3becfab225@haskell.org> Message-ID: <063.c3213fb03ece266e4778f4fc19032193@haskell.org> #15832: fprintCCS_stderr (+RTS -xc) should be able to traverse into stacks that evaluated a given stack even if the latter does not come from a CAF -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 09:18:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 09:18:30 -0000 Subject: [GHC] #15809: Use level numbers for generalisation In-Reply-To: <046.a6e0ab66a770cc4806a0fa3da3482ff2@haskell.org> References: <046.a6e0ab66a770cc4806a0fa3da3482ff2@haskell.org> Message-ID: <061.1866326107c656af74b5d5859c993510@haskell.org> #15809: Use level numbers for generalisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): The evolving patch for this ticket also fixes #15810 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 12:11:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 12:11:18 -0000 Subject: [GHC] #15852: Bad axiom produced for polykinded data family In-Reply-To: <047.481c46c837c01249db862f276fa4c502@haskell.org> References: <047.481c46c837c01249db862f276fa4c502@haskell.org> Message-ID: <062.bedb71ba4461bd0c966aaf3b41796fb2@haskell.org> #15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5328 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5328 * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 15:16:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 15:16:16 -0000 Subject: [GHC] #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.04773817e7b79dc227b911f4ed3c2663@haskell.org> #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): As it came up in a discussion: The overflow check present in the RTS fails for a value of -2287728808. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 16:44:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 16:44:10 -0000 Subject: [GHC] #15740: Type family with higher-rank result is too accepting In-Reply-To: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> References: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> Message-ID: <062.cc38a6ad09888a180d2b288e37b221e8@haskell.org> #15740: Type family with higher-rank result is too accepting -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15793 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon appears to have stumbled upon this separately, in his ongoing work captured in Phab:D5305. The fix appears to be a small change to `kcTyFamEqnRhs` to instantiate only invisible arguments that are within the arity of the tyfam; right now, it wrongly instantiates ''all'' invisible arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 17:13:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 17:13:22 -0000 Subject: [GHC] #15810: Kind inference error in classes In-Reply-To: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> References: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> Message-ID: <062.c8519086b44d63c7405b2e9962578ab6@haskell.org> #15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): Phab:D5305 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D5305 Comment: See comment:2:ticket:15809. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 17:22:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 17:22:28 -0000 Subject: [GHC] #15809: Use level numbers for generalisation In-Reply-To: <046.a6e0ab66a770cc4806a0fa3da3482ff2@haskell.org> References: <046.a6e0ab66a770cc4806a0fa3da3482ff2@haskell.org> Message-ID: <061.9f5c5f051990209142fe8b3ec7fd977a@haskell.org> #15809: Use level numbers for generalisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): And #15740 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 19:35:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 19:35:36 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.d6bc9ed8c7ea8d7bdcd46678599467a5@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Discussion this morning essentially agreed with my "first instinct" above. But with a new spin on things: The `tcm_smart` setting on `TyCoMapper` is really about what to do about `Refl` casts. Do we preserve them? Discard them? Or, in our new mode, discard some of them? Previously, the "dumb" mode meant to preserve all casts. This is important for `Note [The well- kinded type invariant]` (where we sometimes use reflexive casts to make a type's kind looked zonked even when the type is not yet zonked). The "smart" mode dropped all reflexive casts. Now, we want a third mode that drops all casts that look reflexive to the type checker. By elucidating what we really mean by "smart", having a third setting does not look so unusual, after all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 21:12:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 21:12:32 -0000 Subject: [GHC] #15769: GHC 8.6 for macOS depends on homebrew In-Reply-To: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> References: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> Message-ID: <067.8930110260a7978e6accec9570944894@haskell.org> #15769: GHC 8.6 for macOS depends on homebrew -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #15404 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #15404 Comment: This is a duplicate of #15404, which was fixed in 8.6.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 21:18:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 21:18:07 -0000 Subject: [GHC] #14225: "No module named ... is imported" message is a bit misleading with qualified imports In-Reply-To: <046.66ec7009ab5b4f5d3b72af6d147f4e53@haskell.org> References: <046.66ec7009ab5b4f5d3b72af6d147f4e53@haskell.org> Message-ID: <061.cdfc286183e18fdd34676b1de58da9fc@haskell.org> #14225: "No module named ... is imported" message is a bit misleading with qualified imports -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14225 Blocked By: | Blocking: Related Tickets: #15611 | Differential Rev(s): Phab:D5331 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => make test TEST=T14225 * differential: => Phab:D5331 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 21:49:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 21:49:04 -0000 Subject: [GHC] #15889: ghc documentation doesn't explain difference between dwarf levels 1 2 and 3 Message-ID: <045.ab3fe7a26edf38924c1d1e51505427fa@haskell.org> #15889: ghc documentation doesn't explain difference between dwarf levels 1 2 and 3 -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Documentation | Version: 8.6.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: -------------------------------------+------------------------------------- I tried digging into current ghc source (well a 8.6.2 checkout) to track down where / how `debugLevel` crops up. The docs/examples support g0 (off ) through g3. But when looking at where debugLevel appears in code, there isn't any different currently at the GHC layer for g3 vs g2! (is there a difference at the C compiler layer?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 21:50:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 21:50:05 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.df9db9bbf36e97775c5dc79117a8a4df@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): @Ben I just tried applying the diff from https://phabricator.haskell.org/D4781 on my mac... and it doesn't seem to work .. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 21:50:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 21:50:24 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.09d5183b07be2fd2ccb1081ff02ce323@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): this was on top of the current 8.6 branch as of today -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 12 23:51:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Nov 2018 23:51:33 -0000 Subject: [GHC] #15769: GHC 8.6 for macOS depends on homebrew In-Reply-To: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> References: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> Message-ID: <067.1660a719a7df4199eb182f61d24528ce@haskell.org> #15769: GHC 8.6 for macOS depends on homebrew -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #15404 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nshimaza): It seems binary distribution ghc-8.6.2-x86_64-apple-darwin.tar.xz still lacks intree-gmp. make install fails with the same error if /usr/local/opt/gmp/lib/libgmp.10.dylib is missing. {{{ "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /ghc-prim dist-install "strip" '' '/Users/nshimaza/Documents/Hack/haskell/tmp/inst' '/Users/nshimaza/Documents/Hack/haskell/tmp/inst/lib/ghc-8.6.2' '/Users/nshimaza/Documents/Hack/haskell/tmp/inst/share/doc/ghc-8.6.2/html/libraries' 'v p dyn' dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib Referenced from: /Users/nshimaza/Documents/Hack/haskell/tmp/ghc-8.6.2/libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.2.dylib Reason: image not found make[1]: *** [install_packages] Abort trap: 6 make: *** [install] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 00:13:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 00:13:47 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.8cd2e4fb0d8507a6889677ced1222596@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): in the middle of validating / checking a possibly slightly different patch that works Kavon on IRC asked if the issues between platforms and clang vs gcc etc could be resolved by moving the inline assembly into its own file. I think that might work and remove dependency on platform specific CPP about ASM encodings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 01:30:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 01:30:45 -0000 Subject: [GHC] #15769: GHC 8.6 for macOS depends on homebrew In-Reply-To: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> References: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> Message-ID: <067.ccdedf58113a034d888e42922c22d1f7@haskell.org> #15769: GHC 8.6 for macOS depends on homebrew -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #15404 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kazu-yamamoto): Ben, there were two issues. The first one (installation) was fixed in 8.6.2. But the second one was not. I cannot use GHC 8.6.2 without: {{{ % export LIBRARY_PATH=/usr/lib:/opt/local/lib }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 02:26:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 02:26:00 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.d872ccdc5c3d0942eff65268b36eb057@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): my build gets stuck at the following {{{ "inplace/bin/ghc-stage1" -this-unit-id rts -shared -dynamic -dynload deploy -no-auto-link-packages -Lrts/dist/build -lffi -optl-Wl,-rpath -optl-Wl, at loader_path `cat rts/dist/libs.depend` rts/dist/build/STM.dyn_o rts/dist/build/Timer.dyn_o rts/dist/build/ThreadPaused.dyn_o rts/dist/build/Ticky.dyn_o rts/dist/build/ThreadLabels.dyn_o rts/dist/build/RtsMain.dyn_o rts/dist/build/ProfilerReport.dyn_o rts/dist/build/PathUtils.dyn_o rts/dist/build/LibdwPool.dyn_o rts/dist/build/Proftimer.dyn_o rts/dist/build/CheckUnload.dyn_o rts/dist/build/fs.dyn_o rts/dist/build/OldARMAtomic.dyn_o rts/dist/build/HsFFI.dyn_o rts/dist/build/RtsDllMain.dyn_o rts/dist/build/RtsSymbolInfo.dyn_o rts/dist/build/RaiseAsync.dyn_o rts/dist/build/ProfHeap.dyn_o rts/dist/build/Schedule.dyn_o rts/dist/build/Hash.dyn_o rts/dist/build/Trace.dyn_o rts/dist/build/Threads.dyn_o rts/dist/build/Hpc.dyn_o rts/dist/build/Weak.dyn_o rts/dist/build/ProfilerReportJson.dyn_o rts/dist/build/Task.dyn_o rts/dist/build/StgCRun.dyn_o rts/dist/build/ClosureFlags.dyn_o rts/dist/build/RetainerProfile.dyn_o rts/dist/build/Libdw.dyn_o rts/dist/build/Stats.dyn_o rts/dist/build/Interpreter.dyn_o rts/dist/build/Messages.dyn_o rts/dist/build/RtsUtils.dyn_o rts/dist/build/RtsSymbols.dyn_o rts/dist/build/xxhash.dyn_o rts/dist/build/LdvProfile.dyn_o rts/dist/build/Capability.dyn_o rts/dist/build/Printer.dyn_o rts/dist/build/Globals.dyn_o rts/dist/build/Adjustor.dyn_o rts/dist/build/RtsAPI.dyn_o rts/dist/build/Inlines.dyn_o rts/dist/build/TopHandler.dyn_o rts/dist/build/Linker.dyn_o rts/dist/build/Disassembler.dyn_o rts/dist/build/WSDeque.dyn_o rts/dist/build/StaticPtrTable.dyn_o rts/dist/build/Pool.dyn_o rts/dist/build/StgPrimFloat.dyn_o rts/dist/build/FileLock.dyn_o rts/dist/build/RtsStartup.dyn_o rts/dist/build/RetainerSet.dyn_o rts/dist/build/Profiling.dyn_o rts/dist/build/Sparks.dyn_o rts/dist/build/RtsFlags.dyn_o rts/dist/build/RtsMessages.dyn_o rts/dist/build/Stable.dyn_o rts/dist/build/Arena.dyn_o rts/dist/build/Heap.dyn_o rts/dist/build/hooks/StackOverflow.dyn_o rts/dist/build/hooks/LongGCSync.dyn_o rts/dist/build/hooks/OnExit.dyn_o rts/dist/build/hooks/FlagDefaults.dyn_o rts/dist/build/hooks/MallocFail.dyn_o rts/dist/build/hooks/OutOfHeap.dyn_o rts/dist/build/sm/Scav_thr.dyn_o rts/dist/build/sm/Storage.dyn_o rts/dist/build/sm/Evac.dyn_o rts/dist/build/sm/Sanity.dyn_o rts/dist/build/sm/GC.dyn_o rts/dist/build/sm/MarkWeak.dyn_o rts/dist/build/sm/Evac_thr.dyn_o rts/dist/build/sm/BlockAlloc.dyn_o rts/dist/build/sm/GCUtils.dyn_o rts/dist/build/sm/GCAux.dyn_o rts/dist/build/sm/Sweep.dyn_o rts/dist/build/sm/CNF.dyn_o rts/dist/build/sm/Compact.dyn_o rts/dist/build/sm/Scav.dyn_o rts/dist/build/sm/MBlock.dyn_o rts/dist/build/eventlog/EventLog.dyn_o rts/dist/build/eventlog/EventLogWriter.dyn_o rts/dist/build/linker/elf_util.dyn_o rts/dist/build/linker/elf_reloc.dyn_o rts/dist/build/linker/LoadArchive.dyn_o rts/dist/build/linker/elf_plt_arm.dyn_o rts/dist/build/linker/SymbolExtras.dyn_o rts/dist/build/linker/CacheFlush.dyn_o rts/dist/build/linker/Elf.dyn_o rts/dist/build/linker/elf_got.dyn_o rts/dist/build/linker/M32Alloc.dyn_o rts/dist/build/linker/elf_plt_aarch64.dyn_o rts/dist/build/linker/elf_plt.dyn_o rts/dist/build/linker/PEi386.dyn_o rts/dist/build/linker/MachO.dyn_o rts/dist/build/linker/elf_reloc_aarch64.dyn_o rts/dist/build/posix/GetEnv.dyn_o rts/dist/build/posix/Select.dyn_o rts/dist/build/posix/Signals.dyn_o rts/dist/build/posix/TTY.dyn_o rts/dist/build/posix/Itimer.dyn_o rts/dist/build/posix/OSThreads.dyn_o rts/dist/build/posix/GetTime.dyn_o rts/dist/build/posix/OSMem.dyn_o rts/dist/build/Updates.dyn_o rts/dist/build/HeapStackCheck.dyn_o rts/dist/build/StgStdThunks.dyn_o rts/dist/build/Exception.dyn_o rts/dist/build/Apply.dyn_o rts/dist/build/StgMiscClosures.dyn_o rts/dist/build/Compact.dyn_o rts/dist/build/PrimOps.dyn_o rts/dist/build/StgStartup.dyn_o rts/dist/build/AutoApply.dyn_o -fPIC -dynamic -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist- derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -DDTRACE -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -fno-use-rpaths -o rts/dist/build/libHSrts-ghc8.6.2.dylib 0 0x10c2f3898 __assert_rtn + 129 1 0x10c30c983 mach_o::relocatable::Parser::parse(mach_o::relocatable::ParserOptions const&) + 3153 2 0x10c30274c mach_o::relocatable::Parser::parse(unsigned char const*, unsigned long long, char const*, long, ld::File::Ordinal, mach_o::relocatable::ParserOptions const&) + 282 3 0x10c35a12c ld::tool::InputFiles::makeFile(Options::FileInfo const&, bool) + 1014 4 0x10c35d4f7 ld::tool::InputFiles::parseWorkerThread() + 533 5 0x7fff59b6d661 _pthread_body + 340 6 0x7fff59b6d50d _pthread_body + 0 A linker snapshot was created at: /tmp/libHSrts-ghc8.6.2.dylib-2018-10-12-212259.ld-snapshot ld: Assertion failed: (cfiStartsArray[i] != cfiStartsArray[i-1]), function parse, file /Library/Caches/com.apple.xbs/Sources/ld64_Fall2018/ld64-409.12/src/ld/parsers/macho_relocatable_file.cpp, line 1939. collect2: error: ld returned 1 exit status `gcc-8' failed in phase `Linker'. (Exit code: 1) rts/ghc.mk:315: recipe for target 'rts/dist/build/libHSrts-ghc8.6.2.dylib' failed make[1]: *** [rts/dist/build/libHSrts-ghc8.6.2.dylib] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 }}} i tried out using LLVM 7's ld.lld tool, and i had the same problme/error there.. iVe 1-2 ideas left i'm going to try -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 03:15:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 03:15:48 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.1f332fe2ff93070cc9908d16c8c52f80@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): So a few things: ben's patch on phabricator is inccorect, it needs to be changed as follows {{{ -#if defined(__clang__) + #if !defined(__clang__) && defined(darwin_HOST_OS) #define NEED_EXPLICIT_CFI_START_END #endif }}} and the comment / explanation there is wrong the issue isn't building the file with CLANG. its building the inline asm with GCC, but using the OSX assembler. even with the above tweak (which isolates the change to OSX and using gcc there), linking the RTS including one of the STGCRUN object files triggers an Assert in the system linker, both the xcode 10 cli tools LD and the LLVM 7 LD (ld.lld) both have this validation aasert -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 03:16:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 03:16:31 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.64f27fc3570863c43b9fd5ad5488bc71@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * Attachment "fustratedSTGCRun.s" added. gcc's asssembly for the offending file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 03:20:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 03:20:13 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.98b05853a8f4b484e5a6a323e1d8e3bb@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): so i've some ideas: 1) are we placing end proc at the right spot? 2) i think it may be profitable / simplest to move the darwin code path to asm, using clang output as a reference which is going to be my next attachment :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 03:20:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 03:20:46 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.4ce7efc762646a8b5f65b9b07e4fe431@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * Attachment "clangSTGCRUN.s" added. happy stgCRun darwin asm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 04:15:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 04:15:27 -0000 Subject: [GHC] #15889: ghc documentation doesn't explain difference between dwarf levels 1 2 and 3 In-Reply-To: <045.ab3fe7a26edf38924c1d1e51505427fa@haskell.org> References: <045.ab3fe7a26edf38924c1d1e51505427fa@haskell.org> Message-ID: <060.2b21ca4632fcfba9168980226c78f3ae@haskell.org> #15889: ghc documentation doesn't explain difference between dwarf levels 1 2 and 3 -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Documentation | Version: 8.6.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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 06:35:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 06:35:19 -0000 Subject: [GHC] #15608: Segfault in retainer profiling In-Reply-To: <043.5de2d12576332caf387b4ed18691b19e@haskell.org> References: <043.5de2d12576332caf387b4ed18691b19e@haskell.org> Message-ID: <058.3d040b90bde45507f7118aecb10f6844@haskell.org> #15608: Segfault in retainer profiling -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.5 Component: Profiling | 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): Phab:D5134 Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 06:36:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 06:36:38 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack In-Reply-To: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> References: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> Message-ID: <061.2a50aa240c5bb2d1cf2ec331a2780a61@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 14:09:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 14:09:39 -0000 Subject: [GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself Message-ID: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> #15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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: -------------------------------------+------------------------------------- And more generally, is there any chance that we could make something like our builder `Args`/predicate logic work for specifying arguments to hadrian itself? Regardless of the answer to that last question, it seems only natural to have a simple/trivial solution for the case where we are always passing the same options to hadrian, over and over again, while working on GHC. "Yes, hadrian, I still want to build with the `perf` flavour, still with `integer-simple`, and you should still put all the build artifacts under `./ghc-prof-build/` while using all of my 4 cores", is something that I often told hadrian myself, while investigating a particular problem a few weeks ago, for example. Ryan in particular has expressed interested in having a slightly cleaner solution than writing a tiny wrapper script that just does `hadrian/build.sh --flavour=perf -oghc-prof-build $@` or something along those lines. Especially given that our `Args` infrastructure seems perfect to specify that kind of thing. It does seem a little bit circular though, of course. An alternative would be look at a build.mk-ish file, without support for any Make construct, just the good old key=value syntax + comments, and reconstruct a `Flavour` and everything else out of it. This way, instead of "implicitly" passing the same arguments on the CLI, we would "implicitly" look them up from some file, without having to create a wrapper script. (This build.mk-ish file is something I discussed with hvr some time ago, which he would like so as to programmatically specify how he wants his GHCs. He can't reasonably programmatically edit the settings file.) Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 14:47:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 14:47:54 -0000 Subject: [GHC] #13114: UniqSet definition seems shady In-Reply-To: <045.b5ecdb7a698ef5b3e0fe6cbfbbe5606e@haskell.org> References: <045.b5ecdb7a698ef5b3e0fe6cbfbbe5606e@haskell.org> Message-ID: <060.cac491ec6e9a5fa5dc8454d8085a827a@haskell.org> #13114: UniqSet definition seems shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: task | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3146 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sebastian Graf ): In [changeset:"5b98a38a32f2bc8491dc897631be8892919e2143/ghc" 5b98a38a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5b98a38a32f2bc8491dc897631be8892919e2143" Make `UniqDSet` a newtype Summary: This brings the situation of `UniqDSet` in line with `UniqSet`. @dfeuer said in D3146#92820 that he would do this, but probably never got around to it. Validated locally. Reviewers: AndreasK, mpickering, bgamari, dfeuer, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter, dfeuer GHC Trac Issues: #15879, #13114 Differential Revision: https://phabricator.haskell.org/D5313 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 14:47:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 14:47:54 -0000 Subject: [GHC] #15879: Make UniqDSet a newtype In-Reply-To: <044.d015b93ddf01ab30fec5e94dbe79cede@haskell.org> References: <044.d015b93ddf01ab30fec5e94dbe79cede@haskell.org> Message-ID: <059.83e958170f9f982fa23cd706b4605229@haskell.org> #15879: Make UniqDSet a newtype -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13114 | Differential Rev(s): Phab:D5313 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sebastian Graf ): In [changeset:"5b98a38a32f2bc8491dc897631be8892919e2143/ghc" 5b98a38a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5b98a38a32f2bc8491dc897631be8892919e2143" Make `UniqDSet` a newtype Summary: This brings the situation of `UniqDSet` in line with `UniqSet`. @dfeuer said in D3146#92820 that he would do this, but probably never got around to it. Validated locally. Reviewers: AndreasK, mpickering, bgamari, dfeuer, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter, dfeuer GHC Trac Issues: #15879, #13114 Differential Revision: https://phabricator.haskell.org/D5313 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 15:57:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 15:57:42 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.cdfda036037354c986e637bfd23cf127@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by simonpj): Simon will look at the lint error on `wip/T15696` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 16:36:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 16:36:11 -0000 Subject: [GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself In-Reply-To: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> References: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> Message-ID: <063.da4b90c78a3509bd99f0dabe0f7073f1@haskell.org> #15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): I think we can already almost do this, have a look at this section in the docs: https://github.com/ghc/ghc/blob/master/hadrian/doc/user-settings.md #command-line-arguments For example, it's possible to add the following to `UserSetting.hs`: {{{#!haskell ryanFlavour :: Flavour ryanFlavour = performanceFlavour -- Note that we inherit all performanceFlavour settings { name = "ryan" , args = args performanceFlavour <> ryanArgs -- Further tweaks to Args , integerLibrary = pure integerSimple } ryanArgs :: Args ryanArgs = builder Ghc ? input "//Prelude.hs"? pure ["-ddump-simpl", "-ddump-to-file"] }}} And then invoke Hadrian with `--flavour=ryan` flag. There are several further improvements: * Make it possible to override the default flavour, so that it's not necessary to pass `--flavour=ryan`. * Add a new setting `buildThreads` to `Flavour`, so that one could set `buildThreads = 4` as part of the user flavour, instead of setting it separately via command line. * Similarly, add the build root setting to `Flavour` to support `buildRoot = "ghc-prof-build"`, which can still be overriden from the command line if need be. Alp, Ryan: Does this sound like the right thing to do? I'm happy to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 16:57:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 16:57:42 -0000 Subject: [GHC] #12906: GHC fails to typecheck Main module without main In-Reply-To: <045.9f131820c17fbe502671d27a0102f251@haskell.org> References: <045.9f131820c17fbe502671d27a0102f251@haskell.org> Message-ID: <060.0b0f969cc1c78e799707492431792278@haskell.org> #12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: I'll ive it a go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 19:50:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 19:50:09 -0000 Subject: [GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself In-Reply-To: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> References: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> Message-ID: <063.89fabdbda6969ee8ba0d7012a719c5a9@haskell.org> #15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: 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): I'd be happy with this but my needs are less demanding than Ryan's, so I'll just let Ryan comment on your proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 19:54:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 19:54:38 -0000 Subject: [GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself In-Reply-To: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> References: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> Message-ID: <063.e27e900d97a93f9f51a0c36961822ed6@haskell.org> #15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: 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 quite sure if I understand the proposal. Is the basic idea to just make it so that more things (e.g., the number of threads and the output directory) can be customized within `Flavour`? And, once that's in place, to allow overriding which build flavour is the default? If so, that sounds swell to me. There's one more thing that I'd request be customizable, however, that wasn't mentioned in this ticket. I currently have to pass `--progress- colour=never` on the command line since there doesn't appear to be a way to set this in `UserSettings.hs` itself. Having this be customizable in the user settings would be quite nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 22:48:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 22:48:08 -0000 Subject: [GHC] #15891: Excessive system time during execution of GHC-built executables on macOS Message-ID: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> #15891: Excessive system time during execution of GHC-built executables on macOS ----------------------------------------+--------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- It seems that the executables built by GHC on my configuration of macOS are slow, clocking in 80% of my machine's cycles in system time. Here is what I know. - Everything tested bootstrapping with both GHC 8.6.1 and GHC 8.6.2. There is no observable difference between these bootstrapping compilers. The detailed data reported is all from GHC 8.6.1. - When I try to build GHC, stage 1 builds snappily. But once stage-1 gets used, it slows to a crawl. - Activity Monitor reports that my computer is spending roughly 80% of its time in the System space, not the User space. (While building ghc-stage1 itself, there is barely any system activity.) - I have sampled ghc-stage1 during a rts_dist_HC call. Samples are at https://gist.github.com/goldfirere/7316920ad37d776c25c15dbb0ed5996f - I then `dtruss`d the same, with output at https://gist.github.com/goldfirere/621ce9072e1204d30e96e7daecc80d02 - System information: * macOS High Sierra, 10.13.6 * Processor: 3.5 GHz Intel Core i5 * Memory: 16 GB 2400 MHz DDR4 * SSD main storage, formatted with APFS * happy 1.19.9 * alex 3.2.4 * XCode 10.1 * gcc is clang-1000.11.45.5, Apple LLVM version 10.0.0, thread model: posix Others (see [https://mail.haskell.org/pipermail/ghc- devs/2018-November/016507.html thread]) have not been able to repro, but this is very reliable for me. Any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 13 22:53:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Nov 2018 22:53:42 -0000 Subject: [GHC] #15890: Provide a way for hadrian users to always pass some options to hadrian itself In-Reply-To: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> References: <048.a76d3e6c5549bba03c112529ebb4f565@haskell.org> Message-ID: <063.5aea319e9979dc06db6a2a8f84198564@haskell.org> #15890: Provide a way for hadrian users to always pass some options to hadrian itself -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): > Is the basic idea to just make it so that more things (e.g., the number of threads and the output directory) can be customized within `Flavour`? And, once that's in place, to allow overriding which build flavour is the default? If so, that sounds swell to me. Yes, that's the plan. > There's one more thing [...] Sure, adding `--progress-colour` to `Flavour` shouldn't be difficult, I'll do that too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 00:05:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 00:05:28 -0000 Subject: [GHC] #15891: Excessive system time during execution of GHC-built executables on macOS In-Reply-To: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> References: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> Message-ID: <062.aa54cdfc3b7c0a6c68d41b2d0e3ce8ba@haskell.org> #15891: Excessive system time during execution of GHC-built executables on macOS ---------------------------------+---------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: | ---------------------------------+---------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 05:40:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 05:40:36 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString and -O Message-ID: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> #15892: Segmentation fault with ByteString and -O --------------------------------------+---------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- The attached program consistently segfaults (within a few seconds) when compiled with ghc-8.6.1 or ghc-8.6.2. It runs forever (as expected) when compiled with ghc-8.4. To reproduce: {{{ ghc segfault.hs }}} then, {{{ ./segfault >/dev/null }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 05:41:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 05:41:23 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString and -O In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.3606347f7db1e8b731e4220e1eecd2c2@haskell.org> #15892: Segmentation fault with ByteString and -O ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by akio): * Attachment "segfault.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 05:56:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 05:56:23 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString and -O In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.b4fe4b4500ef0e1a6a3a3782c845ccb1@haskell.org> #15892: Segmentation fault with ByteString and -O ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by osa1): Confirmed on GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 06:03:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 06:03:13 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString and -O In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.1531a0b95bfda2547f1dcf4e60cb4116@haskell.org> #15892: Segmentation fault with ByteString and -O ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by osa1): * cc: osa1, simonmar (added) Comment: This seems to be related with the GC. I realized two things: - If I run with debug runtime I get this error: {{{ segfault: internal error: Evaluated a CAF (0x851768) that was GC'd! (GHC version 8.7.20181113 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./segfault +RTS > /dev/null }}} - If I play around with GC params sometimes this programs can run for much longer. E.g. on my system `+RTS -A1G` or `+RTS -G5` seem to make the problem disappear. Could this be related with the recent SRT work? CCing simonmar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 06:05:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 06:05:33 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString and -O In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.cfdc35bd9e66e8541b5d902791fac5d5@haskell.org> #15892: Segmentation fault with ByteString and -O ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by fumieval): Here's an equivalent code with bytestring operations unrolled: https://github.com/tsurucapital/segfault/blob/fumieval/app/Main.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 06:06:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 06:06:31 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString and -O In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.41aca937bec5c988e2555ae43fc25a37@haskell.org> #15892: Segmentation fault with ByteString and -O ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * priority: normal => highest Comment: Yikes, this looks awful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 06:23:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 06:23:28 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString and -O In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.4ad56ec420b66a00f503c7aaad462d6a@haskell.org> #15892: Segmentation fault with ByteString and -O ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 06:25:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 06:25:45 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString (was: Segmentation fault with ByteString and -O) In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.b48befcae964b27ebc9591028e1730f1@haskell.org> #15892: Segmentation fault with ByteString ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by osa1): (You don't need -O for this, updating summary) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 06:41:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 06:41:00 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.8b9fec50a56bb57221de27b8be69a29d@haskell.org> #15892: Segmentation fault with ByteString ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by Fuuzetsu): * cc: fuuzetsu (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 06:45:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 06:45:06 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.416fcbe795e13be4a5b43ff92948e023@haskell.org> #15892: Segmentation fault with ByteString ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by fumieval): * cc: fumieval (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 09:30:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 09:30:48 -0000 Subject: [GHC] #15893: View Patterns affect typechecking in an unpredictable manner Message-ID: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> #15893: View Patterns affect typechecking in an unpredictable manner -------------------------------------+------------------------------------- Reporter: theindigamer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 Keywords: ViewPatterns | 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: -------------------------------------+------------------------------------- Copying the text from my [https://stackoverflow.com/questions/53294823 /viewpatterns-affects-typechecking-in-an-unpredictable-manner StackOverflow question]. {{{ {-# LANGUAGE ViewPatterns #-} import Data.Text (Text) import qualified Data.Text as T import qualified Data.Vector.Unboxed as UV import qualified Data.Vector.Generic as V bar :: Int -> UV.Vector Char -> (Text, Text) bar i v = (t_pre, t_post) where f = T.pack . V.toList (f -> t_pre, f -> t_post) = V.splitAt i v }}} This gives an unexpected type error (tested with GHC 8.4.3), concerning ambiguous type variables and `f` being out of scope. {{{ • Ambiguous type variable ‘v0’ arising from a use of ‘V.toList’ prevents the constraint ‘(V.Vector v0 Char)’ from being solved. Relevant bindings include f :: v0 Char -> Text (bound at Weird.hs:11:5) Probable fix: use a type annotation to specify what ‘v0’ should be. These potential instances exist: instance V.Vector UV.Vector Char -- Defined in ‘Data.Vector.Unboxed.Base’ ...plus one instance involving out-of-scope types instance primitive-0.6.3.0:Data.Primitive.Types.Prim a => V.Vector Data.Vector.Primitive.Vector a -- Defined in ‘Data.Vector.Primitive’ • In the second argument of ‘(.)’, namely ‘V.toList’ In the expression: T.pack . V.toList In an equation for ‘f’: f = T.pack . V.toList | 11 | f = T.pack . V.toList | ^^^^^^^^ Weird.hs:13:6: error: Variable not in scope: f :: UV.Vector Char -> t | 13 | (f -> t_pre, f -> t_post) = V.splitAt i v | ^ Weird.hs:13:18: error: Variable not in scope: f :: UV.Vector Char -> t1 | 13 | (f -> t_pre, f -> t_post) = V.splitAt i v | ^ }}} Some of the other answers on SO have done some digging (e.g. enabling FlexibleContexts / NoMonomorphismRestriction doesn't solve the issue). I haven't yet figured out how to minimize the example further to remove the dependency on Vector... Is this a compiler bug or a documentation bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 09:31:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 09:31:06 -0000 Subject: [GHC] #15894: Cannot find symbol during interactive linking using new-repl on Windows Message-ID: <047.e1fd690e2268aff32d437d88b3160edf@haskell.org> #15894: Cannot find symbol during interactive linking using new-repl on Windows --------------------------------------+---------------------------- Reporter: YellPika | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- Originally from https://github.com/haskell/cabal/issues/5683. I get the following error on Windows 10: {{{ > cabal new-repl --build-depends=ieee754 ... GHCi loads ... Prelude> import Numeric.IEEE Prelude Numeric.IEEE> infinity ghc.exe: | C:\Users\Anthony\AppData\Roaming\cabal\store\ghc-8.6.2\ieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266\lib\libHSieee754-0.8.0-7eecc33cf22b0ebf4d3c4dda98cc9f039432a266.a: unknown symbol `copysign' ghc.exe: ^^ Could not load 'ieee754zm0zi8zi0zm7eecc33cf22b0ebf4d3c4dda98cc9f039432a266_NumericziIEEE_infinity_closure', dependency unresolved. See top entry above. ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: ieee754zm0zi8zi0zm7eecc33cf22b0ebf4d3c4dda98cc9f039432a266_NumericziIEEE_infinity_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org }}} This occurs with both cabal-install 2.4.0.0 and HEAD. This does not occur if I install ieee754 into a sandbox and use `cabal repl`. It also works correctly on Ubuntu 18.04 (on both WSL and a full installation), so it looks like a Windows-specific problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 09:58:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 09:58:49 -0000 Subject: [GHC] #15893: View Patterns affect typechecking in an unpredictable manner In-Reply-To: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> References: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> Message-ID: <066.1752661cdd7b7d1333e6bdbc8fdd9f31@haskell.org> #15893: View Patterns affect typechecking in an unpredictable manner -------------------------------------+------------------------------------- Reporter: theindigamer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 Resolution: | Keywords: ViewPatterns 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): Wow. Here's an example with no dependencies {{{ bar :: Int -> (Int,Int) bar i = (t_pre, t_post) where f :: Int -> Int f j = j (f -> t_pre, f -> t_post) = (i+1, i-1) }}} We get {{{ T15893.hs:10:6: error: * Variable not in scope: f :: Int -> t * Perhaps you meant `f' (line 9) | 10 | (f -> t_pre, f -> t_post) = (i+1, i-1) | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 10:23:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 10:23:36 -0000 Subject: [GHC] #14293: View patterns with locally defined functions in restructuring don't compile In-Reply-To: <048.c31716401fbaaf0de63b3851966b01cc@haskell.org> References: <048.c31716401fbaaf0de63b3851966b01cc@haskell.org> Message-ID: <063.ff5fdd6e0eed28a0da6a08f923ca6568@haskell.org> #14293: View patterns with locally defined functions in restructuring don't compile -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ViewPatterns Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ViewPatterns * related: => #15893 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 10:23:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 10:23:57 -0000 Subject: [GHC] #15893: View Patterns affect typechecking in an unpredictable manner In-Reply-To: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> References: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> Message-ID: <066.bea3c73b1238cdf04b92749acc264df3@haskell.org> #15893: View Patterns affect typechecking in an unpredictable manner -------------------------------------+------------------------------------- Reporter: theindigamer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 Resolution: | Keywords: ViewPatterns Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14293 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14293 Comment: Isn't this just a duplicate of #14293? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 10:30:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 10:30:44 -0000 Subject: [GHC] #15893: View Patterns affect typechecking in an unpredictable manner In-Reply-To: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> References: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> Message-ID: <066.a6ec0475044e1b8989b1661a1c30d04f@haskell.org> #15893: View Patterns affect typechecking in an unpredictable manner -------------------------------------+------------------------------------- Reporter: theindigamer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 Resolution: | Keywords: ViewPatterns Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14293 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by theindigamer): Huh, looks like I didn't use the query tool correctly. I did use "ViewPatterns" as a keyword but it gave me no results when I searched. :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 10:32:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 10:32:06 -0000 Subject: [GHC] #15893: View Patterns affect typechecking in an unpredictable manner In-Reply-To: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> References: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> Message-ID: <066.f756f2ca11bba5debac693a84fed729e@haskell.org> #15893: View Patterns affect typechecking in an unpredictable manner -------------------------------------+------------------------------------- Reporter: theindigamer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 Resolution: | Keywords: ViewPatterns Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14293 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Don't worry, that's not your fault—#14923 wasn't properly tagged with the ViewPatterns keyword, so it was impossible to discover originally :) (I've since amended it with that keyword.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 10:56:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 10:56:05 -0000 Subject: [GHC] #15893: View Patterns affect typechecking in an unpredictable manner In-Reply-To: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> References: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> Message-ID: <066.2890c996d01d9007227ee1574ee2a6a3@haskell.org> #15893: View Patterns affect typechecking in an unpredictable manner -------------------------------------+------------------------------------- Reporter: theindigamer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 Resolution: duplicate | Keywords: ViewPatterns Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14293 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 11:00:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 11:00:25 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.472078a20883d578027d640c035bc6d1@haskell.org> #15892: Segmentation fault with ByteString ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by simonmar): I'm looking into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 11:11:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 11:11:43 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.3509412375850cb13782cc281fe370a9@haskell.org> #15892: Segmentation fault with ByteString ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by hsyl20): Could it be another manifestation of #14375? Maybe try to NOINLINE `withForeignPtr`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 11:32:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 11:32:43 -0000 Subject: [GHC] #14293: View patterns with locally defined functions in restructuring don't compile In-Reply-To: <048.c31716401fbaaf0de63b3851966b01cc@haskell.org> References: <048.c31716401fbaaf0de63b3851966b01cc@haskell.org> Message-ID: <063.bfe2a82511aaeac38a5fbcd99ceae2c5@haskell.org> #14293: View patterns with locally defined functions in restructuring don't compile -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ViewPatterns Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15893 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've realised that it may be simpler than I thought. Currently `RnBinds.rnLocalValBindsLHS` looks like this {{{ rnLocalValBindsLHS fix_env binds = do { binds' <- rnValBindsLHS (localRecNameMaker fix_env) binds ; let bound_names = collectHsValBinders binds' ... }}} I think instead we can do this {{{ = do { let bound_rdr_names = collectHsValBinders binds' ; bound_names <- mapM newLocalBndrRn bound_rdr_name ; binds' <- bindLocalNames bound_names $ addLocalFixities fix_env bound_names $ rnValBindsLHS (localRecNameMaker fix_env) binds ... }}} Take an tricky example binding {{{ (f, f -> x) = e }}} The idea is 1. Find all the `RdrName` binders from bindings, here `f` and `x`. 2. Make fresh `Names` for each of them, say `f_34` and `x_88`. 3. Extend the environment with bindings `f :-> f_34` and `x :-> x_88`. 4. Then rename the LHSs; but when we find a binder (say the `RdrName` `f`), `localRecNameMaker` should ''look it up'' in the environment, rather than making a fresh `Name` (that's been done already). Result is the pattern `(f_34, f_34 -> x_88)`. 5. After that, everything is as before. To do this we need to persuade `localRecNameMaker` to look up rather than make a fresh `Name`. I think we can do this easily, by altering the `LetMk` case of `newPatName`. We need to make exactly the same change in `rnSrcDecls`, for the same reason. I think that's it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 11:33:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 11:33:18 -0000 Subject: [GHC] #15893: View Patterns affect typechecking in an unpredictable manner In-Reply-To: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> References: <051.85c95fbed4321866d2497ca7ce758c5f@haskell.org> Message-ID: <066.97d5f83fb49eb70d0c579938b053285e@haskell.org> #15893: View Patterns affect typechecking in an unpredictable manner -------------------------------------+------------------------------------- Reporter: theindigamer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 Resolution: duplicate | Keywords: ViewPatterns Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14293 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): As usual, Ryan, you are spot on. I'd totally forgotten about #14293. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 12:35:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 12:35:51 -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.a7331f74f711a2ab4a30289189041b50@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: | -------------------------------------+------------------------------------- Comment (by michaelpj): I ran into this recently when attempting to embed some static data into a program from a Core plugin. Having found http://hackage.haskell.org/package/ghc-8.4.3/docs/MkCore.html#v:mkWordExpr I thought I could sneak a bytestring in as a list of word expressions - which triggered this issue when the list got long enough. Again, this does only trigger when compiling without -O, but people do occasionally do that. I worked around it by essentially mimicing what `fileEmbed` does to make a bytestring literal in TH (http://hackage.haskell.org/package/file- embed-0.0.11/docs/src/Data.FileEmbed.html#bsToExp), but this is somewhat clumsy as you have to rely on having the `ByteString` names around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 13:45:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 13:45:00 -0000 Subject: [GHC] #15895: Unable to match instance signatures Message-ID: <051.1979d3ada6f866f15c724d47afa87518@haskell.org> #15895: Unable to match instance signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: InstanceSigs | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Richard said GHC should be able to infer this {{{#!hs {-# Language PolyKinds #-} {-# Language RankNTypes #-} {-# Language TypeFamilies #-} {-# Language FlexibleInstances #-} {-# Language InstanceSigs #-} import Data.Kind class Ríki ob where type Arr :: ob -> ob -> Type ið :: forall (a :: ob). Arr a a instance Ríki Type where type Arr = (->) ið :: Arr a a ið a = a }}} {{{ $ ~/code/unmodifiedghc/inplace/bin/ghc-stage2 --interactive -ignore-dot- ghci ~/hs/693_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /home/baldur/hs/693_bug.hs, interpreted ) /home/baldur/hs/693_bug.hs:18:3: error: • Couldn't match kind ‘ob’ with ‘*’ ‘ob’ is a rigid type variable bound by the type signature for: ið :: forall ob (a :: ob). Arr a a at /home/baldur/hs/693_bug.hs:17:9-15 When matching types p0 :: * a :: ob Expected type: Arr a a Actual type: p0 -> p0 • The equation(s) for ‘ið’ have one argument, but its type ‘Arr a a’ has none In the instance declaration for ‘Ríki *’ • Relevant bindings include ið :: Arr a a (bound at /home/baldur/hs/693_bug.hs:18:3) | 18 | ið a = a | ^^^^^^^^ Failed, no modules loaded. }}} It works if we specify the kind of `a` or use `(->)` {{{#!hs ið :: forall (a :: Type). Arr a a }}} {{{#!hs ið :: a -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 14:32:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 14:32:22 -0000 Subject: [GHC] #15895: Unable to match instance signatures In-Reply-To: <051.1979d3ada6f866f15c724d47afa87518@haskell.org> References: <051.1979d3ada6f866f15c724d47afa87518@haskell.org> Message-ID: <066.7ff1a25152fd02f04517423769640b35@haskell.org> #15895: Unable to match instance signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: InstanceSigs Operating System: 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): At issue here is whether the instance signature `id :: Arr a a` (excuse my Latin letters) stands alone, or should be considered in the context of the instance it's written in. Alone, there's no way to know that `a`'s kind is `Type`. But, in context, it's obvious. I think we should check an instance signature in light of this information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 14:39:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 14:39:00 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.3235ae8872669fbf585b4e6c339c663f@haskell.org> #15892: Segmentation fault with ByteString ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5334 Wiki Page: | ----------------------------------+-------------------------------------- Changes (by simonmar): * status: new => patch * differential: => Phab:D5334 Comment: Thanks for the bug report @akio and for the very nice small test case @fumieval. I managed to further reduce the code and remove most of the Iteratee stuff, which was making the bug really hard to narrow down. I believe I've now found the problem, the fix was to add a pair of parentheses(!), see Phab:D5334. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 14:52:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 14:52:34 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.994873901316500fce99c992138a6128@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 raichoo): I've a patch that gets me a working `ghc` build with `hadrian` on FreeBSD. I still need to pass `--integer-simple` as a flag since for some reason `hadrian` won't pass the `libgmp` library path to the linker. https://phabricator.haskell.org/D5335 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 15:52:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 15:52:42 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.fc13328dc5d05792a046d91ec8b618d2@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > With a simple package: > > issue.cabal: > {{{ > name: issue > version: 0 > cabal-version: >= 1.10 > build-type: Simple > > library > build-depends: base, binary, binary-orphans==0.1.5.2 > exposed-modules: Issue > }}} > > Issue.hs: > {{{ > {-# LANGUAGE DeriveGeneric #-} > {-# OPTIONS_GHC -Wall #-} > module Issue (T (..)) where > > import Prelude () > import Data.Binary.Orphans > import Data.Binary (Binary (..)) > import GHC.Generics (Generic) > import Data.Aeson (Value) > > data T = T Value deriving (Generic) > > instance Binary T > }}} > > GHC 7.10.3 correctly reports: > {{{ > Issue.hs:7:1: Warning: > The import of ‘Data.Binary’ is redundant > except perhaps to import instances from ‘Data.Binary’ > To import instances alone, use: import Data.Binary() > }}} > > GHC 8.0.1 incorrectly (!!!) reports: > > {{{ > Issue.hs:6:1: warning: [-Wunused-imports] > The import of ‘Data.Binary.Orphans’ is redundant > except perhaps to import instances from ‘Data.Binary.Orphans’ > To import instances alone, use: import Data.Binary.Orphans( > }}} > > but `Binary Value` instance is imported from `Data.Binary.Orphans`. > > --- > > In real life while compiling https://github.com/futurice/haskell-mega- > repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- > github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't > reported, as `Futurice.Prelude` exports other stuff, which is used. See > https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for > minimal imports reported with `-ddump-minimal-imports`. > > ## Status > > I've submitted some PRs to fix the impending unused import warnings: > > * MERGED https://github.com/haskell/cabal/pull/5673 > * https://github.com/kolmodin/binary/pull/159 > * MERGED https://github.com/haskell/bytestring/pull/168 > * https://github.com/haskell/containers/pull/576 > * MERGED https://github.com/haskell/text/pull/240 > > I've also added a new ghc patch here: > * https://phabricator.haskell.org/D5312 New description: With a simple package: issue.cabal: {{{ name: issue version: 0 cabal-version: >= 1.10 build-type: Simple library build-depends: base, binary, binary-orphans==0.1.5.2 exposed-modules: Issue }}} Issue.hs: {{{ {-# LANGUAGE DeriveGeneric #-} {-# OPTIONS_GHC -Wall #-} module Issue (T (..)) where import Prelude () import Data.Binary.Orphans import Data.Binary (Binary (..)) import GHC.Generics (Generic) import Data.Aeson (Value) data T = T Value deriving (Generic) instance Binary T }}} GHC 7.10.3 correctly reports: {{{ Issue.hs:7:1: Warning: The import of ‘Data.Binary’ is redundant except perhaps to import instances from ‘Data.Binary’ To import instances alone, use: import Data.Binary() }}} GHC 8.0.1 incorrectly (!!!) reports: {{{ Issue.hs:6:1: warning: [-Wunused-imports] The import of ‘Data.Binary.Orphans’ is redundant except perhaps to import instances from ‘Data.Binary.Orphans’ To import instances alone, use: import Data.Binary.Orphans( }}} but `Binary Value` instance is imported from `Data.Binary.Orphans`. --- In real life while compiling https://github.com/futurice/haskell-mega- repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't reported, as `Futurice.Prelude` exports other stuff, which is used. See https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for minimal imports reported with `-ddump-minimal-imports`. ## Status I've submitted some PRs to fix the impending unused import warnings: * MERGED https://github.com/haskell/cabal/pull/5673 * https://github.com/kolmodin/binary/pull/159 * MERGED https://github.com/haskell/bytestring/pull/168 * MERGED https://github.com/haskell/containers/pull/576 * MERGED https://github.com/haskell/text/pull/240 I've also added a new ghc patch here: * https://phabricator.haskell.org/D5312 -- Comment (by davide): Just waiting on the [https://github.com/kolmodin/binary/pull/159 binary PR] to be merged, then I'll update the ghc patch and we'll be on our way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 18:06:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 18:06:22 -0000 Subject: [GHC] #5692: Source code with large floating constants in exponential notation cannot be compiled In-Reply-To: <046.9c0670fdc22c4eddb346525c684e623e@haskell.org> References: <046.9c0670fdc22c4eddb346525c684e623e@haskell.org> Message-ID: <061.d4d5111e979f509cdb5a83cef459ebd3@haskell.org> #5692: Source code with large floating constants in exponential notation cannot be compiled -------------------------------------+------------------------------------- Reporter: gracjan | Owner: pcapriotti Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #5688 #15646 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * related: 5688 => #5688 #15646 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 18:08:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 18:08:43 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.2602597db3206d5f2c3072c933040fe8@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * related: => #5692 Comment: I have found an old related (duplicate?) ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 18:31:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 18:31:30 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.a54b7d38b0011ab9ad52a298101d3ddd@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Good find. Indeed that's a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 18:32:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 18:32:02 -0000 Subject: [GHC] #5692: Source code with large floating constants in exponential notation cannot be compiled In-Reply-To: <046.9c0670fdc22c4eddb346525c684e623e@haskell.org> References: <046.9c0670fdc22c4eddb346525c684e623e@haskell.org> Message-ID: <061.5877ebc7702592a2197bbd4aee28a92c@haskell.org> #5692: Source code with large floating constants in exponential notation cannot be compiled -------------------------------------+------------------------------------- Reporter: gracjan | Owner: pcapriotti Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #5688 #15646 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #15646. We're making progress there so closing this one as duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 18:51:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 18:51:20 -0000 Subject: [GHC] #15841: User's Guide section for Coercible links to a 404 page In-Reply-To: <043.ad009ea48127d14d476f5088b41d0b03@haskell.org> References: <043.ad009ea48127d14d476f5088b41d0b03@haskell.org> Message-ID: <058.d73788073a2198c5018f01b4ec5f0e93@haskell.org> #15841: User's Guide section for Coercible links to a 404 page -------------------------------------+------------------------------------- Reporter: koz_ | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 Resolution: fixed | Keywords: newcomer 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 monoidal): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 19:02:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 19:02:27 -0000 Subject: [GHC] #10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr` In-Reply-To: <047.e2e165b0a37a7097edcf4a218b419974@haskell.org> References: <047.e2e165b0a37a7097edcf4a218b419974@haskell.org> Message-ID: <062.43721e60082b7d65bbede2ff6ab6d15f@haskell.org> #10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: kseo Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13238 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): It seems to me that Phab:D3043 has completed this. Can this ticket be closed, or is there something remaining? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 19:51:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 19:51:42 -0000 Subject: [GHC] #15843: Tuple sections can't be quoted In-Reply-To: <049.0eff09d65f5dcf5b91058a38c402215d@haskell.org> References: <049.0eff09d65f5dcf5b91058a38c402215d@haskell.org> Message-ID: <064.16ebb183e6383deb2cc2ac7deb742168@haskell.org> #15843: Tuple sections can't be quoted -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: newcomer, | TemplateHaskell Operating System: 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 disagree with the design in the original post. TH syntax should really be as close as possible to Haskell syntax. Instead, I would say that TH should support tuple sections directly. I propose changing `TupE :: [Exp] -> Exp` to become `TupE :: [Maybe Exp] -> Exp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 20:09:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 20:09:02 -0000 Subject: [GHC] #15879: Make UniqDSet a newtype In-Reply-To: <044.d015b93ddf01ab30fec5e94dbe79cede@haskell.org> References: <044.d015b93ddf01ab30fec5e94dbe79cede@haskell.org> Message-ID: <059.31c023f8aceab03475a86b286fc34ae7@haskell.org> #15879: Make UniqDSet a newtype -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13114 | Differential Rev(s): Phab:D5313 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 21:01:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 21:01:26 -0000 Subject: [GHC] #15896: GHC API: add function to allow looking up Name for Located RdrName Message-ID: <044.aff719817112fa9706a5e690b6a4722f@haskell.org> #15896: GHC API: add function to allow looking up Name for Located RdrName -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: GHC API | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5330 | Wiki Page: -------------------------------------+------------------------------------- A tool writer using the GHC API to do a source level change must use the `ParsedSource` as it most closely represents the original source code, and has API Annotations. But the `ParsedSource` only has `RdrName`s in it, and many useful transformations need information from the renamer, the simplest example being renaming a variable in the presence of name shadowing. So we need a way to look up the `Name` corresponding to each `RdrName` in the `ParsedSource`. GHC does have a `GlobalRdrEnv` which is a mapping from `OccName` to a list of elements, each of which has the `Name`. But the `OccName` is only unique wrt its spelling, and so cannot distinguish the name shadowing case. Fortuitously (!), every `RdrName` in the `ParsedSource` is `Located`, and hence has a unique `SrcSpan` associated with it. So, given a `TypecheckedModule`, it is possible to construct a map from the `SrcSpan` of each `Located RdrName` to the corresponding `Name` from the `RenamedSource` (or `TypecheckedSource` for ambiguous record selectors). Introduce this as part of the GHC API. Note: this function has existed in `HaRe` for some time, and is the reason each `RdrName` in the `ParsedSource` is `Located`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 21:01:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 21:01:43 -0000 Subject: [GHC] #15896: GHC API: add function to allow looking up Name for Located RdrName In-Reply-To: <044.aff719817112fa9706a5e690b6a4722f@haskell.org> References: <044.aff719817112fa9706a5e690b6a4722f@haskell.org> Message-ID: <059.daa52cd55c6ffb84db4cb730c067746a@haskell.org> #15896: GHC API: add function to allow looking up Name for Located RdrName -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: GHC API | Version: 8.6.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:D5330 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 14 23:31:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Nov 2018 23:31:16 -0000 Subject: [GHC] #15891: Excessive system time during execution of GHC-built executables on macOS In-Reply-To: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> References: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> Message-ID: <062.85c96c88a751aaa4ba9963be9425e06d@haskell.org> #15891: Excessive system time during execution of GHC-built executables on macOS ---------------------------------+---------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: | ---------------------------------+---------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 00:48:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 00:48:22 -0000 Subject: [GHC] #15447: Mark the core libraries' internal modules "not-home" instead of "hide" In-Reply-To: <046.a98aa20d9b2d7592ee4ae25a27876473@haskell.org> References: <046.a98aa20d9b2d7592ee4ae25a27876473@haskell.org> Message-ID: <061.4d16e984865e08c9d6d9c8f1b1765adf@haskell.org> #15447: Mark the core libraries' internal modules "not-home" instead of "hide" -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: haddock Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4692 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * differential: => Phab:D4692 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 00:56:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 00:56:02 -0000 Subject: [GHC] #881: Improve space profiling for references In-Reply-To: <046.89fda28d10e4c9bf9885adf9e31162cb@haskell.org> References: <046.89fda28d10e4c9bf9885adf9e31162cb@haskell.org> Message-ID: <061.173c6dde03a9a87436934af311cf7f8d@haskell.org> #881: Improve space profiling for references -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Profiling | Version: 6.4.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 maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 01:25:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 01:25:32 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled Message-ID: <043.bd7f9da23904789b86411de4cb766153@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Debugging (amd64) | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Mutator run time in +RTS -s -RTS can go negative in GHC 8.6.x when retainer profiling is enabled. Here is an example taken from https://ghc.haskell.org/trac/ghc/ticket/881#comment:9 {{{ {-# OPTIONS_GHC -fprof-auto #-} import Control.Monad import Data.IORef import System.Environment main = do [n] <- getArgs replicateM (read n) (newIORef [1,2,3]) }}} {{{ % ghc-8.6.2 -prof -rtsopts -fforce-recomp repro.hs [1 of 1] Compiling Main ( repro.hs, repro.o ) Linking repro ... % ./repro 10000000 +RTS -s -h 3,053,080,472 bytes allocated in the heap 5,538,404,848 bytes copied during GC 1,013,615,328 bytes maximum residency (16 sample(s)) 36,422,944 bytes maximum slop 966 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2600 colls, 0 par 1.375s 1.376s 0.0005s 0.0019s Gen 1 16 colls, 0 par 4.355s 4.355s 0.2722s 1.0136s INIT time 0.000s ( 0.000s elapsed) MUT time 0.000s ( -0.833s elapsed) GC time 4.016s ( 4.016s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 1.715s ( 1.715s elapsed) EXIT time 1.715s ( 1.715s elapsed) Total time 6.612s ( 6.612s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 0 bytes per MUT second Productivity -12.6% of total user, -12.6% of total elapsed }}} Here is what I found so far: * GHC 8.6.1, 8.6.2, and yesterday's HEAD have the same issue. GHC 8.4.4 doesn't have this issue. * `-hr` has the same issue. `-hT` is fine. * Without heap profiling the numbers this doesn't happen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 01:26:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 01:26:59 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled In-Reply-To: <043.bd7f9da23904789b86411de4cb766153@haskell.org> References: <043.bd7f9da23904789b86411de4cb766153@haskell.org> Message-ID: <058.7cdd6424ad268e03b2ec4deb3db75b00@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by maoe: Old description: > Mutator run time in +RTS -s -RTS can go negative in GHC 8.6.x when > retainer profiling is enabled. > > Here is an example taken from > https://ghc.haskell.org/trac/ghc/ticket/881#comment:9 > {{{ > {-# OPTIONS_GHC -fprof-auto #-} > import Control.Monad > import Data.IORef > import System.Environment > > main = do > [n] <- getArgs > replicateM (read n) (newIORef [1,2,3]) > }}} > {{{ > % ghc-8.6.2 -prof -rtsopts -fforce-recomp repro.hs > [1 of 1] Compiling Main ( repro.hs, repro.o ) > Linking repro ... > % ./repro 10000000 +RTS -s -h > 3,053,080,472 bytes allocated in the heap > 5,538,404,848 bytes copied during GC > 1,013,615,328 bytes maximum residency (16 sample(s)) > 36,422,944 bytes maximum slop > 966 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2600 colls, 0 par 1.375s 1.376s 0.0005s > 0.0019s > Gen 1 16 colls, 0 par 4.355s 4.355s 0.2722s > 1.0136s > > INIT time 0.000s ( 0.000s elapsed) > MUT time 0.000s ( -0.833s elapsed) > GC time 4.016s ( 4.016s elapsed) > RP time 0.000s ( 0.000s elapsed) > PROF time 1.715s ( 1.715s elapsed) > EXIT time 1.715s ( 1.715s elapsed) > Total time 6.612s ( 6.612s elapsed) > > %GC time 0.0% (0.0% elapsed) > > Alloc rate 0 bytes per MUT second > > Productivity -12.6% of total user, -12.6% of total elapsed > > }}} > > Here is what I found so far: > > * GHC 8.6.1, 8.6.2, and yesterday's HEAD have the same issue. GHC 8.4.4 > doesn't have this issue. > * `-hr` has the same issue. `-hT` is fine. > * Without heap profiling the numbers this doesn't happen New description: Mutator run time in +RTS -s -RTS can go negative in GHC 8.6.x when heap profiling is enabled. Here is an example taken from https://ghc.haskell.org/trac/ghc/ticket/881#comment:9 {{{ {-# OPTIONS_GHC -fprof-auto #-} import Control.Monad import Data.IORef import System.Environment main = do [n] <- getArgs replicateM (read n) (newIORef [1,2,3]) }}} {{{ % ghc-8.6.2 -prof -rtsopts -fforce-recomp repro.hs [1 of 1] Compiling Main ( repro.hs, repro.o ) Linking repro ... % ./repro 10000000 +RTS -s -h 3,053,080,472 bytes allocated in the heap 5,538,404,848 bytes copied during GC 1,013,615,328 bytes maximum residency (16 sample(s)) 36,422,944 bytes maximum slop 966 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2600 colls, 0 par 1.375s 1.376s 0.0005s 0.0019s Gen 1 16 colls, 0 par 4.355s 4.355s 0.2722s 1.0136s INIT time 0.000s ( 0.000s elapsed) MUT time 0.000s ( -0.833s elapsed) GC time 4.016s ( 4.016s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 1.715s ( 1.715s elapsed) EXIT time 1.715s ( 1.715s elapsed) Total time 6.612s ( 6.612s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 0 bytes per MUT second Productivity -12.6% of total user, -12.6% of total elapsed }}} Here is what I found so far: * GHC 8.6.1, 8.6.2, and yesterday's HEAD have the same issue. GHC 8.4.4 doesn't have this issue. * `-hr` has the same issue. `-hT` is fine. * Without heap profiling the numbers this doesn't happen -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 01:28:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 01:28:59 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled In-Reply-To: <043.bd7f9da23904789b86411de4cb766153@haskell.org> References: <043.bd7f9da23904789b86411de4cb766153@haskell.org> Message-ID: <058.f4d1f430536059c868ea37b6d112bc09@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by maoe: Old description: > Mutator run time in +RTS -s -RTS can go negative in GHC 8.6.x when heap > profiling is enabled. > > Here is an example taken from > https://ghc.haskell.org/trac/ghc/ticket/881#comment:9 > {{{ > {-# OPTIONS_GHC -fprof-auto #-} > import Control.Monad > import Data.IORef > import System.Environment > > main = do > [n] <- getArgs > replicateM (read n) (newIORef [1,2,3]) > }}} > {{{ > % ghc-8.6.2 -prof -rtsopts -fforce-recomp repro.hs > [1 of 1] Compiling Main ( repro.hs, repro.o ) > Linking repro ... > % ./repro 10000000 +RTS -s -h > 3,053,080,472 bytes allocated in the heap > 5,538,404,848 bytes copied during GC > 1,013,615,328 bytes maximum residency (16 sample(s)) > 36,422,944 bytes maximum slop > 966 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2600 colls, 0 par 1.375s 1.376s 0.0005s > 0.0019s > Gen 1 16 colls, 0 par 4.355s 4.355s 0.2722s > 1.0136s > > INIT time 0.000s ( 0.000s elapsed) > MUT time 0.000s ( -0.833s elapsed) > GC time 4.016s ( 4.016s elapsed) > RP time 0.000s ( 0.000s elapsed) > PROF time 1.715s ( 1.715s elapsed) > EXIT time 1.715s ( 1.715s elapsed) > Total time 6.612s ( 6.612s elapsed) > > %GC time 0.0% (0.0% elapsed) > > Alloc rate 0 bytes per MUT second > > Productivity -12.6% of total user, -12.6% of total elapsed > > }}} > > Here is what I found so far: > > * GHC 8.6.1, 8.6.2, and yesterday's HEAD have the same issue. GHC 8.4.4 > doesn't have this issue. > * `-hr` has the same issue. `-hT` is fine. > * Without heap profiling the numbers this doesn't happen New description: Mutator run time in +RTS -s -RTS can go negative in GHC 8.6.x when heap profiling is enabled. Here is an example taken from https://ghc.haskell.org/trac/ghc/ticket/881#comment:9 {{{ {-# OPTIONS_GHC -fprof-auto #-} import Control.Monad import Data.IORef import System.Environment main = do [n] <- getArgs replicateM (read n) (newIORef [1,2,3]) }}} {{{ % ghc-8.6.2 -prof -rtsopts -fforce-recomp repro.hs [1 of 1] Compiling Main ( repro.hs, repro.o ) Linking repro ... % ./repro 10000000 +RTS -s -h 3,053,080,472 bytes allocated in the heap 5,538,404,848 bytes copied during GC 1,013,615,328 bytes maximum residency (16 sample(s)) 36,422,944 bytes maximum slop 966 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2600 colls, 0 par 1.375s 1.376s 0.0005s 0.0019s Gen 1 16 colls, 0 par 4.355s 4.355s 0.2722s 1.0136s INIT time 0.000s ( 0.000s elapsed) MUT time 0.000s ( -0.833s elapsed) GC time 4.016s ( 4.016s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 1.715s ( 1.715s elapsed) EXIT time 1.715s ( 1.715s elapsed) Total time 6.612s ( 6.612s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 0 bytes per MUT second Productivity -12.6% of total user, -12.6% of total elapsed }}} Here is what I found so far: * GHC 8.6.1, 8.6.2, and recent HEAD (20181112) have the same issue. GHC 8.4.4 doesn't have this issue. * `-hr` has the same issue. `-hT` is fine. * Without heap profiling the numbers this doesn't happen -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 01:29:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 01:29:40 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled In-Reply-To: <043.bd7f9da23904789b86411de4cb766153@haskell.org> References: <043.bd7f9da23904789b86411de4cb766153@haskell.org> Message-ID: <058.0f0faa1a98934ddf42171e187bd9282a@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by maoe: Old description: > Mutator run time in +RTS -s -RTS can go negative in GHC 8.6.x when heap > profiling is enabled. > > Here is an example taken from > https://ghc.haskell.org/trac/ghc/ticket/881#comment:9 > {{{ > {-# OPTIONS_GHC -fprof-auto #-} > import Control.Monad > import Data.IORef > import System.Environment > > main = do > [n] <- getArgs > replicateM (read n) (newIORef [1,2,3]) > }}} > {{{ > % ghc-8.6.2 -prof -rtsopts -fforce-recomp repro.hs > [1 of 1] Compiling Main ( repro.hs, repro.o ) > Linking repro ... > % ./repro 10000000 +RTS -s -h > 3,053,080,472 bytes allocated in the heap > 5,538,404,848 bytes copied during GC > 1,013,615,328 bytes maximum residency (16 sample(s)) > 36,422,944 bytes maximum slop > 966 MB total memory in use (0 MB lost due to fragmentation) > > Tot time (elapsed) Avg pause Max > pause > Gen 0 2600 colls, 0 par 1.375s 1.376s 0.0005s > 0.0019s > Gen 1 16 colls, 0 par 4.355s 4.355s 0.2722s > 1.0136s > > INIT time 0.000s ( 0.000s elapsed) > MUT time 0.000s ( -0.833s elapsed) > GC time 4.016s ( 4.016s elapsed) > RP time 0.000s ( 0.000s elapsed) > PROF time 1.715s ( 1.715s elapsed) > EXIT time 1.715s ( 1.715s elapsed) > Total time 6.612s ( 6.612s elapsed) > > %GC time 0.0% (0.0% elapsed) > > Alloc rate 0 bytes per MUT second > > Productivity -12.6% of total user, -12.6% of total elapsed > > }}} > > Here is what I found so far: > > * GHC 8.6.1, 8.6.2, and recent HEAD (20181112) have the same issue. GHC > 8.4.4 doesn't have this issue. > * `-hr` has the same issue. `-hT` is fine. > * Without heap profiling the numbers this doesn't happen New description: Mutator run time in +RTS -s -RTS can go negative in GHC 8.6.x when heap profiling is enabled. Here is an example taken from https://ghc.haskell.org/trac/ghc/ticket/881#comment:9 {{{ {-# OPTIONS_GHC -fprof-auto #-} import Control.Monad import Data.IORef import System.Environment main = do [n] <- getArgs replicateM (read n) (newIORef [1,2,3]) }}} {{{ % ghc-8.6.2 -prof -rtsopts -fforce-recomp repro.hs [1 of 1] Compiling Main ( repro.hs, repro.o ) Linking repro ... % ./repro 10000000 +RTS -s -h 3,053,080,472 bytes allocated in the heap 5,538,404,848 bytes copied during GC 1,013,615,328 bytes maximum residency (16 sample(s)) 36,422,944 bytes maximum slop 966 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 2600 colls, 0 par 1.375s 1.376s 0.0005s 0.0019s Gen 1 16 colls, 0 par 4.355s 4.355s 0.2722s 1.0136s INIT time 0.000s ( 0.000s elapsed) MUT time 0.000s ( -0.833s elapsed) GC time 4.016s ( 4.016s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 1.715s ( 1.715s elapsed) EXIT time 1.715s ( 1.715s elapsed) Total time 6.612s ( 6.612s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 0 bytes per MUT second Productivity -12.6% of total user, -12.6% of total elapsed }}} Here is what I found so far: * GHC 8.6.1, 8.6.2, and recent HEAD (20181112) have the same issue. GHC 8.4.4 doesn't have this issue. * `-hr` has the same issue. `-hT` is fine. * Without heap profiling the numbers look fine -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 01:45:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 01:45:01 -0000 Subject: [GHC] #15891: Excessive system time during execution of GHC-built executables on macOS In-Reply-To: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> References: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> Message-ID: <062.eea71c2fe208d728ff4c943ab67542b1@haskell.org> #15891: Excessive system time during execution of GHC-built executables on macOS ---------------------------------+---------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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 goldfire): I'm glad to see some folks are cc'ing themselves to this ticket, so it's of more general interest. If anyone has observed similar behavior on their own machines, that would be incredibly helpful. Right now, my machine is the only known example of this phenomenon, and so it's quite hard to know where to look. If the problem can be repro'd elsewhere, then we'd really have something to go on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 02:24:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 02:24:00 -0000 Subject: [GHC] #15891: Excessive system time during execution of GHC-built executables on macOS In-Reply-To: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> References: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> Message-ID: <062.1dbb1091a7266c4b0f03c23386eeab32@haskell.org> #15891: Excessive system time during execution of GHC-built executables on macOS ---------------------------------+---------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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 gridaphobe): I'm noticing similar behavior on my macbook. System information: {{{ macOS Mojave, 10.14 Processor: 2.6 GHz Intel Core i7 Memory: 16 GB 2133 MHz LPDDR3 SSD main storage, formatted with APFS happy 1.19.9 alex 3.2.4 gcc is clang-1000.11.45.5, Apple LLVM version 10.0.0, thread model: posix bootstrap ghc is 8.4.4 BuildFlavour = devel2 }}} Just like Richard, the stage1 build is snappy, but things slow down when I start using ghc-stage1. I also noticed a sudden jump to 40% system time (compared to 10% user time and 50% idle) when I started using ghc-stage1. I'm not sure how to sample ghc, but I ran the [https://gist.github.com/gridaphobe/dd3df6616720c571548584160912b950 dtruss command]. I don't really know what to make of the dtruss output, but I'm happy to run any other suggested tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 03:21:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 03:21:18 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.3ed64eb7304858a3993df4f0fb6be7c6@haskell.org> #15892: Segmentation fault with ByteString ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5334 Wiki Page: | ----------------------------------+-------------------------------------- Comment (by fumieval): Nice, that's amazingly fast! I confirmed that D5334 fixes the crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 03:35:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 03:35:41 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.ed717a1847045f778d6e626cc8403166@haskell.org> #15892: Segmentation fault with ByteString ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5334 Wiki Page: | ----------------------------------+-------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"eb46345d37ee61575e6fed04da718c1b7ee0bb99/ghc" eb46345d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb46345d37ee61575e6fed04da718c1b7ee0bb99" Fix a bug in SRT generation (#15892) Summary: The logic in `Note [recursive SRTs]` was correct. However, my implementation of it wasn't: I got the associativity of `Set.difference` wrong, which led to an extremely subtle and difficult to find bug. Fortunately now we have a test case. I was able to cut down the code to something manageable, and I've added it to the test suite. Test Plan: Before (using my stage 1 compiler without the fix): ``` ====> T15892(normal) 1 of 1 [0, 0, 0] cd "T15892.run" && "/home/smarlow/ghc/inplace/bin/ghc-stage1" -o T15892 T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O cd "T15892.run" && ./T15892 +RTS -G1 -A32k -RTS Wrong exit code for T15892(normal)(expected 0 , actual 134 ) Stderr ( T15892 ): T15892: internal error: evacuate: strange closure type 0 (GHC version 8.7.20181113 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) *** unexpected failure for T15892(normal) =====> T15892(g1) 1 of 1 [0, 1, 0] cd "T15892.run" && "/home/smarlow/ghc/inplace/bin/ghc-stage1" -o T15892 T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O cd "T15892.run" && ./T15892 +RTS -G1 -RTS +RTS -G1 -A32k -RTS Wrong exit code for T15892(g1)(expected 0 , actual 134 ) Stderr ( T15892 ): T15892: internal error: evacuate: strange closure type 0 (GHC version 8.7.20181113 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) ``` After (using my stage 2 compiler with the fix): ``` =====> T15892(normal) 1 of 1 [0, 0, 0] cd "T15892.run" && "/home/smarlow/ghc/inplace/test spaces/ghc-stage2" -o T15892 T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "T15892.run" && ./T15892 +RTS -G1 -A32k -RTS =====> T15892(g1) 1 of 1 [0, 0, 0] cd "T15892.run" && "/home/smarlow/ghc/inplace/test spaces/ghc-stage2" -o T15892 T15892.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "T15892.run" && ./T15892 +RTS -G1 -RTS +RTS -G1 -A32k -RTS ``` Reviewers: bgamari, osa1, erikd Reviewed By: osa1 Subscribers: rwbarton, carter GHC Trac Issues: #15892 Differential Revision: https://phabricator.haskell.org/D5334 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 03:36:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 03:36:39 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.4512a3007f7c8904277288b5169bb414@haskell.org> #15892: Segmentation fault with ByteString ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5334 Wiki Page: | ----------------------------------+-------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 03:43:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 03:43:49 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled In-Reply-To: <043.bd7f9da23904789b86411de4cb766153@haskell.org> References: <043.bd7f9da23904789b86411de4cb766153@haskell.org> Message-ID: <058.e821b8abda63f6aa2dbfc214cc07d556@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | 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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 04:10:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 04:10:47 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled In-Reply-To: <043.bd7f9da23904789b86411de4cb766153@haskell.org> References: <043.bd7f9da23904789b86411de4cb766153@haskell.org> Message-ID: <058.384ac92eca1b82812bb70dc3e5af417d@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | 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 osa1): * cc: duog (added) Comment: This is probably introduced in #14660 (Phab:D4303). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 06:47:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 06:47:48 -0000 Subject: [GHC] #10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr` In-Reply-To: <047.e2e165b0a37a7097edcf4a218b419974@haskell.org> References: <047.e2e165b0a37a7097edcf4a218b419974@haskell.org> Message-ID: <062.4ca8a375c700ebd15f33240ef738033e@haskell.org> #10854: Remove recursive uses of `pprParendHsExpr` from `HsExpr.ppr_expr` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: kseo Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13238 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Strictly speaking, I don't think this ticket's goal has been achieved yet, since it's possible to find recursive occurrences of `pprDebugParendExpr` (i.e., [http://git.haskell.org/ghc.git/blob/eb46345d37ee61575e6fed04da718c1b7ee0bb99:/compiler/hsSyn/HsExpr.hs#l982 here]), which is just a thin wrapper around `pprParendExpr`. But then again, I am not the person who originally opened this ticket, so all I can offer is speculation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 08:21:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 08:21:51 -0000 Subject: [GHC] #15466: debug validation failures In-Reply-To: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> References: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> Message-ID: <063.57d98808392a7fc3971bedcf317c86ce@haskell.org> #15466: debug validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 08:47:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 08:47:36 -0000 Subject: [GHC] #15898: Promoted type constructors don't print right in HsType Message-ID: <046.1383fa36176eb530ea6a2c7b418c0593@haskell.org> #15898: Promoted type constructors don't print right in HsType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 {{{ ghci> import Data.Proxy ghci> undefined :: '() -> Int :11:14: error: • Expected a type, but ‘ '()’ has kind ‘()’ • In an expression type signature: '() -> Int }}} What is that strange space doing before the `'()`? Similarly {{{ undefined :: Proxy '() Int :12:14: error: • Expected kind ‘* -> *’, but ‘Proxy '()’ has kind ‘*’ • In an expression type signature: Proxy '() Int }}} Again, the strange space. It comes from the `HsType` pretty printer, which is worried about printing the type {{{ '['K] }}} That is, a promoted list with one element `K`. The trouble is that looks like a character literal `'['`. So we add an extra space, thus `'[ 'K]`. ''But we add it before every promoded data constructor!" Hence the spurious spaces. In `IfaceType` exactly the same thing happens, but we are more clever, and only print the leading space if the promoted data con immediately follows `'[` or `'(`. We should do the same thing for `HsType`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 09:26:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 09:26:19 -0000 Subject: [GHC] #15899: Testcase tcfail158 is broken Message-ID: <049.7f6552ee392f2083aa812ec96556b9fa@haskell.org> #15899: Testcase tcfail158 is broken -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Test testsuite/tests/typecheck/should_fail/tcfail158.hs contains the following code: {{{#!hs {-# LANGUAGE ExplicitForAll #-} -- This one actually crashed in 6.4.1 -- There's a kind error in the signature for bar, -- and we were recovering, and then crashing when we found -- a scoped type variable not in scope data Val v sm = Val foo :: forall v sm. Val v sm foo = undefined where foo1 :: Val v sm foo1 = bar -- Correct type signature: bar :: forall v sm. Val v sm bar :: forall v. Val v bar = undefined foo }}} The expected test result in testsuite/tests/typecheck/should_fail/tcfail158.stderr is: {{{ tcfail158.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ }}} == Issues: 1. With a very high probability, the intention of this test was not to test on the missing main function. The intention was to test the error message for the type signature of function ''bar'' . 2. The code for the definitions and functions start in column 2 and not in column 1. 3. With an added main function GHC Versions 8.0, 8.2, 8.4 and 8.6 report the following error: {{{ tcfail158.hs:17:18: error: • Expecting one more argument to ‘Val v’ Expected a type, but ‘Val v’ has kind ‘* -> *’ • In the type signature: bar :: forall v. Val v }}} 4. GHC HEAD version 8.7.20181112, however, reports: {{{ tcfail158.hs:15:17: error: • Couldn't match expected type ‘Val v1 sm1’ with actual type ‘Val v0’ • In the expression: bar In an equation for ‘foo1’: foo1 = bar In an equation for ‘foo’: foo = undefined where foo1 :: Val v sm foo1 = bar • Relevant bindings include foo1 :: Val v1 sm1 (bound at tcfail158.hs:15:10) tcfail158.hs:17:18: error: • Expecting one more argument to ‘Val v’ Expected a type, but ‘Val v’ has kind ‘* -> *’ • In the type signature: bar :: forall v. Val v ^^^^^ tcfail158.hs:18:7: error: • Couldn't match kind ‘* -> *’ with ‘*’ When matching types t0 :: * Val v :: * -> * • In the expression: undefined foo In an equation for ‘bar’: bar = undefined foo • Relevant bindings include bar :: Val v (bound at tcfail158.hs:18:1) }}} GHC HEAD reports errors in 3 different lines 15, 17 and 18. Fix the type signature in line 17 and GHC compiles successfully. The error messages produced by GHC HEAD are very confusing! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 10:12:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 10:12:15 -0000 Subject: [GHC] #12906: GHC fails to typecheck Main module without main In-Reply-To: <045.9f131820c17fbe502671d27a0102f251@haskell.org> References: <045.9f131820c17fbe502671d27a0102f251@haskell.org> Message-ID: <060.975c863810c3c578b752d725bcc5fdd8@haskell.org> #12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: make test | TEST=T12906 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5338 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => make test TEST=T12906 * differential: => Phab:D5338 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 10:27:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 10:27:45 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.cf4e2eaa5311a05a6dc90a3bac7efd1a@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Yeah I'll put it up on a fork on github. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 11:02:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 11:02:28 -0000 Subject: [GHC] #15853: Unregisterised GHC panics when building test cgrun018 In-Reply-To: <047.a568cb0e736c463bce20c7d17a5e90c5@haskell.org> References: <047.a568cb0e736c463bce20c7d17a5e90c5@haskell.org> Message-ID: <062.8719a710d96c9459b01bff593bc31850@haskell.org> #15853: Unregisterised GHC panics when building test cgrun018 -------------------------------------+------------------------------------- Reporter: iliastsi | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: cgrun018 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrtc27): This is fixed by https://phabricator.haskell.org/D5306 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 11:06:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 11:06:27 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.41fa16dfd37acb164fc4013706925fd5@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Here's my PR to my forked GHC branch: https://github.com/JulianLeviston/ghc/pull/1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 11:50:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 11:50:45 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.49cc6fb5e4eff605093f45cf9978e0dc@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): I can't seem to successfully build my ghc any more... {{{ GHC error in desugarer lookup in GHC.Real: Can't find interface-file declaration for type constructor or class mkRational 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 ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181012 for x86_64-apple-darwin): initDs }}} after I attempted to do the profiler build... that's from attempting a `BuildFlavour = devel2` build without `stage=2` specified. I might follow the build instructions from the ground up again without my code in place then put it back and see if that works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 11:53:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 11:53:20 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types In-Reply-To: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> References: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> Message-ID: <059.baded7bd733daeb1041ef01c0b25d801@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9371 | Differential Rev(s): Phab:D5206 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fe0576426d3ef07d7743c65e34c8b04ce0616426/ghc" fe057642/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fe0576426d3ef07d7743c65e34c8b04ce0616426" Comments only, about polykinded TyConApps See Trac #15704 comment:8ff }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 11:53:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 11:53:20 -0000 Subject: [GHC] #15859: Dependent quantification, GHC panic In-Reply-To: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> References: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> Message-ID: <066.c3157b3f758b3827387ab6ed567fde24@haskell.org> #15859: Dependent quantification, GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T15859 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0ce66be953becf7c9de3cbea406953306b4db3b1/ghc" 0ce66be9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0ce66be953becf7c9de3cbea406953306b4db3b1" Comments adding to the fix for Trac #15859 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 11:53:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 11:53:20 -0000 Subject: [GHC] #15898: Promoted type constructors don't print right in HsType In-Reply-To: <046.1383fa36176eb530ea6a2c7b418c0593@haskell.org> References: <046.1383fa36176eb530ea6a2c7b418c0593@haskell.org> Message-ID: <061.50f18865642323a9224fdf6cd2c3c8eb@haskell.org> #15898: Promoted type constructors don't print right in HsType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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:"ae2c9b40f5b6bf272251d1f4107c60003f541b62/ghc" ae2c9b40/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae2c9b40f5b6bf272251d1f4107c60003f541b62" Smarter HsType pretty-print for promoted datacons Fix Trac #15898, by being smarter about when to print a space before a promoted data constructor, in a HsType. I had to implement a mildly tiresome function HsType.lhsTypeHasLeadingPromotionQuote It has multiple cases, of course, but it's very simple. The patch improves the error-message output in a bunch of cases, and (to my surprise) actually fixes a bug in the output of T14343 (Trac #14343), thus - In the expression: _ :: Proxy '('( 'True, 'False), 'False) + In the expression: _ :: Proxy '( '( 'True, 'False), 'False) I discovered that there were two copies of the PromotionFlag type (a boolean, with helpfully named data cons), one in IfaceType and one in HsType. So I combined into one, PromotionFlag, and moved it to BasicTypes. That's why quite a few files are touched, but it's all routine. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 11:53:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 11:53:20 -0000 Subject: [GHC] #14343: bad pretty-printing of types with promoted data types In-Reply-To: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> References: <048.9dafa4d8103f25346932aca07d111b88@haskell.org> Message-ID: <063.9924c65d602c35426406a6510920ea5e@haskell.org> #14343: bad pretty-printing of types with promoted data types -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: andreash Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4746 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ae2c9b40f5b6bf272251d1f4107c60003f541b62/ghc" ae2c9b40/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae2c9b40f5b6bf272251d1f4107c60003f541b62" Smarter HsType pretty-print for promoted datacons Fix Trac #15898, by being smarter about when to print a space before a promoted data constructor, in a HsType. I had to implement a mildly tiresome function HsType.lhsTypeHasLeadingPromotionQuote It has multiple cases, of course, but it's very simple. The patch improves the error-message output in a bunch of cases, and (to my surprise) actually fixes a bug in the output of T14343 (Trac #14343), thus - In the expression: _ :: Proxy '('( 'True, 'False), 'False) + In the expression: _ :: Proxy '( '( 'True, 'False), 'False) I discovered that there were two copies of the PromotionFlag type (a boolean, with helpfully named data cons), one in IfaceType and one in HsType. So I combined into one, PromotionFlag, and moved it to BasicTypes. That's why quite a few files are touched, but it's all routine. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 13:09:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 13:09:28 -0000 Subject: [GHC] #15898: Promoted type constructors don't print right in HsType In-Reply-To: <046.1383fa36176eb530ea6a2c7b418c0593@haskell.org> References: <046.1383fa36176eb530ea6a2c7b418c0593@haskell.org> Message-ID: <061.d0ff16b95875ffd8f91eb858e8f700b1@haskell.org> #15898: Promoted type constructors don't print right in HsType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T15898 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => ghci/scripts/T15898 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 14:08:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 14:08:14 -0000 Subject: [GHC] #13839: GHC warnings do not respect the default module header In-Reply-To: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> References: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> Message-ID: <063.889cca38f1a51da88a1aa54c6b4ffac6@haskell.org> #13839: GHC warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * cc: RolandSenn (added) * status: new => infoneeded Comment: @Feuerbach: Can you still reproduce this? With ''cat T13869.hs'' {{{#!hs type T = Int main :: IO () main = return () }}} ''ghc --version && ghc -Wall T13893.hs'' I get {{{ The Glorious Glasgow Haskell Compilation System, version 8.6.2 [1 of 1] Compiling Main ( T13893.hs, T13893.o ) T13893.hs:1:1: warning: [-Wunused-top-binds] Defined but not used: type constructor or class ‘T’ | 1 | type T = Int | ^^^^^^^^^^^^ Linking T13893 ... }}} Even with GHC 8.0.1 I'm unable to reproduce your problem! How did you compile your program? What's your OS? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 14:51:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 14:51:40 -0000 Subject: [GHC] #15900: Can't boot with GHC 8.6.2 Message-ID: <043.eae99a908053775baf8edf5cdbcfb5dc@haskell.org> #15900: Can't boot with GHC 8.6.2 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- I just installed GHC 8.6.2 on a fresh Ubuntu 18.04 and cloned the repo. This is what I get when I do `make` without a `build.mk`: {{{ "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/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 Cabal-2.4.0.1 -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.3.1 -package-id filepath-1.4.2.1 -package-id ghc-8.7 -package-id ghc-boot-8.7 -package-id parsec-3.1.13.0 -package-id text-1.2.3.1 -package-id transformers-0.5.5.0 -package-id xhtml-3000.2.2.1 -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/Types.hs -o utils/haddock/dist/build/Haddock/Types.dyn_o utils/haddock/haddock-api/src/Haddock/Types.hs:385:37: error: • Data constructor not in scope: NotPromoted :: BasicTypes.PromotionFlag • Perhaps you want to add ‘NotPromoted’ to the import list in the import of ‘BasicTypes’ (utils/haddock/haddock-api/src/Haddock/Types.hs:37:1-30). | 385 | tvar = L loc (HsTyVar NoExt NotPromoted (L loc name)) | ^^^^^^^^^^^ utils/haddock/haddock-api/src/Haddock/Types.hs:386:47: error: • Data constructor not in scope: NotPromoted :: BasicTypes.PromotionFlag • Perhaps you want to add ‘NotPromoted’ to the import list in the import of ‘BasicTypes’ (utils/haddock/haddock-api/src/Haddock/Types.hs:37:1-30). | 386 | mkType (UserTyVar _ name) = HsTyVar NoExt NotPromoted name | ^^^^^^^^^^^ utils/haddock/ghc.mk:20: recipe for target 'utils/haddock/dist/build/Haddock/Types.dyn_o' failed make[1]: *** [utils/haddock/dist/build/Haddock/Types.dyn_o] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 15:01:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 15:01:54 -0000 Subject: [GHC] #15840: Inline data constructor wrappers very late In-Reply-To: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> References: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> Message-ID: <062.234e08dcec093eeaf516e51865b781a9@haskell.org> #15840: Inline data constructor wrappers very late -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I like this plan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 16:00:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 16:00:12 -0000 Subject: [GHC] #15900: Can't boot with GHC 8.6.2 In-Reply-To: <043.eae99a908053775baf8edf5cdbcfb5dc@haskell.org> References: <043.eae99a908053775baf8edf5cdbcfb5dc@haskell.org> Message-ID: <058.c447cee50058717f679121ca05c8e329@haskell.org> #15900: Can't boot with GHC 8.6.2 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 osa1): I just tried on another computer with GHC 8.4 and got the same error. It seems like GHC can't be built now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 16:01:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 16:01:30 -0000 Subject: [GHC] #15900: Can't boot with GHC 8.6.2 In-Reply-To: <043.eae99a908053775baf8edf5cdbcfb5dc@haskell.org> References: <043.eae99a908053775baf8edf5cdbcfb5dc@haskell.org> Message-ID: <058.58b5b9fea9b8e4fbbcafc89731cbd736@haskell.org> #15900: Can't boot with GHC 8.6.2 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 osa1): * cc: simonpj (added) Comment: ae2c9b40f5 seems to be the commit that broke haddock. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 16:43:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 16:43:43 -0000 Subject: [GHC] #15840: Inline data constructor wrappers very late In-Reply-To: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> References: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> Message-ID: <062.0fe151700e7bf7bb66bc404321985702@haskell.org> #15840: Inline data constructor wrappers very late -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aspiwack): Here is an example program which changes behaviour depending on this ticket: {{{#!haskell data T = MkT !Bool f :: T -> Bool f _ = False {-# NOINLINE f #-} {-# RULES "non-det" [1] forall x. f (MkT x) = x #-} main :: IO () main = print (f (MkT True)) }}} Since `MkT` has a strict field, it has a wrapper. The rule triggers only if the wrapper hasn't been inlined, however, wrappers are inlined (current GHC) in phase 2, and the rules is only active in phase 1 (and later). So the rule never fires, and the program prints `False`. With the proposed patch, the wrapper is not inlined before phase 0, so the rule can fire and the program prints `False`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 17:13:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 17:13:05 -0000 Subject: [GHC] #15901: Assert and record that code generation requires distinct uiques for let-binders Message-ID: <044.667c51a2ab3cbeffd260201fc3c43d63@haskell.org> #15901: Assert and record that code generation requires distinct uiques for let- binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Simon writes in [https://ghc.haskell.org/trac/ghc/ticket/15754#comment:10 #15754]: Another invariant that the code generator needs is (I believe) that every let-binder has a distinct unique. We can't re-use the same unique, even in a different scope, let alone shadowing. Why? Because (I believe) that the code generator uses these uniques to generate unique top level labels for the entry code and info table for the closure. Now, it's probably the case that they are unique anyway; but we should either * Write this down as a invariant of STG, or * Establish this invariant in the immediately-before-codegen pass that gets the free vars right, or * Not assume it in the code generator -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 17:17:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 17:17:42 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.8e73c22432287f63862cd068b2b419cb@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 #15867 | Differential Rev(s): Phab:D5324 #15901 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: #9718 #15867 => #9718 #15867 #15901 Comment: Replying to [comment:12 osa1]: > Note that Phab:D5324 does not address comment:10, which we may want to track in another ticket. This is now tracked in #15901. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 17:25:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 17:25:30 -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.3fd42309df731f51fb58992c63be891b@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.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): Phab:D4817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kgardas): * cc: kgardas (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 19:37:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 19:37:46 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.5596bf71794c9198eea43692fba03b05@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): i put a patch up on https://phabricator.haskell.org/D5340 i'm still failing to get it to build though :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 19:50:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 19:50:59 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.4a8e3ef359fc8fcdd92b1dde3f5a1078@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): (though it may be because i didn't reboot the build after editing the cabal.in file for the RTS) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 20:08:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 20:08:49 -0000 Subject: [GHC] #15902: dead symbol warning error in rts base Message-ID: <045.3733b3a97e244142f0d34dba5301153a@haskell.org> #15902: dead symbol warning error in rts base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- rts/posix/OSMem.c:161:1: error: warning: 'post_mmap_madvise' defined but not used [-Wunused-function] post_mmap_madvise(int operation, W_ size, void *ret) ^~~~~~~~~~~~~~~~~ | 161 | post_mmap_madvise(int operation, W_ size, void *ret) OSX build env -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 22:49:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 22:49:19 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.17fef12db12998422738af973b334dfd@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: None | Version: Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by berdario): Has this really been fixed? https://gist.github.com/berdario/e1160b6fb2d353f446a0ecd9c8caa6d1 I get the same error: dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib Referenced from: /private/tmp/ghc-8.6.2/libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.2.dylib Reason: image not found -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 15 23:02:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Nov 2018 23:02:57 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.76efd30ab375b3120cec2bb22fb18f97@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: None | Version: Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by berdario): I see that here: https://circleci.com/gh/ghc/ghc/11020 This message is logged: configure: WARNING: unrecognized options: --with-intree-gmp maybe the configuration hasn't been picked up by autoconf? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 00:11:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 00:11:28 -0000 Subject: [GHC] #15860: Hadrian build fails on FreeBSD In-Reply-To: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> References: <046.16d3d17d413d6830e1e435c2cb9ff5a5@haskell.org> Message-ID: <061.3c9080ffb6083dc78e242f11bb66ed2d@haskell.org> #15860: Hadrian build fails on FreeBSD -------------------------------------+------------------------------------- Reporter: raichoo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: FreeBSD | 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 snowleopard): Thank you for the patch! Glad you made it work with `--integer-simple`. It's difficult to figure out what's wrong with `libgmp` on FreeBSD from my Windows machine, but I can point you to the GMP-related build rule: https://github.com/ghc/ghc/blob/94756201349685a34c4495addd3484fdfcc8b498/hadrian/src/Rules/Gmp.hs#L46 Also, you could try to build GHC using in-tree GMP. I think the easiest way to do that is to comment out these lines: https://github.com/ghc/ghc/blob/94756201349685a34c4495addd3484fdfcc8b498/hadrian/src/Rules/Gmp.hs#L51-L58 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 05:05:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 05:05:39 -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.b247850a9e4340b45fcda3801bcf223e@haskell.org> #14742: Unboxed sums can treat Word#s as Int#s -------------------------------------+------------------------------------- Reporter: duog | Owner: osa1 Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => invalid Comment: As explained in comment:3, this is by design, and this currently does not cause linter errors (probably fixed with 7f389a580f42a105623853adad15ab3323b41ed5). Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 05:13:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 05:13:13 -0000 Subject: [GHC] #10675: GHC does not check the functional dependency consistency condition correctly In-Reply-To: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> References: <046.c63a3d5abf02d779fbe6a1e8e4a5d19e@haskell.org> Message-ID: <061.5682170ac47afe4eb7e5e96652828a99@haskell.org> #10675: GHC does not check the functional dependency consistency condition correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: FunDeps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 05:22:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 05:22:34 -0000 Subject: [GHC] #15903: Assertion failure in LDV profiler Message-ID: <043.95bcd17554628d1ece5f19f0074a13aa@haskell.org> #15903: Assertion failure in LDV profiler -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.7 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: -------------------------------------+------------------------------------- `T11627a` and `T11627b` fail the same way when run with debug runtime: {{{ $ make EXTRA_HC_OPTS=-debug TEST=T11627b WAY=prof_hb ... =====> T11627b(prof_hb) 1 of 1 [0, 0, 0] cd "profiling/should_run/T11627b.run" && "/home/omer/haskell/ghc_4/inplace/test spaces/ghc-stage2" -o T11627b T11627b.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -debug -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O -prof -static -fprof-auto cd "profiling/should_run/T11627b.run" && ./T11627b +RTS -hb -RTS +RTS -i0 -RTS Wrong exit code for T11627b(prof_hb)(expected 0 , actual 134 ) Stderr ( T11627b ): T11627b: internal error: ASSERTION FAILED: file rts/ProfHeap.c, line 200 (GHC version 8.7.20181115 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) *** unexpected failure for T11627b(prof_hb) Unexpected results from: TEST="T11627b" }}} Only tried with GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 05:29:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 05:29:23 -0000 Subject: [GHC] #15900: Can't boot with GHC 8.6.2 In-Reply-To: <043.eae99a908053775baf8edf5cdbcfb5dc@haskell.org> References: <043.eae99a908053775baf8edf5cdbcfb5dc@haskell.org> Message-ID: <058.06c5e01e68afefe5b5ed291b903d1f6a@haskell.org> #15900: Can't boot with GHC 8.6.2 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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:D5341 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5341 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 05:30:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 05:30:43 -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.9b1fad808bc430b60ca81e86ed01729e@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.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): Phab:D4817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by neosimsim): * cc: neosimsim (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 05:59:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 05:59:51 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled In-Reply-To: <043.bd7f9da23904789b86411de4cb766153@haskell.org> References: <043.bd7f9da23904789b86411de4cb766153@haskell.org> Message-ID: <058.9b690cde106cb1a3c2aaf5497e9ac476@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | 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 osa1): * cc: bgamari (added) Comment: If I run this program with debug runtime I get this assertion failure: {{{ Main: internal error: ASSERTION FAILED: file rts/Stats.c, line 1123 (GHC version 8.7.20181115 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Main 5000000 +RTS -s -h }}} Code that fails: {{{ // The subdivision of runtime into INIT/EXIT/GC/MUT is just adding // and subtracting, so the parts should add up to the total exactly. // Note that stats->total_ns is captured a tiny bit later than // end_exit_elapsed, so we don't use it here. ASSERT(stats.init_elapsed_ns \ + stats.mutator_elapsed_ns \ + stats.gc_elapsed_ns \ + sum.exit_elapsed_ns \ == end_exit_elapsed - start_init_elapsed); }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 08:25:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 08:25:35 -0000 Subject: [GHC] #15904: hp2ps fail with parse error when the command args contains double quotes Message-ID: <046.fc408ba87d45914eacede67a1118c1d0@haskell.org> #15904: hp2ps fail with parse error when the command args contains double quotes -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.7 Keywords: hp2ps | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ watashi % cat test.hs main = pure () watashi % ghc -prof -rtsopts test.hs watashi % ./test '{"e": 2.72, "pi": 3.14}' +RTS -h watashi % hp2ps test.hp hp2ps: test.hp, line 1: integer must follow identifier }}} Manually open `test.hp` and remove the `"`s in `JOB` will mitigate the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 08:25:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 08:25:47 -0000 Subject: [GHC] #15904: hp2ps fail with parse error when the command args contains double quotes In-Reply-To: <046.fc408ba87d45914eacede67a1118c1d0@haskell.org> References: <046.fc408ba87d45914eacede67a1118c1d0@haskell.org> Message-ID: <061.25c7fa4bd2e76727c65ad97dff6eea63@haskell.org> #15904: hp2ps fail with parse error when the command args contains double quotes -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.7 Resolution: | Keywords: hp2ps 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 watashi): * owner: (none) => watashi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 08:53:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 08:53:25 -0000 Subject: [GHC] #15900: Can't boot with GHC 8.6.2 In-Reply-To: <043.eae99a908053775baf8edf5cdbcfb5dc@haskell.org> References: <043.eae99a908053775baf8edf5cdbcfb5dc@haskell.org> Message-ID: <058.723660f9b2ac8081de5c6577111b8791@haskell.org> #15900: Can't boot with GHC 8.6.2 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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:D5341 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Andreas Klebinger ): In [changeset:"4efd1b487e10c8cdbc1bca10c45f0887642a5c48/ghc" 4efd1b4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4efd1b487e10c8cdbc1bca10c45f0887642a5c48" bump haddock submodule Summary: ae2c9b40f5b6bf272251d1f4107c60003f541b62 introduced some changes that broke haddock, [1] fixed them and this patch bumps the haddock submodule to include the fixes. [1]: https://github.com/haskell/haddock/pull/970 Test Plan: build haddock (make or hadrian) Reviewers: bgamari, AndreasK Reviewed By: AndreasK Subscribers: osa1, AndreasK, rwbarton, carter GHC Trac Issues: #15900 Differential Revision: https://phabricator.haskell.org/D5341 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 09:50:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 09:50:47 -0000 Subject: [GHC] #15905: Data familes should end in Type Message-ID: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 we allow {{{ data family Fix (f :: Type -> k) :: k }}} with a ‘k’ in the right-hand corner. See `Note [Arity of data families]` in `FamInstEnv`. That seems attractive because we can then have {{{ data instance Fix (f :: Type -> Type -> Type) (x :: Type) = MkFix2 (f (Fix f x) x) }}} But what about this? {{{ type family F a type instance F Int = Type -> Type data instance Fix (f :: Type -> F Int) (x :: Type) = … }}} The type inference engine (tcInferApps) will type the LHS as something like {{{ ((Fix (f :: Type -> F Int)) |> co1) (x |> co2) where co1 :: F Int ~ Type co2 :: Type ~ F Int }}} But the LHS of a family axiom has to look like {{{ F t1 t2 … tn }}} not {{{ ((F t1 |> co) t2 t3) |> co4) …tn }}} with casts in the way. So that LHS must be rejected. And it’s very hard to see how to accept the first example while (predictably, comprehensibly) rejecting the second. It’d be something like “the kind that instantiates k must have obvious, visible, arrows”. Ugh! And indeed GHC HEAD does accept the first, but rejects the second with the error message {{{ • Expected kind ‘* -> * -> *’, but ‘f :: Type -> F Int’ has kind ‘* -> F Int’ • In the first argument of ‘Fix’, namely ‘(f :: Type -> F Int)’ In the data instance declaration for ‘Fix’ }}} That's clearly bogus: we've specified that `F Int = Type -> Type`. I'm not even sure precisely how it happens, but it must be fragile: a change in solve order, or more aggressive solving might change the behaviour. I don't see how to solve this. I propose instead to require data family kinds to end in `Type`, not in a type ''variable'' (as we currently allow). I don't know how many people that would affect, but the current state of affairs looks untenable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 10:11:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 10:11:00 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack In-Reply-To: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> References: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> Message-ID: <061.14d2375be5303243a281e5a06acd98c3@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by qnikst): * owner: (none) => qnikst Comment: I'm going to work on this ticket during Munihac. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 10:21:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 10:21:28 -0000 Subject: [GHC] #15898: Promoted type constructors don't print right in HsType In-Reply-To: <046.1383fa36176eb530ea6a2c7b418c0593@haskell.org> References: <046.1383fa36176eb530ea6a2c7b418c0593@haskell.org> Message-ID: <061.9aee92849da0fc71e588d23508824f45@haskell.org> #15898: Promoted type constructors don't print right in HsType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T15898 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) Comment: As you can see in this validate run: https://circleci.com/gh/ghc/ghc/11395 {{{#!hs Actual stderr output differs from expected: --- /dev/null 2018-11-16 06:39:05.702159000 +0000 +++ ghci/scripts/T15898.run/T15898.run.stderr.normalised 2018-11-16 09:54:38.995083401 +0000 @@ -0,0 +1,52 @@ + +:3:1: + Couldn't match kind ‘()’ with ‘*’ + When matching types + a0 :: * + '() :: () + In the expression: undefined :: '() + In an equation for ‘it’: it = undefined :: '() + +:3:14: + Expected a type, but ‘'()’ has kind ‘()’ + In an expression type signature: '() + In the expression: undefined :: '() + In an equation for ‘it’: it = undefined :: '() + +:4:14: + Expected kind ‘* -> *’, but ‘Proxy '()’ has kind ‘*’ + In an expression type signature: Proxy '() Int + In the expression: undefined :: Proxy '() Int + In an equation for ‘it’: it = undefined :: Proxy '() Int + +:5:1: + Couldn't match kind ‘[*]’ with ‘*’ + When matching types + a0 :: * + '[(), ()] :: [*] + In the expression: undefined :: [(), ()] + In an equation for ‘it’: it = undefined :: [(), ()] + +:5:14: + Expected a type, but ‘[(), ()]’ has kind ‘[*]’ + In an expression type signature: [(), ()] + In the expression: undefined :: [(), ()] + In an equation for ‘it’: it = undefined :: [(), ()] + +:6:1: + Couldn't match kind ‘([k0], [k1])’ with ‘*’ + When matching types + a0 :: * + '( '[], '[]) :: ([k0], [k1]) + In the expression: undefined :: '( '[], '[]) + In an equation for ‘it’: it = undefined :: '( '[], '[]) + Relevant bindings include + it :: '( '[], '[]) (bound at :6:1) + +:6:14: + Expected a type, but ‘'( '[], '[])’ has kind ‘([k0], [k1])’ + In an expression type signature: '( '[], '[]) + In the expression: undefined :: '( '[], '[]) + In an equation for ‘it’: it = undefined :: '( '[], '[]) + Relevant bindings include + it :: '( '[], '[]) (bound at :6:1) *** unexpected failure for T15898(ghci) }}} T15898 doesn't pass in the ghci way on HEAD. Should we re-open this ticket, or is it a new problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 10:30:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 10:30:04 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.d039e81076ec85f69e1b87c484e87ca4@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: None | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => * milestone: 8.6.2 => 8.6.3 Comment: Indeed, very good catch! Looks like another 8.6 release is in order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 11:39:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 11:39:00 -0000 Subject: [GHC] #15702: "-main-is" flag is broken for recent ghc-head In-Reply-To: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> References: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> Message-ID: <064.d16afe2d7a2688ecc1e5a41578c625ec@haskell.org> #15702: "-main-is" flag is broken for recent ghc-head -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) * version: 8.6.1 => 8.7 * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 11:39:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 11:39:50 -0000 Subject: [GHC] #15898: Promoted type constructors don't print right in HsType In-Reply-To: <046.1383fa36176eb530ea6a2c7b418c0593@haskell.org> References: <046.1383fa36176eb530ea6a2c7b418c0593@haskell.org> Message-ID: <061.191e6ad39aa8051d62eb71e9d5e729dd@haskell.org> #15898: Promoted type constructors don't print right in HsType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T15898 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"32e7738bb1a1df5133fd775312e7fb5ae6823099/ghc" 32e7738/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="32e7738bb1a1df5133fd775312e7fb5ae6823099" Add missing stderr file for Trac #15898 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 11:40:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 11:40:21 -0000 Subject: [GHC] #15898: Promoted type constructors don't print right in HsType In-Reply-To: <046.1383fa36176eb530ea6a2c7b418c0593@haskell.org> References: <046.1383fa36176eb530ea6a2c7b418c0593@haskell.org> Message-ID: <061.ab64e7898fbca072d14d79002f97a775@haskell.org> #15898: Promoted type constructors don't print right in HsType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T15898 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah. I had the stderr file in my build tree, but not in my source tree, so I failed to add it. Sorry. Now pushed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 11:52:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 11:52:26 -0000 Subject: [GHC] #15906: Stable name allocation causes heap corruption when GC is triggered in the primop Message-ID: <043.dc1662ef67173abf865b687c84575bba@haskell.org> #15906: Stable name allocation causes heap corruption when GC is triggered in the primop -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Runtime | Version: 8.7 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The error is originally reported in #15241, and is caught by the test `memo001` when run with `-debug` (which only happens in sanity way currently). Here's the problem. mkStableName# is defined like this: {{{ stg_makeStableNamezh ( P_ obj ) { W_ index, sn_obj; (index) = ccall lookupStableName(obj "ptr"); /* Is there already a StableName for this heap object? * stable_name_table is a pointer to an array of snEntry structs. */ if ( snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry) == NULL ) { ALLOC_PRIM (SIZEOF_StgStableName); <------------ PROBLEM HERE ---------- sn_obj = Hp - SIZEOF_StgStableName + WDS(1); SET_HDR(sn_obj, stg_STABLE_NAME_info, CCCS); StgStableName_sn(sn_obj) = index; snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry) = sn_obj; } else { sn_obj = snEntry_sn_obj(W_[stable_name_table] + index*SIZEOF_snEntry); } return (sn_obj); } }}} There's a problem in the annotated line: if we allocate a `snEntry` in the stable name table, but run out of heap to actually allocate the `StgStableName` we call GC with incorrect `snEntry` contents. As a reminder, this is `snEntry`: {{{ typedef struct { StgPtr addr; // Haskell object when entry is in use, next free // entry (NULL when this is the last free entry) // otherwise. May be NULL temporarily during GC (when // pointee dies). StgPtr old; // Old Haskell object, used during GC StgClosure *sn_obj; // The StableName object, or NULL when the entry is // free } snEntry; }}} In summary, `sn_obj == NULL` means the entry is free. When we trigger the GC after allocating the `snEntry` but before allocating the `StgStableName`, we end up calling the GC with `sn_obj == NULL` even though the `snEntry` is not actually free. In particular, the `addr` field should be updated by `gcStableNameTable`, but it's currently not because `gcStableNameTable` sees `sn_obj` as NULL and skips the entry. The is caught by memo001 when run with -debug. I already have a fix and will submit a patch soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 11:52:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 11:52:54 -0000 Subject: [GHC] #15241: Validate failures in sanity way In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.9b552e9bb31e43aa26d1a10a711f4ffd@haskell.org> #15241: Validate failures in sanity way -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14915, #15906 | Differential Rev(s): Phab:D4839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: #14915 => #14915, #15906 Comment: Tracking `memo001` in #15906 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 11:59:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 11:59:56 -0000 Subject: [GHC] #15906: Stable name allocation causes heap corruption when GC is triggered in the primop In-Reply-To: <043.dc1662ef67173abf865b687c84575bba@haskell.org> References: <043.dc1662ef67173abf865b687c84575bba@haskell.org> Message-ID: <058.f5e83695bb2e592829816510293fb2f5@haskell.org> #15906: Stable name allocation causes heap corruption when GC is triggered in the primop -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5342 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * cc: simonmar (added) * differential: => Phab:D5342 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 12:08:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 12:08:26 -0000 Subject: [GHC] #15907: memo001 causes compile time panic with fails with -O -dannot-lint Message-ID: <043.fd83f51dcee4fdd0ad225b67674205bf@haskell.org> #15907: memo001 causes compile time panic with fails with -O -dannot-lint -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- {{{ $ cd libraries/base/tests; ghc-stage2 memo001.hs -O -dannot-lint [1 of 2] Compiling Memo1 ( Memo1.lhs, Memo1.o ) [Optimisation flags changed] ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181116 for x86_64-unknown-linux): idInfo val_a3pf Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:567: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 Fri Nov 16 12:38:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 12:38:42 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.d35595aa151484cf7fcfbfb16e89873b@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.3 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by bgamari): * priority: normal => high * milestone: 8.8.1 => 8.6.3 Comment: Apparently [[https://github.com/commercialhaskell/stack/issues/3990|several others]] have encountered this. Bumping in priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 13:00:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 13:00:26 -0000 Subject: [GHC] #15900: Can't boot with GHC 8.6.2 In-Reply-To: <043.eae99a908053775baf8edf5cdbcfb5dc@haskell.org> References: <043.eae99a908053775baf8edf5cdbcfb5dc@haskell.org> Message-ID: <058.5b975819763e9ae0792eec38517a5bda@haskell.org> #15900: Can't boot with GHC 8.6.2 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 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:D5341 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * version: 8.6.2 => 8.7 * resolution: => fixed * milestone: 8.6.3 => 8.8.1 Comment: I believe this should be fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 13:03:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 13:03:26 -0000 Subject: [GHC] #15905: Data familes should end in Type In-Reply-To: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> References: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> Message-ID: <061.9abd83c9e0d0e66879f26b36ad2556a4@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14645 Comment: #14645 would be nuked out of existence if this were implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 13:38:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 13:38:55 -0000 Subject: [GHC] #12906: GHC fails to typecheck Main module without main In-Reply-To: <045.9f131820c17fbe502671d27a0102f251@haskell.org> References: <045.9f131820c17fbe502671d27a0102f251@haskell.org> Message-ID: <060.c73c314994d1339c4d7dd6fb16485d11@haskell.org> #12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: make test | TEST=T12906 Blocked By: | Blocking: Related Tickets: #15899 | Differential Rev(s): Phab:D5338 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15899 Comment: See #15899 for a ticket caused by Phab:D5338. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 13:50:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 13:50:55 -0000 Subject: [GHC] #15899: Testcase tcfail158 is broken In-Reply-To: <049.7f6552ee392f2083aa812ec96556b9fa@haskell.org> References: <049.7f6552ee392f2083aa812ec96556b9fa@haskell.org> Message-ID: <064.fe2872ff0dd543e58cc4f7595efffdf5@haskell.org> #15899: Testcase tcfail158 is broken -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12906 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12906 Comment: It's worth noting that `tcfail158` will in fact start reporting these errors once/if the fix for #12906 (Phab:D5338) lands. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 13:57:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 13:57:29 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.725e113c93c6ee5bd907e70bb5774ccb@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.3 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by berdario): * Attachment "symboltable.xz" added. Symbol table for HSinteger-gmp-1.0.2.0.o -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 13:57:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 13:57:33 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.0f6bf3494558d32d2edac894e87ad21b@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.3 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by bgamari): I have been looking into this with Dario Bertini at Munihac. It appears that `___gmp_rands` is a "common" symbol. With linker debugging enabled I see the following output, {{{ relocateSection: making jump island for ___stack_chk_guard, extern = 1, X86_64_RELOC_GOT lookupSymbol: looking up ___stack_chk_guard lookupSymbol: symbol not found lookupSymbol: looking up ___stack_chk_guard with dlsym relocateSection: looked up ___stack_chk_guard, external X86_64_RELOC_GOT or X86_64_RELOC_GOT_LOAD : addr = 0x7fffabebd070 relocateSection: value = 0x10e3e1d50 relocateSection: relocation 8481 : type = 3 : address = 283153 : symbolnum = 4303 : pcrel = 1 : length = 2 : extern = 1 : type = 3 relocateSection: length = 2, thing = 0, baseValue = 0x10e3125f5 relocateSection: making jump island for ___gmp_rands, extern = 1, X86_64_RELOC_GOT lookupSymbol: looking up ___gmp_rands lookupSymbol: symbol not found lookupSymbol: looking up ___gmp_rands with dlsym relocateSection: looked up ___gmp_rands, external X86_64_RELOC_GOT or X86_64_RELOC_GOT_LOAD : addr = 0x0 ghc-stage2: lookupSymbol failed in relocateSection (RELOC_GOT) /Users/berdario/Projects/ghc/libraries/integer-gmp/dist-install/build /HSinteger-gmp-1.0.2.0.o: unknown symbol `___gmp_rands' removeLibrarySearchPath: ptr = `0x0' }}} In principle common symbols do appear to be handled by `ocGetNames_MachO`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 14:10:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 14:10:12 -0000 Subject: [GHC] #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) In-Reply-To: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> References: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> Message-ID: <060.b84dfafd356766144c4f4634d9f1e094@haskell.org> #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.3 (Linking) | Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5292 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Actually, it looks like this shouldn't even fallthrough! Fixing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 14:14:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 14:14:58 -0000 Subject: [GHC] #15905: Data familes should end in Type In-Reply-To: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> References: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> Message-ID: <061.e69c5c319afdfb9762082a114d988c35@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ha ha! I'm in favour of walking (on solid ground) before we run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 14:59:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 14:59:49 -0000 Subject: [GHC] #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) In-Reply-To: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> References: <045.c82d9958b329ffd45f64454bdb7b134e@haskell.org> Message-ID: <060.2ce20b82da6d134c2eb93a625ca22029@haskell.org> #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.3 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5292 Wiki Page: | -------------------------------------+------------------------------------- Changes (by berdario): * status: merge => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 15:07:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 15:07:24 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.8fa552423ed8c6a16b84559941e6d45a@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: None | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by berdario): * milestone: 8.6.3 => 8.6.2 Comment: Thanks to dminuoso, he pointed out that the flag is actually defined for the inner library, and in fact should be toggled differently in the build.mk While running tests with this fix in https://github.com/ghc/ghc/pull/222/files this surfaced test failures due to https://ghc.haskell.org/trac/ghc/ticket/15105 This turned out to be the same behavior in GHC 8.4, unclear why the failures weren't seen before. The .o code for the HSinteger-gmp-1.0.2.0.o had the same symbol table. The bug turned out to be in GHC static linker. We added a bunch more logging statements to the code that reads MachO symbols. It turned out that it was counting the number of external symbols (let's say M), and then going through the first M such symbols in the table (thus ignoring the last N-M symbols). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 15:08:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 15:08:00 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.2eef71246edb489e74b09454f4638541@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: None | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by berdario): * status: new => patch * milestone: 8.6.2 => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 15:15:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 15:15:41 -0000 Subject: [GHC] #15908: Hadrian: Spurious build failure on fresh build Message-ID: <048.a89ef557e46194c4c1aec9053cb7e09a@haskell.org> #15908: Hadrian: Spurious build failure on fresh build -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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: -------------------------------------+------------------------------------- On a freshly checked-out (Windows10 64)ghc tree I was building with hadrian (`hadrian/build.bat -j`). It aborted here: | Run Ghc CompileHs Stage1: libraries/pretty/src/Text/PrettyPrint/Annotated.hs => _build/stage1/libraries/pretty/build/Text/PrettyPrint/Annotated.o | Run Ar Pack Stage1: _build/stage1/libraries/stm/build/Control/Concurrent/STM.p_o (and 9 more) => _build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a C:/Users/ggreif/ghc/inplace/mingw/bin/ar.exe: creating _build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a C:/Users/ggreif/ghc/inplace/mingw/bin/ar.exe: unable to rename '_build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a'; reason: File exists shakeArgsWith 0.001s 0% Function shake 0.317s 0% Database read 0.468s 0% With database 0.013s 0% Running rules 3492.921s 99% ========================= Total 3493.720s 100% Error when running Shake build system: * _build/stage1/lib/package.conf.d/stm-2.5.0.0.conf * _build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a user error (Development.Shake.cmd, system command failed Command: C:/Users/ggreif/ghc/inplace/mingw/bin/ar.exe q _build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a @C:\Users\ggreif\AppData\Local\Temp\extA08E Exit code: 1 Stderr: C:/Users/ggreif/ghc/inplace/mingw/bin/ar.exe: creating _build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a C:/Users/ggreif/ghc/inplace/mingw/bin/ar.exe: unable to rename '_build/stage1/libraries/stm/build/libHSstm-2.5.0.0_p.a'; reason: File exists ) Can this be a concurrency problem, while renaming archives? Anyway it healed after restarting Hadrian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 15:36:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 15:36:36 -0000 Subject: [GHC] #15909: prepareAlts does not take into account equalities which are in scope Message-ID: <049.e4b589ae89c739dd7d9ac3f55f71e325@haskell.org> #15909: prepareAlts does not take into account equalities which are in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- If we consider this program submitted for our consideration by Andres we see some surprising behaviour. https://gist.github.com/kosmikus/237946a2335600690208a4a36efef988 {{{ {-# LANGUAGE TypeOperators, GADTs, FlexibleContexts, DataKinds, RankNTypes, PolyKinds, TypeFamilies, MultiParamTypeClasses, UndecidableInstances, UndecidableSuperClasses, FlexibleInstances, ConstraintKinds, TypeApplications, EmptyCase, ScopedTypeVariables, PartialTypeSignatures, TemplateHaskell #-} module Partition where import Data.Coerce import Data.Kind import Data.Proxy data NP (f :: k -> Type) (xs :: [k]) where Nil :: NP f '[] (:*) :: f x -> NP f xs -> NP f (x : xs) infixr 5 :* strictToPair :: forall f a b . NP f '[a, b] -> (f a, f b) strictToPair np = case np of (fx :* fxs) -> case (fxs {- :: NP f '[b] -}) of (fy :* fys) -> (fx, fy) }}} Both pattern matches are exhaustive so we don't need to generate any failure cases when pattern matching. Notice in the generated core that we have a match on `Partition.Nil` even though the match will never be reached. {{{ Partition.strictToPair :: forall k (f :: k -> *) (a :: k) (b :: k). Partition.NP f '[a, b] -> (f a, f b) [GblId, Arity=1, Str=m, Unf=OtherCon []] Partition.strictToPair = \ (@ k_a1gV) (@ (f_a1gW :: k_a1gV -> *)) (@ (a_a1gX :: k_a1gV)) (@ (b_a1gY :: k_a1gV)) (np_s1yz [Occ=Once!] :: Partition.NP f_a1gW '[a_a1gX, b_a1gY]) -> case np_s1yz of { Partition.:* @ x_a1h2 @ xs_a1h3 co_a1h4 fx_s1yB [Occ=Once] fxs_s1yC [Occ=Once!] -> case fxs_s1yC of { Partition.Nil _ [Occ=Dead, Dmd=] -> Partition.strictToPair1 @ k_a1gV @ a_a1gX @ f_a1gW @ b_a1gY; Partition.:* @ x1_a1h7 @ xs1_a1h8 co1_a1h9 fy_s1yE [Occ=Once] _ [Occ=Dead] -> (fx_s1yB `cast` (_R (Nth:1 (Sym co_a1h4)) :: (f_a1gW x_a1h2 :: *) ~R# (f_a1gW a_a1gX :: *)), fy_s1yE `cast` (_R (Nth:1 (Sym co1_a1h9 ; Nth:2 (Sym co_a1h4))) :: (f_a1gW x1_a1h7 :: *) ~R# (f_a1gW b_a1gY :: *))) } } }}} This is because in `prepareAlts` are try to inspect the type of `fxs` which looks like a type variable, however it has since been refined by the pattern match on `np` above. Adding the explicit type signature to `fxs` makes `prepareAlts` treat it correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 15:51:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 15:51:49 -0000 Subject: [GHC] #15909: prepareAlts does not take into account equalities which are in scope In-Reply-To: <049.e4b589ae89c739dd7d9ac3f55f71e325@haskell.org> References: <049.e4b589ae89c739dd7d9ac3f55f71e325@haskell.org> Message-ID: <064.b37dedfe1f161b15c3196d65db90b4dc@haskell.org> #15909: prepareAlts does not take into account equalities which are in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 RyanGlScott): Here is a much simpler example which demonstrates the issue: {{{#!hs {-# LANGUAGE GADTs #-} module Bug where data T a where TInt :: T Int TBool :: T Bool f1 :: T Int -> () f1 TInt = () f2 :: a ~ Int => T a -> () f2 TInt = () }}} {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs -O2 -ddump-simpl [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ==================== Tidy Core ==================== ... f1 = \ (ds_d1tE :: T Int) -> case ds_d1tE of { TInt co_a1s1 [Dmd=] -> GHC.Tuple.() } ... f2 = \ (@ a_a1rU) _ [Occ=Dead] (ds_d1tf :: T a_a1rU) -> case ds_d1tf of { TInt co_a1rX [Dmd=] -> GHC.Tuple.(); TBool ipv_s1tT [Dmd=] -> Bug.f4 } Bug.f4 = Control.Exception.Base.patError @ 'GHC.Types.LiftedRep @ () lvl_r1v7 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 16:06:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 16:06:13 -0000 Subject: [GHC] #15909: prepareAlts does not take into account equalities which are in scope In-Reply-To: <049.e4b589ae89c739dd7d9ac3f55f71e325@haskell.org> References: <049.e4b589ae89c739dd7d9ac3f55f71e325@haskell.org> Message-ID: <064.ce0d098ebde35299a79bd05aa06c290e@haskell.org> #15909: prepareAlts does not take into account equalities which are in scope -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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): Reasoning about equalities is the business of the typechecker, and the simplifier doesn't do much. But it does do some things; e.g. it tries to reduce type-family applications. It would be reasonable to try to make it do more; and indeed to support the pattern-match overlap stuff we have an API for the typechecker that can be called externally. I don't know if it's the ''right'' API for this purpose. To make this work we'd have to accumulate the "givens" as we go down. Not too hard. I'd be inclined to do this in a separate pass, NOT the simplifier which has too much else to do. Just possibly the occurrence analyser, though I worry about slowing it down. Another tricky point is that I'd like to be able to prove that every case is exhaustive, and a Lint-checkable property. But if I later remove the second parameter to f2 (it is dead) then it won't be provable anymore. This problem is more basic than fancy equalities. Consider {{{ case x of Red -> e1 DEFAULT -> let v = case x of Red -> e2 Blue -> e3 Green -> e4 in blah }}} we can prune the `Red` branch out of the `case` in the RHS of `v`. But now imagine floating the `v`-binding: {{{ let v = case x of Blue -> e3 Green -> e4 in case x of Red -> e1 DEFAULT -> blah }}} This is actually still correct, but it's not ''obviously'' correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 16:07:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 16:07:58 -0000 Subject: [GHC] #15901: Assert and record that code generation requires distinct uiques for let-binders In-Reply-To: <044.667c51a2ab3cbeffd260201fc3c43d63@haskell.org> References: <044.667c51a2ab3cbeffd260201fc3c43d63@haskell.org> Message-ID: <059.32799925863ac56bb90257ca272338d8@haskell.org> #15901: Assert and record that code generation requires distinct uiques for let- binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Resolution: | Keywords: CodeGen 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: => CodeGen Old description: > Simon writes in [https://ghc.haskell.org/trac/ghc/ticket/15754#comment:10 > #15754]: > > Another invariant that the code generator needs is (I believe) that every > let-binder has a distinct unique. We can't re-use the same unique, even > in a different scope, let alone shadowing. > > Why? Because (I believe) that the code generator uses these uniques to > generate unique top level labels for the entry code and info table for > the closure. > > Now, it's probably the case that they are unique anyway; but we should > either > * Write this down as a invariant of STG, or > * Establish this invariant in the immediately-before-codegen pass that > gets the free vars right, or > * Not assume it in the code generator New description: Simon writes in [https://ghc.haskell.org/trac/ghc/ticket/15754#comment:10 #15754]: Another invariant that the code generator needs is (I believe) that every let-binder has a distinct unique. We can't re-use the same unique, even in a different scope, let alone shadowing. Why? Because (I believe) that the code generator uses these uniques to generate unique top level labels for the entry code and info table for the closure. Now, it's probably the case that they are unique anyway; but we should either 1. Write this down as a invariant of STG, or 2. Establish this invariant in the immediately-before-codegen pass that gets the free vars right, or 3. Not assume it in the code generator -- Comment: I have no strong opinion about 1-3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 18:39:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 18:39:53 -0000 Subject: [GHC] #13839: GHC warnings do not respect the default module header In-Reply-To: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> References: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> Message-ID: <063.8a2bf808d23ec775effc1d951767a011@haskell.org> #13839: GHC warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: bug | Status: infoneeded 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 Feuerbach): You are right, I cannot reproduce this by compiling the program either. However, I can reproduce this by loading it into ghci, with both 8.0.1 and 8.6.2. I'll update the description to reflect this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 18:41:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 18:41:54 -0000 Subject: [GHC] #13839: GHC warnings do not respect the default module header In-Reply-To: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> References: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> Message-ID: <063.bdb0bd29a7f17973143658652d9219b0@haskell.org> #13839: GHC warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | 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: | -------------------------------------+------------------------------------- Changes (by Feuerbach): * status: infoneeded => new Old description: > If I compile this program with `-Wall`, I get no warnings: > > {{{#!hs > type T = Int > > main :: IO () > main = return () > }}} > > If I add a module header: > > {{{#!hs > module Main(main) where > > type T = Int > > main :: IO () > main = return () > }}} > > I now get a warning: > > {{{ > ghcbug2.hs:3:1: warning: [-Wunused-top-binds] > Defined but not used: type constructor or class ‘T’ > }}} > > Yet, according to Haskell2010 (section 5.1): > > > An abbreviated form of module, consisting only of the module body, is > permitted. If this is used, the header is assumed to be ‘module > Main(main) where’. > > Therefore, the right behaviour should be to print a warning in the first > case as well. New description: If I load this program in ghci with `-Wall`, I get no warnings: {{{#!hs type T = Int main :: IO () main = return () }}} If I add a module header: {{{#!hs module Main(main) where type T = Int main :: IO () main = return () }}} I now get a warning: {{{ ghcbug2.hs:3:1: warning: [-Wunused-top-binds] Defined but not used: type constructor or class ‘T’ }}} Yet, according to Haskell2010 (section 5.1): > An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be ‘module Main(main) where’. Therefore, the right behaviour should be to print a warning in the first case as well. If I compile the program instead of loading it in ghci, I correctly get the warning in both cases. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 20:54:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 20:54:05 -0000 Subject: [GHC] #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm In-Reply-To: <046.0992e281b492040f72d63791112b8b7a@haskell.org> References: <046.0992e281b492040f72d63791112b8b7a@haskell.org> Message-ID: <061.0ff3c8f67134e25dcb952952af961b56@haskell.org> #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm -------------------------------------+------------------------------------- Reporter: gwright | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.6.1 Resolution: | Keywords: Operating System: FreeBSD | 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 George): * component: Compiler => Compiler (LLVM) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 20:55:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 20:55:00 -0000 Subject: [GHC] #15873: move to llvm 7 for 8.8.1 In-Reply-To: <045.eb24c323c15fc6ee3b2438976dc5b650@haskell.org> References: <045.eb24c323c15fc6ee3b2438976dc5b650@haskell.org> Message-ID: <060.cacf3689c296fb8c7c9ce1fbce3e9f01@haskell.org> #15873: move to llvm 7 for 8.8.1 -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.6.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 George): * component: Compiler => Compiler (LLVM) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 21:11:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 21:11:54 -0000 Subject: [GHC] #15904: hp2ps fail with parse error when the command args contains double quotes In-Reply-To: <046.fc408ba87d45914eacede67a1118c1d0@haskell.org> References: <046.fc408ba87d45914eacede67a1118c1d0@haskell.org> Message-ID: <061.324c7d908c255cc38d1899687be19410@haskell.org> #15904: hp2ps fail with parse error when the command args contains double quotes -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.7 Resolution: | Keywords: hp2ps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5346 Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * differential: => Phab:D5346 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 21:35:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 21:35:43 -0000 Subject: [GHC] #15905: Data familes should end in Type In-Reply-To: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> References: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> Message-ID: <061.2dd719fb3a87c8123ff8a625fe86db95@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't see any reason to throw the baby out with the bathwater here. It's true that extending this feature to work with type families is difficult, but we can continue the status quo. If we want to make sure that we're order-independent, just look for type families in the instantiated kind. If we spot any, fail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 22:25:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 22:25:16 -0000 Subject: [GHC] #15854: PPC: Panic in native code generator In-Reply-To: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> References: <047.7979b48dbbc8c5e6245309f9625463f3@haskell.org> Message-ID: <062.35059b0686a54a7f86bbcdd6f39d47c8@haskell.org> #15854: PPC: Panic in native code generator ----------------------------------------+---------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5300 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by admock): * cc: admock (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 22:59:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 22:59:21 -0000 Subject: [GHC] #15891: Excessive system time during execution of GHC-built executables on macOS In-Reply-To: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> References: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> Message-ID: <062.56a61016956b06641127b659a279dce4@haskell.org> #15891: Excessive system time during execution of GHC-built executables on macOS ---------------------------------+---------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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 goldfire): I should add a few details, inspired by comment:4 - My BuildFlavour = devel2 - Used `make -j5` I needed to `chmod u+s` `dtruss` to get it to work... but then, later, had trouble and so had to revert this change. Just posting here to avoid @gridaphobe problems later. To sample, I ran `sample ghc-stage1` while GHC was compiling in another terminal session. Glad to know I'm not alone here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 16 23:02:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Nov 2018 23:02:55 -0000 Subject: [GHC] #15905: Data familes should end in Type In-Reply-To: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> References: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> Message-ID: <061.b77bf40de6167ab0eb588059aa7e1b97@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): My point is that the status quo is extremely fragile -- it relies crucially on eager unification. It's supposed to be the case that we can defer all unifications to the constraint solver, all all will work. But not so! So now, to give a precise spec, we have to make precise which constraints can be solved eagerly and which can be deferred. I hate that. The baby is mingled with the bathwater -- it's a fluke that it works at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 10:06:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 10:06:06 -0000 Subject: [GHC] #15899: Testcase tcfail158 is broken In-Reply-To: <049.7f6552ee392f2083aa812ec96556b9fa@haskell.org> References: <049.7f6552ee392f2083aa812ec96556b9fa@haskell.org> Message-ID: <064.49ccc9c781ad39b8c737a5047ae98069@haskell.org> #15899: Testcase tcfail158 is broken -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12906 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RolandSenn): Phab:D5338 skips test {{{tcfail158}}}. Hence CI should not be affected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 10:28:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 10:28:17 -0000 Subject: [GHC] #15124: Improve block layout for the NCG In-Reply-To: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> References: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> Message-ID: <062.7a8000172cae7c7235114f93ee20190f@haskell.org> #15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (NCG) | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8082 #14672 | Differential Rev(s): Phab:D4726 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Andreas Klebinger ): In [changeset:"912fd2b6ca0bc51076835b6e3d1f469b715e2760/ghc" 912fd2b6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="912fd2b6ca0bc51076835b6e3d1f469b715e2760" NCG: New code layout algorithm. Summary: This patch implements a new code layout algorithm. It has been tested for x86 and is disabled on other platforms. Performance varies slightly be CPU/Machine but in general seems to be better by around 2%. Nofib shows only small differences of about +/- ~0.5% overall depending on flags/machine performance in other benchmarks improved significantly. Other benchmarks includes at least the benchmarks of: aeson, vector, megaparsec, attoparsec, containers, text and xeno. While the magnitude of gains differed three different CPUs where tested with all getting faster although to differing degrees. I tested: Sandy Bridge(Xeon), Haswell, Skylake * Library benchmark results summarized: * containers: ~1.5% faster * aeson: ~2% faster * megaparsec: ~2-5% faster * xml library benchmarks: 0.2%-1.1% faster * vector-benchmarks: 1-4% faster * text: 5.5% faster On average GHC compile times go down, as GHC compiled with the new layout is faster than the overhead introduced by using the new layout algorithm, Things this patch does: * Move code responsilbe for block layout in it's own module. * Move the NcgImpl Class into the NCGMonad module. * Extract a control flow graph from the input cmm. * Update this cfg to keep it in sync with changes during asm codegen. This has been tested on x64 but should work on x86. Other platforms still use the old codelayout. * Assign weights to the edges in the CFG based on type and limited static analysis which are then used for block layout. * Once we have the final code layout eliminate some redundant jumps. In particular turn a sequences of: jne .foo jmp .bar foo: into je bar foo: .. Test Plan: ci Reviewers: bgamari, jmct, jrtc27, simonmar, simonpj, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, trommler, jmct, carter, thomie, rwbarton GHC Trac Issues: #15124 Differential Revision: https://phabricator.haskell.org/D4726 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 10:36:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 10:36:08 -0000 Subject: [GHC] #15844: Error fetching msys2 tarballs - crt-git In-Reply-To: <044.bfc9857a19082596b12202bbb22c13f4@haskell.org> References: <044.bfc9857a19082596b12202bbb22c13f4@haskell.org> Message-ID: <059.e1638323f92a6e2b3e22547fa9884a75@haskell.org> #15844: Error fetching msys2 tarballs - crt-git -------------------------------------+------------------------------------- Reporter: Viwor | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (make) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): This sounds like an internet connection issue. Your file is being truncated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 11:39:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 11:39:20 -0000 Subject: [GHC] #15702: "-main-is" flag is broken for recent ghc-head In-Reply-To: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> References: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> Message-ID: <064.c7f712f5bf6010823d471b048ef53b69@haskell.org> #15702: "-main-is" flag is broken for recent ghc-head -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5322 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => patch * differential: => Phab:D5322 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 12:52:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 12:52:40 -0000 Subject: [GHC] #12906: GHC fails to typecheck Main module without main In-Reply-To: <045.9f131820c17fbe502671d27a0102f251@haskell.org> References: <045.9f131820c17fbe502671d27a0102f251@haskell.org> Message-ID: <060.17ce3d6ca2f1b7e628ab319880d08e96@haskell.org> #12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: make test | TEST=T12906 Blocked By: | Blocking: Related Tickets: #15899 | Differential Rev(s): Phab:D5338 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"92f81841e885f081bbb079d0dca6eb50b9043d4b/ghc" 92f81841/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="92f81841e885f081bbb079d0dca6eb50b9043d4b" Fix #12906: GHC fails to typecheck Main module without main Summary: The function fail is no longer called immediately after adding the no-main error message to the TcM monad. The rest of the module will be typechecked. Test Plan: make test TEST=T12906 Reviewers: dfeuer, RyanGlScott, ezyang, mpickering, bgamari Reviewed By: RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #12906 Differential Revision: https://phabricator.haskell.org/D5338 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 12:52:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 12:52:40 -0000 Subject: [GHC] #12525: Internal identifiers creeping into :show bindings In-Reply-To: <044.1bd8a372e3005251359006b86de7988e@haskell.org> References: <044.1bd8a372e3005251359006b86de7988e@haskell.org> Message-ID: <059.183d013cebd38fbef639a1c161badfb4@haskell.org> #12525: Internal identifiers creeping into :show bindings -------------------------------------+------------------------------------- Reporter: mniip | Owner: RolandSenn Type: bug | Status: patch Priority: low | Milestone: 8.8.1 Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: make test performance bug | TEST=T12525 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5326 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"921fd890abe0e7267962c9439098b03c94ebdb9b/ghc" 921fd89/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="921fd890abe0e7267962c9439098b03c94ebdb9b" Fix #12525: Remove derived bindings from the TyThings from getBindings Summary: Remove derived OccNames from the list of TyThings returned by the function GHC.getBindings. Therefore the output of the `:show bindings `command will not contain names generated by GHC. Test Plan: make test TEST=T12525 Reviewers: austin, hvr, alanz, angerman, thomie, bgamari, osa1 Reviewed By: osa1 Subscribers: simonpj, osa1, rwbarton, carter GHC Trac Issues: #12525 Differential Revision: https://phabricator.haskell.org/D5326 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 12:52:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 12:52:40 -0000 Subject: [GHC] #15879: Make UniqDSet a newtype In-Reply-To: <044.d015b93ddf01ab30fec5e94dbe79cede@haskell.org> References: <044.d015b93ddf01ab30fec5e94dbe79cede@haskell.org> Message-ID: <059.95f01b05f8653564039fed1387f3a7c7@haskell.org> #15879: Make UniqDSet a newtype -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13114 | Differential Rev(s): Phab:D5313 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"17e771e17e2374f50f39948955e583760f28351f/ghc" 17e771e1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="17e771e17e2374f50f39948955e583760f28351f" More compact Outputable instance for `Uniq(D)Set` Summary: Until now, `UniqSet` and `UniqDSet` inherited their `Outputable` instances from `UniqFM` and `UniqDFM`. That made for verbose and redundant output. This patch rectifies that by pretty-printing these sets in common math notation. E.g., previously, we would render `UniqSet`s like this: [s2fE :-> x_s2fE, s2fF :-> y_s2fF, s2fG :-> z_s2fG, s2fH :-> g_s2fH] Now, they're are printed like this: {x_s2fE, y_s2fF, z_s2fG, g_s2fH} Reviewers: simonpj, bgamari, AndreasK, dfeuer, osa1 Reviewed By: osa1 Subscribers: osa1, rwbarton, carter GHC Trac Issues: #15879 Differential Revision: https://phabricator.haskell.org/D5315 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 12:52:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 12:52:40 -0000 Subject: [GHC] #11477: Remove -Wamp In-Reply-To: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> References: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> Message-ID: <061.92a6dc844ae0704b3c76b31b26ea6599@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.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:D4785 Wiki Page: | Phab:D5296 -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"33f572589d1c40c77d642c79f9cfdd6d84fa7477/ghc" 33f57258/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="33f572589d1c40c77d642c79f9cfdd6d84fa7477" Remove -Wamp flag (#11477) Summary: Add line "The deprecated ghc-flag -Wamp has been removed." to the release notes for 8.8.1 Reviewers: bgamari, monoidal Reviewed By: monoidal Subscribers: rwbarton, carter GHC Trac Issues: #11477 Differential Revision: https://phabricator.haskell.org/D5296 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 12:52:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 12:52:40 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.6faf5281e7dcaa1bc0c7ca4d2df1af88@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: chessai Type: feature request | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"0e7790abf7d19d19f84c86dc95e50beb65462d12/ghc" 0e7790a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e7790abf7d19d19f84c86dc95e50beb65462d12" Fix trac #15702, as a followon to fix for #13704. Summary: The effect of this change is that -main-is changes the default export list for the main module, but does not apply the same change to non-main modules. This fixes some cases where -main-is was used to wrap a module that expected that default behavior (exporting `main`, even when that wasn't the main entry point name). Reviewers: mpickering, monoidal, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #13704, #15702 Differential Revision: https://phabricator.haskell.org/D5322 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 12:52:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 12:52:40 -0000 Subject: [GHC] #15702: "-main-is" flag is broken for recent ghc-head In-Reply-To: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> References: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> Message-ID: <064.7f331291bbc2907961daf85cdc4712a8@haskell.org> #15702: "-main-is" flag is broken for recent ghc-head -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5322 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"0e7790abf7d19d19f84c86dc95e50beb65462d12/ghc" 0e7790a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e7790abf7d19d19f84c86dc95e50beb65462d12" Fix trac #15702, as a followon to fix for #13704. Summary: The effect of this change is that -main-is changes the default export list for the main module, but does not apply the same change to non-main modules. This fixes some cases where -main-is was used to wrap a module that expected that default behavior (exporting `main`, even when that wasn't the main entry point name). Reviewers: mpickering, monoidal, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #13704, #15702 Differential Revision: https://phabricator.haskell.org/D5322 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 12:53:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 12:53:16 -0000 Subject: [GHC] #11477: Remove -Wamp In-Reply-To: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> References: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> Message-ID: <061.ecb3da4a08fe946b782b1401624e72c8@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.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:D4785 Wiki Page: | Phab:D5296 -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 12:54:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 12:54:06 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.024130acececba589370ca6a35b525d8@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: chessai Type: feature request | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 12:54:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 12:54:22 -0000 Subject: [GHC] #15702: "-main-is" flag is broken for recent ghc-head In-Reply-To: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> References: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> Message-ID: <064.dca46ab82672f09a2c7ac7f3fb10efeb@haskell.org> #15702: "-main-is" flag is broken for recent ghc-head -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5322 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 12:55:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 12:55:07 -0000 Subject: [GHC] #12525: Internal identifiers creeping into :show bindings In-Reply-To: <044.1bd8a372e3005251359006b86de7988e@haskell.org> References: <044.1bd8a372e3005251359006b86de7988e@haskell.org> Message-ID: <059.3d6f0c4dcf72145709bba96bd96aae35@haskell.org> #12525: Internal identifiers creeping into :show bindings -------------------------------------+------------------------------------- Reporter: mniip | Owner: RolandSenn Type: bug | Status: closed Priority: low | Milestone: 8.8.1 Component: GHCi | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: make test performance bug | TEST=T12525 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5326 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 12:55:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 12:55:47 -0000 Subject: [GHC] #12906: GHC fails to typecheck Main module without main In-Reply-To: <045.9f131820c17fbe502671d27a0102f251@haskell.org> References: <045.9f131820c17fbe502671d27a0102f251@haskell.org> Message-ID: <060.c6eea5b9abaf7b9df56e5d59aad0dddd@haskell.org> #12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn 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: Other | Test Case: make test | TEST=T12906 Blocked By: | Blocking: Related Tickets: #15899 | Differential Rev(s): Phab:D5338 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 13:43:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 13:43:18 -0000 Subject: [GHC] #15887: Ideas for a better GHCi editing experience In-Reply-To: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> References: <046.6eb817ad9c3812be096d4e4bf9bbdb9a@haskell.org> Message-ID: <061.d1fec13a56d3d4c211f94b73e16d739a@haskell.org> #15887: Ideas for a better GHCi editing experience -------------------------------------+------------------------------------- Reporter: Anchpop | Owner: (none) Type: feature request | Status: closed Priority: high | Milestone: Research | needed Component: Compiler | Version: 8.6.2 Resolution: invalid | Keywords: QoL Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): > 1) The issue of how to enter multiline mode without needing to enter :{ and exit it without needing :}. You can use `:set +m` to obtain this behavior. See also https://github.com /ghc-proposals/ghc-proposals/issues/181 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 13:46:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 13:46:00 -0000 Subject: [GHC] #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 In-Reply-To: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> References: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> Message-ID: <060.5b0685c1358dd82c97f5a03fb69adbf6@haskell.org> #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5348 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * status: new => patch * differential: => Phab:D5348 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 14:01:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 14:01:06 -0000 Subject: [GHC] #15910: GHC missreports import as redundant. Message-ID: <047.21839edde40cf5a0cb039762883519ae@haskell.org> #15910: GHC missreports import as redundant. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 the following code GHC claims the first import is redundant. {{{ import Data.Map (Map) import qualified Data.Map as M type MT = Map }}} {{{ test.hs:5:1: warning: [-Wunused-imports] The qualified import of `Data.Map' is redundant except perhaps to import instances from `Data.Map' To import instances alone, use: import Data.Map() | 5 | import qualified Data.Map as M }}} Reproduceable on 8.4 and HEAD at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 14:30:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 14:30:32 -0000 Subject: [GHC] #15910: GHC missreports import as redundant. In-Reply-To: <047.21839edde40cf5a0cb039762883519ae@haskell.org> References: <047.21839edde40cf5a0cb039762883519ae@haskell.org> Message-ID: <062.77590eb9ba8cb07ad37188b0564b4fc0@haskell.org> #15910: GHC missreports import as redundant. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 monoidal): I think GHC is correct. The error is pointing at the second import, which is redundant: {{{ | 5 | import qualified Data.Map as M }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 14:41:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 14:41:05 -0000 Subject: [GHC] #13839: GHC warnings do not respect the default module header In-Reply-To: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> References: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> Message-ID: <063.2821df35a2f85c47a1451e352e5f8b48@haskell.org> #13839: GHC warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 16:12:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 16:12:38 -0000 Subject: [GHC] #15910: GHC missreports import as redundant. In-Reply-To: <047.21839edde40cf5a0cb039762883519ae@haskell.org> References: <047.21839edde40cf5a0cb039762883519ae@haskell.org> Message-ID: <062.781ebf1eab9712dbd3f0427d3b51a88c@haskell.org> #15910: GHC missreports import as redundant. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 AndreasK): * status: new => closed * resolution: => invalid Comment: I think you are right, my bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 16:21:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 16:21:27 -0000 Subject: [GHC] #15891: Excessive system time during execution of GHC-built executables on macOS In-Reply-To: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> References: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> Message-ID: <062.0d9f8cd14db64076eaa1a0ac1809910a@haskell.org> #15891: Excessive system time during execution of GHC-built executables on macOS ---------------------------------+---------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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 gridaphobe): So I tried a build with gcc as the C compiler, to see if the issue was somehow related to Apple's build of clang. I kicked it off with {{{ > ./configure CC=gcc-8 # installed with `brew` ... Configure completed successfully. Building GHC version : 8.7.20181114 Git commit id : 89fa34ecd326de879145e6d854306eb17722bf6c Build platform : x86_64-apple-darwin Host platform : x86_64-apple-darwin Target platform : x86_64-apple-darwin Bootstrapping using : /usr/local/bin/ghc which is version : 8.4.4 Using (for bootstrapping) : clang # why? Using gcc : gcc-8 which is version : 8.2.0 Building a cross compiler : NO Unregisterised : NO hs-cpp : gcc-8 hs-cpp-flags : -E -undef -traditional ar : ar ld : ld nm : nm libtool : libtool objdump : objdump ranlib : ranlib windres : dllwrap : genlib : Happy : /Users/eseidel13/.local/bin/happy (1.19.9) Alex : /Users/eseidel13/.local/bin/alex (3.2.4) Perl : /usr/bin/perl sphinx-build : xelatex : Using LLVM tools clang : clang llc : opt : HsColour : /Users/eseidel13/.cabal/bin/HsColour Tools to build Sphinx HTML documentation available: NO Tools to build Sphinx PDF documentation available: NO }}} Curiously, even though I specified `CC=gcc-8`, the build insists on using `clang` for some portion of bootstrapping. I'm not sure what exactly that means. The build of `ghc-stage1` went smoothly, as before, but I again started to notice a major uptick in system time once ghc-stage1 was used. The build also failed during the RTS portion, with {{{ rts_dist_HC rts/dist/build/StgCRun.o :0:0: error: error: this directive must appear between .cfi_startproc and .cfi_endproc directives }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 16:41:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 16:41:43 -0000 Subject: [GHC] #15891: Excessive system time during execution of GHC-built executables on macOS In-Reply-To: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> References: <047.5d48bb65e858e8fad89767c8bd2c8917@haskell.org> Message-ID: <062.d957ef05e427f30d42941470c968b7f0@haskell.org> #15891: Excessive system time during execution of GHC-built executables on macOS ---------------------------------+---------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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 gridaphobe): Ah, I just noticed there's a separate `CC_STAGE0` flag that controls the bootstrapping C compiler. I rebuilt GHC with gcc as the bootstrapping C compiler, but it didn't seem to change anything. I did manage to collect a sample of ghc-stage1 this time though. https://gist.github.com/gridaphobe/2ce36816c41568b4317173d016dc73c0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 19:50:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 19:50:23 -0000 Subject: [GHC] #15908: Hadrian: Spurious build failure on fresh build In-Reply-To: <048.a89ef557e46194c4c1aec9053cb7e09a@haskell.org> References: <048.a89ef557e46194c4c1aec9053cb7e09a@haskell.org> Message-ID: <063.1da26b959cedb1853258fcd6fcd9ee87@haskell.org> #15908: Hadrian: Spurious build failure on fresh build -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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 heisenbug): I have just updated the repo and this happened: {{{ _build\stage1\libraries\ghc-prim\build\GHC\PrimopWrappers.hs:6:70: error: Module `GHC.Prim' does not export `Int16#' | 6 | import GHC.Prim (Char#, Int#, Word#, Float#, Double#, Int8#, Word8#, Int16#, Word16#, State#, MutableArray#, Array#, SmallMutableArray#, SmallArray#, MutableByteArray#, ByteArray#, Addr#, StablePtr#, MutableArrayArray#, ArrayArray#, MutVar#, RealWorld, TVar#, MVar#, ThreadId#, Weak#, StableName#, Compact#, BCO#) | ^^^^^^ _build\stage1\libraries\ghc-prim\build\GHC\PrimopWrappers.hs:6:78: error: Module `GHC.Prim' does not export `Word16#' | 6 | import GHC.Prim (Char#, Int#, Word#, Float#, Double#, Int8#, Word8#, Int16#, Word16#, State#, MutableArray#, Array#, SmallMutableArray#, SmallArray#, MutableByteArray#, ByteArray#, Addr#, StablePtr#, MutableArrayArray#, ArrayArray#, MutVar#, RealWorld, TVar#, MVar#, ThreadId#, Weak#, StableName#, Compact#, BCO#) | ^^^^^^^ shakeArgsWith 0.001s 0% Function shake 0.583s 0% Database read 0.980s 0% With database 0.045s 0% Running rules 933.195s 99% ========================= Total 934.803s 100% Error when running Shake build system: * test * _build/stage1/bin/ghc.exe * OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Library, pkgName = "Win32", pkgPath = "libraries/Win32"}, way = v})) * _build/stage1/libraries/Win32/setup-config * _build/stage1/lib/package.conf.d/base-4.12.0.0.conf * OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Library, pkgName = "base", pkgPath = "libraries/base"}, way = v})) * _build/stage1/libraries/base/setup-config * _build/stage1/lib/package.conf.d/ghc-prim-0.5.3.conf * _build/stage1/libraries/ghc-prim/build/libHSghc-prim-0.5.3.a * _build/stage1/libraries/ghc-prim/build/GHC/PrimopWrappers.o * _build/stage1/libraries/ghc-prim/build/GHC/PrimopWrappers.o _build/stage1/libraries/ghc-prim/build/GHC/PrimopWrappers.hi user error (Development.Shake.cmd, system command failed Command: _build/stage0/bin/ghc.exe -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db "-package-db _build/stage1/lib/package.conf.d" "-this-unit-id ghc-prim-0.5.3" "-package-id rts-1.0" -i -i_build/stage1/libraries/ghc-prim/build -i_build/stage1/libraries/ghc-prim/build/autogen -ilibraries/ghc-prim/. -Iincludes -I_build/generated -I_build/stage1/libraries/ghc-prim/build -IC:/Users/ggreif/ghc/_build/stage1/x86_64-windows- ghc-8.7.20181117/rts-1.0/include -I_build/generated -optc- I_build/generated -optP-include -optP_build/stage1/libraries/ghc- prim/build/autogen/cabal_macros.h -optc-fno-stack-protector -odir _build/stage1/libraries/ghc-prim/build -hidir _build/stage1/libraries/ghc- prim/build -stubdir _build/stage1/libraries/ghc-prim/build -Wnoncanonical- monad-instances -optc-Wno-error=inline -c _build/stage1/libraries/ghc- prim/build/GHC/PrimopWrappers.hs -o _build/stage1/libraries/ghc- prim/build/GHC/PrimopWrappers.o -O0 -H64m -this-unit-id ghc-prim -XHaskell2010 -ghcversion- file=C:/Users/ggreif/ghc/_build/generated/ghcversion.h -O -Wno-deprecated- flags -Wno-trustworthy-safe Exit code: 1 Stderr: _build\stage1\libraries\ghc-prim\build\GHC\PrimopWrappers.hs:6:70: error: Module `GHC.Prim' does not export `Int16#' | 6 | import GHC.Prim (Char#, Int#, Word#, Float#, Double#, Int8#, Word8#, Int16#, Word16#, State#, MutableArray#, Array#, SmallMutableArray#, SmallArray#, MutableByteArray#, ByteArray#, Addr#, StablePtr#, MutableArrayArray#, ArrayArray#, MutVar#, RealWorld, TVar#, MVar#, ThreadId#, Weak#, StableName#, Compact#, BCO#) | ^^^^^^ _build\stage1\libraries\ghc-prim\build\GHC\PrimopWrappers.hs:6:78: error: Module `GHC.Prim' does not export `Word16#' | 6 | import GHC.Prim (Char#, Int#, Word#, Float#, Double#, Int8#, Word8#, Int16#, Word16#, State#, MutableArray#, Array#, SmallMutableArray#, SmallArray#, MutableByteArray#, ByteArray#, Addr#, StablePtr#, MutableArrayArray#, ArrayArray#, MutVar#, RealWorld, TVar#, MVar#, ThreadId#, Weak#, StableName#, Compact#, BCO#) | ^^^^^^^ ) }}} Revision is: 36fcf9edee (origin/master, origin/HEAD) Introduce Int16# and Word16# -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 17 21:37:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Nov 2018 21:37:40 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.3d3ffa248651dca2c50e5d5a9781dd09@haskell.org> #9207: Detect obvious cases of infinite recursion. -------------------------------------+------------------------------------- Reporter: mrugiero | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: infinite | recursion 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 bebarker): * status: closed => new * version: 7.8.2 => 8.4.4 * resolution: invalid => Comment: I respectfully disagree with Fuuzetsu's suggestion that there are no obvious cases, here is an example that came up for me recently. I'm somewhat new to Haskell but am also fairly familiar with writing recursive functions in other languages. Probably, this was difficult for me to spot because I wrote it: {{{#!haskell loadImage :: MonadIO m => FilePath -> m HicoImage loadImage fpath = liftIO $ loadImage fpath where loadImg :: FilePath -> IO HicoImage loadImg fp = Image <$> SDL.Image.load fp }}} Now, there are several issues with this function stylistically that probably would have prevented this, such as not really needing the `where` clause and choosing bad naming conventions (`loadImage` and `loadImg`). The good news is for folks who know more about GHC than myself, I think, is this snippet I found in [https://www.reddit.com/r/haskell/comments/6hng6n/which_haskell_features_prevent_guaranteed_loop/dizzvvv another discussion] regarding detecting "syntactic cycles" with GHC. To quote: Core differentiates between a single [https://downloads.haskell.org/~ghc/8.4.4/docs/html/libraries/ghc-8.4.4/CoreSyn.html#v:NonRec NonRec] binding at a time vs. a [https://downloads.haskell.org/~ghc/8.4.4/docs/html/libraries/ghc-8.4.4/CoreSyn.html#v:Rec Rec] binding group. The part of GHC which does the conversion from a single, recursive group to these let nestings is called the Occurence Analyzer. It's basically a strongly connected component analysis, once you have figured out all edges. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 03:21:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 03:21:32 -0000 Subject: [GHC] #15911: internal error: evacuate(static): strange closure type -127533247 Message-ID: <047.7efb34f89faa44ffb4bc7ba48c4f60d0@haskell.org> #15911: internal error: evacuate(static): strange closure type -127533247 -------------------------------------+------------------------------------- Reporter: bfraikin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- internal error: evacuate(static): strange closure type -127533247 (GHC version 8.4.4 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 04:35:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 04:35:29 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.bec7a4a585c8d01d23d020d3d1aedeb1@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): I got my build building again. I'm not sure why my interface files went out of sync. I guess I should re-read and watch the videos about the pipelines and stages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 05:31:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 05:31:53 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible In-Reply-To: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> References: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> Message-ID: <062.ac7353d20ef0019c5ca25a34be5257f1@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- 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: Incorrect | Test Case: warning at compile-time | typecheck/should_compile/T10347 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by -Jie-): We ran into the same issue in our project. Simplified version: {{{ module Test (test) where import Data.Coerce (coerce) newtype N = N Int data Test = Test N test :: Test test = Test $ coerce (0 :: Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 06:27:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 06:27:11 -0000 Subject: [GHC] #15911: internal error: evacuate(static): strange closure type -127533247 In-Reply-To: <047.7efb34f89faa44ffb4bc7ba48c4f60d0@haskell.org> References: <047.7efb34f89faa44ffb4bc7ba48c4f60d0@haskell.org> Message-ID: <062.551ae77056a3cefd5ea33b6c2f581b71@haskell.org> #15911: internal error: evacuate(static): strange closure type -127533247 -------------------------------------+------------------------------------- Reporter: bfraikin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * version: 8.6.2 => 8.4.4 * milestone: 8.6.3 => Comment: Can you please submit a reproducer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 13:03:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 13:03:20 -0000 Subject: [GHC] #15912: Output hadrian build data for cabal-helper tool support Message-ID: <045.7a02a67f3e3eb71f04a6b22dc49e40ac@haskell.org> #15912: Output hadrian build data for cabal-helper tool support -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | Keywords: cabal-helper | Operating System: Unknown/Multiple hadrian tool support | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As a step in the direction of adding tool support for ghc development we can output some meta data from Hadrian to better support the cabal-helper tool. Proposed changes: 1. Add a /cabal.helper file that points to the 3 stage build directories under the default Hadrian build dir: _build. 2. Add a "--cabal-helper" command line option to Hadrian that enables this output. 3. Output /stage/build.helper in JSON format containing per package: * .cabal file path relative to (achieved by prefixing paths with $PROJECTDIR) e.g $PROJECTDIR/libraries/binary/binary.cabal * source path e.g. $PROJECTDIR/libraries/binary/binary.cabal * Build "dist directory", which is the directory containing the setup- config file generated by cabal on build. this is a relative path e.g. libraries/binary/setup-config ## TODO * decide on the naming of files ## Implementation * See: * Packages.ghcPackages * Hadrian.Package.pkgCabalFile -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 13:09:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 13:09:05 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2315913=3A_ghc-8=2E6=2E2_fails_to_build_on_?= =?utf-8?b?czM5MHggKHVucmVnaXN0ZXJpc2VkKTog4oCYc3RnX01VVF9BUlJf?= =?utf-8?q?PTRS=5FFROZEN0=5Finfo=E2=80=99_undeclared_=28first_use?= =?utf-8?q?_in_this_function=29=3B_did_you_mean_=E2=80=98stg=5FMU?= =?utf-8?b?VF9BUlJfUFRSU19GUk9aRU5fRElSVFlfaW5mb+KAmT8=?= Message-ID: <050.5c8d8e19b2fece59f8d8381f971f9a5b@haskell.org> #15913: ghc-8.6.2 fails to build on s390x (unregisterised): ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (make) | Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-8.6 fails to build on s390x (likely any unregisterised build with ghc 8.2 or 8.4) apparently due to some mix up of include files between stage0 and stage1 compilers. {{{ "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -package-db libraries/bootstrapping.conf -this-unit-id ghc-8.6.2 -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/stage1/build -Icompiler/stage1/build -icompiler/stage1/build/./autogen -Icompiler/stage1/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -Icompiler/stage1/build/. -Icompiler/stage1/build/parser -Icompiler/stage1/build/utils -Icompiler/stage1/build/stage1 -optP- include -optPcompiler/stage1/build/./autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.10.1.0 -package-id binary-0.8.6.0 -package-id bytestring-0.10.8.2 -package-id containers-0.5.10.2 -package- id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.6.2 -package-id ghc-boot-th-8.6.2 -package-id ghc-heap-8.6.2 -package-id ghci-8.6.2 -package-id hpc-0.6.0.3 -package-id process-1.6.1.0 -package-id template-haskell-2.14.0.0 -package-id terminfo-0.4.1.2 -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 -DNO_REGS -DNOSMP -optc-DNOSMP -DSTAGE=1 -Rghc-timing -Wcpp-undef -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/Binary.hs -o compiler/stage1/build/Binary.o /tmp/ghc24ef_0/ghc_3.hc: In function ‘cNqW_entry’: /tmp/ghc24ef_0/ghc_3.hc:50988:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 50988 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc:50988:61: error: note: each undeclared identifier is reported only once for each function it appears in | 50988 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘cNra_entry’: /tmp/ghc24ef_0/ghc_3.hc:51045:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 51045 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘sHDG_entry’: /tmp/ghc24ef_0/ghc_3.hc:56499:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56499 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘cO9A_entry’: /tmp/ghc24ef_0/ghc_3.hc:56819:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56819 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc24ef_0/ghc_3.hc: In function ‘cOa5_entry’: /tmp/ghc24ef_0/ghc_3.hc:56907:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56907 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) <> make[1]: *** [compiler/ghc.mk:446: compiler/stage1/build/Binary.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:125: all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 13:16:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 13:16:41 -0000 Subject: [GHC] #15914: haddock-library-1.7.0 fails to build on ppc64 BE Message-ID: <050.f395dc81b971adf8bf5a08abf481d621@haskell.org> #15914: haddock-library-1.7.0 fails to build on ppc64 BE -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Linux Architecture: powerpc64 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was trying to build ghc-8.6.2 for Fedora 28 and it failed on ppc64 (Bigendian) with: {{{ utils/haddock/haddock-library/src/Documentation/Haddock/Types.hs:99:25: error: • GHC internal error: ‘TableRow’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [aIy :-> Type variable ‘id’ = id :: k, rHO :-> ATcTyCon Table :: k -> *, rHP :-> APromotionErr RecDataConPE] • In the type ‘[TableRow id]’ In the definition of data constructor ‘Table’ In the data declaration for ‘Table’ | 99 | { tableHeaderRows :: [TableRow id] | ^^^^^^^^ utils/haddock/dist/build/haddock/autogen/Paths_haddock.hs:41:22: error: • Couldn't match type ‘a’ with ‘String’ Expected type: IO a Actual type: IO String • In the first argument of ‘catchIO’, namely ‘(getEnv "haddock_libdir")’ In the expression: catchIO (getEnv "haddock_libdir") (\ _ -> return libdir) In an equation for ‘getLibDir’: getLibDir = catchIO (getEnv "haddock_libdir") (\ _ -> return libdir) | 41 | getLibDir = catchIO (getEnv "haddock_libdir") (\_ -> return libdir) | ^^^^^^^^^^^^^^^^^^^^^^^ make[1]: *** [utils/haddock/ghc.mk:20: utils/haddock/dist/build/Documentation/Haddock/Types.dyn_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/ghc.mk:20: utils/haddock/dist/build/Paths_haddock.dyn_o] Error 1 utils/haddock/haddock-api/src/Haddock/Syb.hs:22:1: warning: [-Wunused-top- binds] Defined but not used: ‘isType’ | 22 | isType _ = isJust $ eqT @a @b | ^^^^^^ utils/haddock/haddock-api/src/Haddock/Syb.hs:38:1: warning: [-Wunused-top- binds] Defined but not used: ‘everythingBut’ | 38 | everythingBut k f x = let (v, stop) = f x | ^^^^^^^^^^^^^ utils/haddock/haddock-api/src/Haddock/Syb.hs:60:21: warning: [-Wunused- matches] Defined but not used: ‘s’ | 60 | everythingWithState s k f x = | ^ utils/haddock/haddock-api/src/Haddock/Syb.hs:75:1: warning: [-Wunused-top- binds] Defined but not used: ‘everywhereBut’ | 75 | everywhereBut q f x | ^^^^^^^^^^^^^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.6.2 for powerpc64-unknown-linux): urk! lookup local fingerprint $fShowTokenType [] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/iface/MkIface.hs:524:37 in ghc:MkIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [utils/haddock/ghc.mk:20: utils/haddock/dist/build/Haddock/Backends/Hyperlinker/Types.dyn_o] Error 1 make: *** [Makefile:127: all] Error 2 }}} https://koji.fedoraproject.org/koji/taskinfo?taskID=30919315 (the log files are only preserved for 2 weeks) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 13:22:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 13:22:44 -0000 Subject: [GHC] #15216: plugins10 broken In-Reply-To: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> References: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> Message-ID: <061.eaf07beaf520c4e8325ad4f1d7461d14@haskell.org> #15216: plugins10 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): This seems to be working in `master` modulo some rearrangement of some lines in the stderr output: {{{ --- plugins/plugins10.run/plugins10.stdout.normalised 2018-11-18 14:20:45.808554732 +0100 +++ plugins/plugins10.run/plugins10.run.stdout.normalised 2018-11-18 14:20:45.808554732 +0100 @@ -5,14 +5,17 @@ interfacePlugin: GHC.Float interfacePlugin: GHC.Base interfacePlugin: Language.Haskell.TH.Syntax -interfacePlugin: GHC.Types typeCheckPlugin (rn) +interfacePlugin: GHC.Types typeCheckPlugin (tc) interfacePlugin: GHC.Integer.Type +interfacePlugin: GHC.Natural parsePlugin(a) +typeCheckPlugin (rn) interfacePlugin: Language.Haskell.TH.Lib.Internal metaPlugin: return [] metaPlugin: quoteExp stringify "x" interfacePlugin: GHC.CString typeCheckPlugin (rn) +typeCheckPlugin (rn) typeCheckPlugin (tc) *** unexpected failure for plugins10(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 13:23:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 13:23:54 -0000 Subject: [GHC] #9207: Detect obvious cases of infinite recursion. In-Reply-To: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> References: <047.44b70fd14a11be1abb2b5e2eb9e456b0@haskell.org> Message-ID: <062.aef5aad7949cf02b77bc38adcebfd7da@haskell.org> #9207: Detect obvious cases of infinite recursion. -------------------------------------+------------------------------------- Reporter: mrugiero | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: infinite | recursion Operating System: 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): OK, let's forget about the warning caused by not using `loadImg` for a moment. Why should a compiler warn about the body of `loadImage`? I seriously hope that it doesn't warn, because `liftIO` is a method of the `MonadIO` type class, so the compiler has no knowledge whatsoever about it, apart from its type. So passing `loadImage fpath` to it might actually make sense, see the `repeat` example above. If you are lucky and the compiler uses enough optimizations, you might get a warning at `loadImage`'s use sites, because then it might see enough context, but the function alone is perfectly OK from a compiler's point of view. In a lazy language, it's quite hard to distinguish between "wanted infinite recursion" and "unwanted infinite recursion". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 13:27:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 13:27:23 -0000 Subject: [GHC] #15216: plugins10 broken In-Reply-To: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> References: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> Message-ID: <061.4a9bd6ab396a3b61db595f39e0d8aeba@haskell.org> #15216: plugins10 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5350 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * status: new => patch * differential: => Phab:D5350 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 13:38:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 13:38:37 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack In-Reply-To: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> References: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> Message-ID: <061.b112f8298eebd58c53af0503468f90dd@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: qnikst Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15287 | Differential Rev(s): Phab:D5351 Wiki Page: | -------------------------------------+------------------------------------- Changes (by qnikst): * status: new => patch * differential: => Phab:D5351 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 14:06:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 14:06:07 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.67db867114244667e959b47f45d36a10@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): I could reproduce some of the errors on a 970 MP PowerPC running Linux and GHC 8.6.1. It looks to me like the issue is not ARM specific. The MVar and IORef programs run fine on PowerPC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 14:27:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 14:27:48 -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.b20075c74853af578c1893c58cc09c95@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.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): Phab:D4817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by qnikst): * cc: qnikst (added) Comment: List of files that have `mmap`, but do not have `mprotect` around: rts/Linker/LoadArchive.c rts/Linker/Elf.c rts/Linker/M32Alloc.c Should all of them be worked on in one pass or should we do some preparatory work before? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 15:15:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 15:15:45 -0000 Subject: [GHC] #15915: Add CI for integer-simple Message-ID: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> #15915: Add CI for integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Continuous | Version: 8.6.2 Integration | 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 Nov 18 15:17:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 15:17:09 -0000 Subject: [GHC] #15915: Add CI for integer-simple In-Reply-To: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> References: <046.1fae987ea6db2762bfd736a255797d3b@haskell.org> Message-ID: <061.fff00aa8d9f41dc82a7fdd66796f96c1@haskell.org> #15915: Add CI for integer-simple -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Continuous | Version: 8.6.2 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: | -------------------------------------+------------------------------------- Old description: New description: We should make sure that the `integer-simple` build gets tested occasionally. It is apparently currently broken. -- Comment (by bgamari): W -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 20:36:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 20:36:25 -0000 Subject: [GHC] #15126: Opportunity to compress common info table representation. In-Reply-To: <047.6c1989d395bea7068f3a9a80b2222326@haskell.org> References: <047.6c1989d395bea7068f3a9a80b2222326@haskell.org> Message-ID: <062.56748c3efdb362a220db16a7dd73a97f@haskell.org> #15126: Opportunity to compress common info table representation. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4632 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): I've collected some rudimentary stats by analysing the assembly dump for nofib/spectral/Simple. Out of 2233 info tables, the most common three make up 370, with the most common case making up 240 of them. I think that case is the small function return (RET_SMALL) with no pointers on the stack: {{{ .align 8 .quad 0 .long 30 .long 0 block_cD9R_info: }}} But shrinking this further would give up the common info table layout. So hard to judge the complexity and cost of this. For now just documenting this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 22:41:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 22:41:08 -0000 Subject: [GHC] #15894: Cannot find symbol during interactive linking using new-repl on Windows In-Reply-To: <047.e1fd690e2268aff32d437d88b3160edf@haskell.org> References: <047.e1fd690e2268aff32d437d88b3160edf@haskell.org> Message-ID: <062.a99afac096c44c7e81a6a7baf1044b2d@haskell.org> #15894: Cannot find symbol during interactive linking using new-repl on Windows -----------------------------+---------------------------------------- Reporter: YellPika | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Test Case: T15894 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5353 Wiki Page: | -----------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * testcase: => T15894 * differential: => Phab:D5353 * architecture: x86_64 (amd64) => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 18 23:19:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Nov 2018 23:19:41 -0000 Subject: [GHC] #15855: Warn about incomplete NamedFieldPuns patterns In-Reply-To: <051.e93dcaca790961e76627949ac09c5501@haskell.org> References: <051.e93dcaca790961e76627949ac09c5501@haskell.org> Message-ID: <066.cd3b88efb36b264368784d7240c14a8e@haskell.org> #15855: Warn about incomplete NamedFieldPuns patterns -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Artyom.Kazak): > `g R{a,b} = a` This one is already covered by `-fwarn-unused-matches`. > `g R{a, ..} = a` This one is trickier, and I'm in two minds about it. Let's see why. ---- Depending on programmer's intent, different kinds of warnings would be useful for the programmer. I will categorize possible intents below, using JSON encoding as a running example. 1. The programmer wants to handle all fields of the record (since the resulting JSON object should contain them all). They write `toJSON R{..} = ...` or `toJSON R{a, b} = ...`. If a new field is added, they would like the compiler to warn them that their `toJSON` implementation needs to be updated. 2. The programmer wants to handle all fields of the record, except for a specific subset – for instance, one of the fields can be derived from the rest of the data and should be omitted from the resulting JSON object to keep the representation compact. They write `toJSON R{a} = ...`, or `toJSON R{a, b = _}`, or perhaps `toJSON R{..} = ...` (relying on the fact that `-fwarn-unused-matches` doesn't apply here). 3. The programmer wants to handle a subset of fields, and they truly don't care about whatever else the record might contain – for instance, when they know that the resulting JSON will be sent to an endpoint that only inspects certain fields. They write `toJSON R{b}` or, again, `toJSON R{..}`. If we want to give helpful warnings in these three cases, we need to somehow distinguish between these different intents. * If we introduce a warning for omitted fields that are not covered by a pattern or `..`, this lets #1 and #2 to be expressed as `R{a, b}` and `R{a, b = _}` respectively. However, this can be cumbersome when there are many fields. * Alternatively, we could introduce a warning for any names brought into scope that are not used in the function body, which lets #1 and #2 to be expressed as `R{..}` and `R{.., b = _}` respectively, but then for #3 the programmer will be forced to list the fields explicitly – e.g. `R{b}`. I like the second option more and it covers my usecases perfectly, but just to make it clear, it's a rather different feature request than the one I originally had in mind. If you agree that the second one has more merit, I will close this ticket and create a new one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 01:20:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 01:20:53 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux Message-ID: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux ---------------------------------+---------------------------------------- Reporter: pkubaj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: powerpc64 | Type of failure: Building GHC failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+---------------------------------------- I'd like to bootstrap GHC for FreeBSD/powerpc64, but GHC seems to be supported only on Linux for powerpc64 architecture. Relevant code: https://github.com/ghc/ghc/blob/1c2c2d3dfd4c36884b22163872feb87122b4528d/rts/StgCRun.c#L875 https://github.com/ghc/ghc/blob/1c2c2d3dfd4c36884b22163872feb87122b4528d/rts/StgCRunAsm.S#L112 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 01:21:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 01:21:55 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.4093b329f55b52ba84730326fbdd91d4@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pkubaj): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 05:32:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 05:32:52 -0000 Subject: [GHC] #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory In-Reply-To: <044.e7b47664b0b4e75e999d3e8ddaf8b64f@haskell.org> References: <044.e7b47664b0b4e75e999d3e8ddaf8b64f@haskell.org> Message-ID: <059.22e71d52c25d147b46a1dd5c24d0182d@haskell.org> #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory -------------------------------------+------------------------------------- Reporter: int-e | Owner: osa1 Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 8.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 osa1): * Attachment "ghc-stage2.hp" added. Raw retainer profiler output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 05:33:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 05:33:11 -0000 Subject: [GHC] #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory In-Reply-To: <044.e7b47664b0b4e75e999d3e8ddaf8b64f@haskell.org> References: <044.e7b47664b0b4e75e999d3e8ddaf8b64f@haskell.org> Message-ID: <059.57679e43d4ce2852116a44ae7649d16b@haskell.org> #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory -------------------------------------+------------------------------------- Reporter: int-e | Owner: osa1 Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 8.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 osa1): * Attachment "ghc-stage2.svg" added. .svg of the retainer profiler output (generated with hp2pretty) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 05:33:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 05:33:39 -0000 Subject: [GHC] #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory In-Reply-To: <044.e7b47664b0b4e75e999d3e8ddaf8b64f@haskell.org> References: <044.e7b47664b0b4e75e999d3e8ddaf8b64f@haskell.org> Message-ID: <059.4be4942f643cd04364dc1e47c2b1136a@haskell.org> #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory -------------------------------------+------------------------------------- Reporter: int-e | Owner: osa1 Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 8.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: | -------------------------------------+------------------------------------- Comment (by osa1): With Phab:D5351 we can run retainer profiler on ghci so I tried this with `ghci +RTS -hb` and used 50000000 as the input. I've attached the raw output and a .svg generated with hp2pretty. It's not too helpful: the `SYSTEM` retainer is retaining GBs of data but we don't have more details on what the retainer is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 06:10:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 06:10:25 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315913=3A_ghc-8=2E6=2E2_fails_to_bui?= =?utf-8?q?ld_on_s390x_=28unregisterised=29=3A_=E2=80=98stg=5FMUT?= =?utf-8?b?X0FSUl9QVFJTX0ZST1pFTjBfaW5mb+KAmSB1bmRlY2xhcmVkIChm?= =?utf-8?q?irst_use_in_this_function=29=3B_did_you_mean_=E2=80=98?= =?utf-8?b?c3RnX01VVF9BUlJfUFRSU19GUk9aRU5fRElSVFlfaW5mb+KAmT8=?= In-Reply-To: <050.5c8d8e19b2fece59f8d8381f971f9a5b@haskell.org> References: <050.5c8d8e19b2fece59f8d8381f971f9a5b@haskell.org> Message-ID: <065.f45261d9644ab9c4b586f0c76bb2d128@haskell.org> #15913: ghc-8.6.2 fails to build on s390x (unregisterised): ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (make) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This renaming was done in 4075656e8bb2338d9857acfa54f8b9c5e0661f44. The changes: {{{ SMALL_MUT_ARR_PTRS_FROZEN0 -> SMALL_MUT_ARR_PTRS_FROZEN_DIRTY SMALL_MUT_ARR_PTRS_FROZEN -> SMALL_MUT_ARR_PTRS_FROZEN_CLEAN MUT_ARR_PTRS_FROZEN0 -> MUT_ARR_PTRS_FROZEN_DIRTY MUT_ARR_PTRS_FROZEN -> MUT_ARR_PTRS_FROZEN_CLEAN }}} It seems like somehow system GHC's tools or header files are used instead of in-tree ones. Not sure how this is possible though ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 08:29:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 08:29:54 -0000 Subject: [GHC] #15901: Assert and record that code generation requires distinct uiques for let-binders In-Reply-To: <044.667c51a2ab3cbeffd260201fc3c43d63@haskell.org> References: <044.667c51a2ab3cbeffd260201fc3c43d63@haskell.org> Message-ID: <059.257040ae8fccf59cc13b19822227f951@haskell.org> #15901: Assert and record that code generation requires distinct uiques for let- binders -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): This is currently done by CorePrep, and noted explicitly in the comments (`CorePrep.hs`): {{{ 6. Clone all local Ids. This means that all such Ids are unique, rather than the weaker guarantee of no clashes which the simplifier provides. And that is what the code generator needs. We don't clone TyVars or CoVars. The code gen doesn't need that, and doing so would be tiresome because then we'd need to substitute in types and coercions. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 08:39:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 08:39:51 -0000 Subject: [GHC] #15844: Error fetching msys2 tarballs - crt-git In-Reply-To: <044.bfc9857a19082596b12202bbb22c13f4@haskell.org> References: <044.bfc9857a19082596b12202bbb22c13f4@haskell.org> Message-ID: <059.5632ed1fd1b2a9bce2f68e70d5b77e25@haskell.org> #15844: Error fetching msys2 tarballs - crt-git -------------------------------------+------------------------------------- Reporter: Viwor | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (make) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 09:02:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 09:02:04 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible In-Reply-To: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> References: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> Message-ID: <062.80e36ac2c736656df467f9c45e4875f8@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- 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: Incorrect | Test Case: warning at compile-time | typecheck/should_compile/T10347 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I wonder if you get an unused-import warning if you say {{{ import Foo( N( N ) ) where test :: Test test = Test $ coerce (0::Int) }}} That is, does the problem apply to imported newtype constructors too? I took at quick look at what to do. The obvious thing to do is * Make `tcg_dus` into a `TcRef` (like `tcg_keep` and `tcg_used_gres`) * Make the constraint solve add a use to `tcg_dus` when solving `Coercible` constraints. (We'd need to change the representation of `tcg_dus` from a list to an `OrdList` or something, else we'd bet inefficient appends.) * Move `reportUnusedNames` after the type checker. Standing back a bit, we carefully gather `tcg_dus :: [DefUse]`, were `type DefUse = (Maybe Defs, Uses)`. So from {{{ type S = Int type T = S -> R }}} we the `DefUse` pairs `(Just S, {})`, and `(Just T, {S,R})`. The idea is that if `T` is unused we can report `S` as unused too. A simpler alternative is simply to gather all the binders `{S,T}` and all the occurrences `{S,R}` and report things that are defined but not referred to. That would report `T` but not `S`. If you deleted `T` you'd get a new warning about `S`. But it's debatable whether reporting `S` unused is a feature or a bug. It certainly confusing -- you can see a reference to `S` -- and if the lack of a reference to `T` was a mistake, then the unused-S warning is simply distracting. So my thought is this: * Suppose instead of gathering `[DefUse]` we simply gather a `NameSet` of things that are referred to; and report as unused anything that it not referred to. That would be significantly simpler. The defs are the declarations themselves, of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 13:33:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 13:33:29 -0000 Subject: [GHC] #15905: Data familes should end in Type In-Reply-To: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> References: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> Message-ID: <061.2ac4176da2b3963cabc6dbcc2e522407@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Duplicate of #14420? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 14:49:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 14:49:32 -0000 Subject: [GHC] #15917: GHC seems to re-read source of module to produce fancy error msgs Message-ID: <047.fdc3becab13158c1bf9270cbcdd68205@haskell.org> #15917: GHC seems to re-read source of module to produce fancy error msgs -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: 8.6.3 Component: Compiler | Version: 8.2.2 Keywords: re-reading | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Poor/confusing (amd64) | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I had a module with unused name `txFees` in it. I started compilation and in the same time edited code by renaming `txFees` -> `_txFees`. I got the following message: {{{ warning: [-Wunused-matches] Defined but not used: ‘txFees’ | 40 | } _txFees | ^^^^^^ : error: Failing due to -Werror. }}} The screenshot is in the attachment. Notice that message part is about old code (`txFees`), and preview is about new code (`_txFees`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 14:49:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 14:49:46 -0000 Subject: [GHC] #15917: GHC seems to re-read source of module to produce fancy error msgs In-Reply-To: <047.fdc3becab13158c1bf9270cbcdd68205@haskell.org> References: <047.fdc3becab13158c1bf9270cbcdd68205@haskell.org> Message-ID: <062.4fdb49bdfa9be6401ac1ed52d65ca6ab@haskell.org> #15917: GHC seems to re-read source of module to produce fancy error msgs -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: 8.6.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: re-reading Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Heimdell): * Attachment "re-reads.png" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 14:50:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 14:50:08 -0000 Subject: [GHC] #15917: GHC seems to re-read source of module to produce fancy error msgs In-Reply-To: <047.fdc3becab13158c1bf9270cbcdd68205@haskell.org> References: <047.fdc3becab13158c1bf9270cbcdd68205@haskell.org> Message-ID: <062.074e6ba86d0d01edf42081a245e1def4@haskell.org> #15917: GHC seems to re-read source of module to produce fancy error msgs -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: 8.6.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: re-reading Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Heimdell): * cc: @… (removed) * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 15:52:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 15:52:51 -0000 Subject: [GHC] #15917: GHC seems to re-read source of module to produce fancy error msgs In-Reply-To: <047.fdc3becab13158c1bf9270cbcdd68205@haskell.org> References: <047.fdc3becab13158c1bf9270cbcdd68205@haskell.org> Message-ID: <062.87abc9a8f1bd939978a540246d6db412@haskell.org> #15917: GHC seems to re-read source of module to produce fancy error msgs -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: 8.6.3 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: re-reading Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Poor/confusing | (amd64) error message | Test Case: Blocked By: | Blocking: Related Tickets: #15660 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15660 Comment: I think this is a duplicate of #15660. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 16:49:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 16:49:40 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.12f9b0877543586f96bf8ab06653fdea@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 #15867 | Differential Rev(s): Phab:D5324 #15901 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Sebastian Graf ): In [changeset:"47bbc709cb221e32310c6e28eb2f33acf78488c7/ghc" 47bbc70/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="47bbc709cb221e32310c6e28eb2f33acf78488c7" Don't track free variables in STG syntax by default Summary: Currently, `CoreToStg` annotates `StgRhsClosure`s with their set of non- global free variables. This free variable information is only needed in the final code generation step (i.e. `StgCmm.codeGen`), which leads to transformations such as `StgCse` and `StgUnarise` having to maintain this information. This is tiresome and unnecessary, so this patch introduces a trees-to- grow-like approach that only introduces the free variable set into the syntax tree in the code gen pass, along with a free variable analysis on STG terms to generate that information. Fixes #15754. Reviewers: simonpj, osa1, bgamari, simonmar Reviewed By: osa1 Subscribers: rwbarton, carter GHC Trac Issues: #15754 Differential Revision: https://phabricator.haskell.org/D5324 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 17:19:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 17:19:26 -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.7440be05150803e4a7b37d9fef98a6c8@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): I've got lost about what the actual problem is here. The Description says "Oh dear" but fails to elaborate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 19:05:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 19:05:47 -0000 Subject: [GHC] #15918: GHC panic from TypeApplications(?) Message-ID: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> #15918: GHC panic from TypeApplications(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Minimized from https://gist.github.com/Icelandjack/683bd4b79027695ffc31632645c9d58b, I don't expect `Build []` to kind check but ti shouldn't crash. {{{#!hs {-# Language PolyKinds #-} {-# Language TypeFamilies #-} {-# Language ConstraintKinds #-} {-# Language FlexibleContexts #-} {-# Language QuantifiedConstraints #-} {-# Language UndecidableInstances #-} import Data.Kind class Rev f where rev :: f a instance (forall xx. cls xx => Rev xx) => Rev (Build cls) where rev = undefined data Build :: ((k -> Type) -> Constraint) -> (k -> Type) uu = rev :: Build [] a }}} gives a panic {{{ $ ghc-stage2 --interactive -ignore-dot-ghci ~/hs/711_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ~/hs/711_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181029 for x86_64-unknown-linux): ASSERT failed! irred_a1zW :: [(xx_a1zV[sk:3] |> Sym {co_a1zu})] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:1826:53 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 19:09:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 19:09:01 -0000 Subject: [GHC] #15918: GHC panic from TypeApplications(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.8e137b4f1408824e2404ee618b85790c@haskell.org> #15918: GHC panic from TypeApplications(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: > Minimized from > https://gist.github.com/Icelandjack/683bd4b79027695ffc31632645c9d58b, I > don't expect `Build []` to kind check but ti shouldn't crash. > > {{{#!hs > {-# Language PolyKinds #-} > {-# Language TypeFamilies #-} > {-# Language ConstraintKinds #-} > {-# Language FlexibleContexts #-} > {-# Language QuantifiedConstraints #-} > {-# Language UndecidableInstances #-} > > import Data.Kind > > class Rev f where > rev :: f a > > instance (forall xx. cls xx => Rev xx) => Rev (Build cls) where > rev = undefined > > data Build :: ((k -> Type) -> Constraint) -> (k -> Type) > > uu = rev :: Build [] a > }}} > > gives a panic > > {{{ > $ ghc-stage2 --interactive -ignore-dot-ghci ~/hs/711_bug.hs > GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( ~/hs/711_bug.hs, interpreted ) > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.7.20181029 for x86_64-unknown-linux): > ASSERT failed! > irred_a1zW :: [(xx_a1zV[sk:3] |> Sym {co_a1zu})] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/utils/Outputable.hs:1219:5 in > ghc:Outputable > assertPprPanic, called at compiler/typecheck/TcType.hs:1826:53 in > ghc:TcType > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} New description: Minimized from https://gist.github.com/Icelandjack/683bd4b79027695ffc31632645c9d58b, I don't expect `Build []` to kind check but ti shouldn't crash. {{{#!hs {-# Language PolyKinds #-} {-# Language TypeFamilies #-} {-# Language ConstraintKinds #-} {-# Language FlexibleContexts #-} {-# Language QuantifiedConstraints #-} {-# Language UndecidableInstances #-} import Data.Kind class Rev f where rev :: f a instance (forall xx. cls xx => Rev xx) => Rev (Build cls) where rev = undefined data Build :: ((k -> Type) -> Constraint) -> (k -> Type) uu = rev :: Build [] a }}} gives a panic {{{ $ ./ghc-stage2 --interactive -ignore-dot-ghci ~/hs/711_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ~/hs/711_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181029 for x86_64-unknown-linux): ASSERT failed! irred_a1zW :: [(xx_a1zV[sk:3] |> Sym {co_a1zu})] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:1826:53 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 19:09:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 19:09:43 -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.5aa659e32aad21c3c76d24b6c8920d9f@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 monoidal): The definition `data Bool = False | True` defines a closed type: the only values of type `Bool` are `False` and `True`, pattern matching on both of them defines a total function. A function `Bool -> A` is equivalent to a tuple `(A,A)`. It's natural to expect the same behavior on the kind level: the promoted kind `Bool` should have only two inhabitants, type `False` and `True`. Currently, this doesn't hold. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 21:12:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 21:12:52 -0000 Subject: [GHC] #15919: Deprecate split objects Message-ID: <046.27c274e844e4ff1dbb0faff4924870ff@haskell.org> #15919: Deprecate split objects -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- For several reasons (see below) we now generally recommend users use split sections instead of split objects. Reasons: * SplitSections is quite a bit simpler * SplitSections may produce smaller binaries * SplitSections requires fewer assembler invocations, potentially improving compilation time (see #11285, #15051) * SplitSections is the approach used by most C compilers, meaning we may avoid edge cases that SplitObjects may turn up -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 21:37:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 21:37:08 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.9650a1bf33fa71cf8cc8ef4f2a9110f3@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D938, Wiki Page: | Phab:D961 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.2 => 8.8.1 Comment: It sounds like this should be reopened in that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 21:51:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 21:51:49 -0000 Subject: [GHC] #15905: Data familes should end in Type In-Reply-To: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> References: <046.999d8855239640ef49988ee40bf6a29c@haskell.org> Message-ID: <061.095305252f047b1482c0220adeaa1762@haskell.org> #15905: Data familes should end in Type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14645 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah yes. Not quite a duplicate of #14420, but it would nail #14420 inter alia. In particular, the description of #14420 says (a bit impreciseely) "We should require that any instantiation of a data family be to a kind that ends in Type." My proposal in this ticket would make that true automatically, because data family kinds would always end in Type, and hence a fortiori so would their instantiations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 19 21:51:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Nov 2018 21:51:54 -0000 Subject: [GHC] #15920: Implement a flag which disables safe Haskell Message-ID: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> #15920: Implement a flag which disables safe Haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- When adding a plugin to a module, it marks the module as unsafe. If I automatically run a plugin on every module I build then all the modules are therefore marked unsafe. This means that libraries start failing to compile as the safety properties change. However, I don't care about safe haskell and want to turn off this error but there appears to be no way to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 00:35:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 00:35:24 -0000 Subject: [GHC] #1965: Allow unconstrained existential contexts in newtypes In-Reply-To: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> References: <044.685803b9d3f1e49e57aaed63227984b8@haskell.org> Message-ID: <059.18a27244a58c0d392e6d11865fa18235@haskell.org> #1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): Yes for @sgraf's reason I wish we used an equivalence relation on these internal notion of deep representations, and also {{{RuntimeRep}}}s. For example, given matching deep structure (not tracked in the kind/{{{RuntimeRep}}}): {{{ forall a t. exists t' t'. (t :: Kind a) ~R (t' :: Kind TupleRep [a]) ~R (t'' :: Kind SumRep [a]) }}} Maybe it's not worth the extra coercions in practice, but certainly I think its good teaching to pretend newtypes are always: {{{ newtype Foo (a :: k) :: TupleRep [k] = Foo (a :: k) }}} to explain {{{ newtype A :: TupleRep [LiftedRep] = A (Int :: LiftedRep) case undefined of A _ -> 1 }}} contrasted with pretend elaborated unpacked {{{!Int}}}: {{{ data A' :: LiftedRep = A' (!Int :: IntRep) case undefined of A' _ -> undefined }}} That the shallow representations of {{{A}}} and {{{A'}}} have different strictness, opposite what is contained inside, cleanly explains how the `case`-expression has different semantics despite the overall isomorphism of {{{A}}} and {{{A'}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 08:16:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 08:16:18 -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.fc6d63a8f2f6765e54e3423dd31cbc00@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 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 edsko): This is all rather unfortunate. I'd like to be able to write {{{#!hs class (forall b. Show b => Show (T a b)) => C a where type family T a :: * -> * data D a = MkD (T a Int) deriving instance C a => Show (D a) }}} but cannot. @simonpj writes: > "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". But then why can I write {{{#!hs class (Show (T a)) => C a where type family T a :: * data D a = MkD (T a) -- Could not deduce (Show (T a Int)) -- arising from a use of ‘showsPrec’ deriving instance C a => Show (D a) }}} Shouldn't by the same reasoning this fail to work also? (Please don't make it fail though! :-D ) (Yes, it's not quantified, but it's "trivially quantified"; it feels strange to me to allow one but not the other.) Note that for this kind of use case there is no easy workaround; as https://ghc.haskell.org/trac/ghc/ticket/15347#comment:15 points out, it involves adding new type variables to the class, kind of defeating the purpose of having type families in the first place. (Not to mention that I have a ''bunch'' of these type families in my real example.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 09:05:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 09:05:11 -0000 Subject: [GHC] #15921: Foldable.maximumBy uses counter-intuitive ordering Message-ID: <043.f779b3281c29f01383dd9a1b52b48caf@haskell.org> #15921: Foldable.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: List | Operating System: Unknown/Multiple maximumBy minimumBy | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs Data.List.maximumBy (Data.Ord.comparing snd) [(0, 1), (3, 2), (2, 2), (1, 1)] }}} What do you expect the outcome to be? All Haskell-programmers I know that I asked this question, would answer, based on their intuition, `(3, 2)`. However, this is not the behaviour that `Data.List.maximumBy` currently has: Instead, `(2, 2)` (the ''last'' occurrence of a 'maximum' element) is kept. Furthermore, this behaviour is different from the one used by `Data.List.minimumBy`. I would therefore like to request: - If its behaviour is unintentionally different from `minimumBy`, alter the implementation to match it. - If its behaviour is intentionally the opposite, this should be specified in the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 09:05:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 09:05:37 -0000 Subject: [GHC] #15921: Data.List.maximumBy uses counter-intuitive ordering (was: Foldable.maximumBy uses counter-intuitive ordering) In-Reply-To: <043.f779b3281c29f01383dd9a1b52b48caf@haskell.org> References: <043.f779b3281c29f01383dd9a1b52b48caf@haskell.org> Message-ID: <058.0f3bb8d4ed5d63998e0172627bd343dc@haskell.org> #15921: Data.List.maximumBy uses counter-intuitive ordering -------------------------------------+------------------------------------- Reporter: qqwy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: List | maximumBy minimumBy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 09:46:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 09:46:47 -0000 Subject: [GHC] #15660: source file modify race leads to inconsistent error message In-Reply-To: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> References: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> Message-ID: <062.a1a09be3a1b5048fdb475f1abae9e2a6@haskell.org> #15660: source file modify race leads to inconsistent error message -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #15917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15917 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 10:01:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 10:01:54 -0000 Subject: [GHC] #15908: Hadrian: Spurious build failure on fresh build In-Reply-To: <048.a89ef557e46194c4c1aec9053cb7e09a@haskell.org> References: <048.a89ef557e46194c4c1aec9053cb7e09a@haskell.org> Message-ID: <063.911f9b5f9a92199f4d476dbd9fbb21e5@haskell.org> #15908: Hadrian: Spurious build failure on fresh build -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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 alpmestan): * cc: snowleopard, alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 11:08:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 11:08:43 -0000 Subject: [GHC] #15922: Can't make a `binary-dist` on MacOS with Hadrian Message-ID: <050.1b314a27eae75b0a6acd46a801d11095@haskell.org> #15922: Can't make a `binary-dist` on MacOS with Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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: -------------------------------------+------------------------------------- Steps to reproduce on a Mac: {{{ $ ./hadrian/build.sh -c -j "binary-dist" Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: binary-dist * Raised the exception: user error (Development.Shake.cmd, system command failed Command: cp -r _D5316/stage1/lib/x86_64-darwin- ghc-8.7.20181119/rts-1.0/include _D5316/bindist/ghc-8.7.20181119-x86_64 -apple-darwin Exit code: 1 Stderr: cp: _D5316/stage1/lib/x86_64-darwin-ghc-8.7.20181119/rts-1.0/include: No such file or directory ) }}} There is an `_D5316/stage1/lib/x86_64-osx- ghc-8.7.20181119/rts-1.0/include` folder though (note the `darwin`/`osx` difference)... At a glance, I think this is a case of Cabal having a different naming convention then Hadrian's `HostOs` (I'm pretty sure that the folders in `lib` are created by Cabal using its internal convention). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 12:31:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 12:31:19 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.94041e0aaeed617631ed8da872c279cd@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 #15867 | Differential Rev(s): Phab:D5324 #15901 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 13:05:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 13:05:24 -0000 Subject: [GHC] #15923: Skip performance tests if not in a git repo Message-ID: <045.e5c4020e231e1edc79694f98c0600925@haskell.org> #15923: Skip performance tests if not in a git repo -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Keywords: performance | Operating System: Unknown/Multiple tests git notes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12758 Differential Rev(s): | Wiki Page: | Performance/Tests -------------------------------------+------------------------------------- As of #12758 performance tests now compare to the results of the previous commit. Results are stored in git notes. If for some reason the rood directory is not a git repo, we have no results to compare to, nor can we save the new results to git notes. Hence we should skip all performance tests. Such a use case was encountered in simonpj's workflow where he copies/syslinks the work tree without the .git directory before validating. An open question is can we allow performance testing while not in a git repo or by adjusting the workflow? Tasks: * When the ghc root directory is not a git repository, skip all performance tests. * Update the [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests wiki page]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 13:16:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 13:16:41 -0000 Subject: [GHC] #15924: Do not save performance test results if work tree is dirty Message-ID: <045.121dd3b656d573c0db8dc6ca80ec8252@haskell.org> #15924: Do not save performance test results if work tree is dirty -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Keywords: performance | Operating System: Unknown/Multiple tests git notes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 12758 Differential Rev(s): | Wiki Page: | Performance/Tests -------------------------------------+------------------------------------- The test driver will automatically save performance results to git notes. Notes are attached to commits, but if the working tree is dirty, performance characteristics my be affected and the saved results will not be valid. * Only save performance test results if work tree is dirty. * Bonus: don't save to a git note if we have 0 results. * Update wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 13:25:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 13:25:00 -0000 Subject: [GHC] #15925: Production quality bindists for hadrian Message-ID: <048.0f796c5db706ecf53494ae820b60c312@haskell.org> #15925: Production quality bindists for hadrian -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | 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 bindists currently produced by hadrian are largely untested, especially on other platforms than linux. Moreover, we had not made a clear decision on what to do with respect to the relocatable GHCs that hadrian produces and wrapper scripts. We realized that everyone would be happy if: - the bindists follow the in-tree structure of `/stage1`, with `bin` containing the actual programs for most cases, etc. No wrapper script just yet. This way we can just unpack the archive and call `bin/ghc`. We still perhaps need to generate a script for ghci, but that's not really a wrapper, it's just a special case of `ghc` really. - `./configure && make install` would systematically generate wrapper scripts and install everything the way we do in our current bindists. I will look into getting this to work soon and will use this ticket to report progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 13:50:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 13:50:56 -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.01d208a2998046f1b053f8f2662bb935@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: Compiler | 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): * component: Build System (make) => Compiler Comment: Uh, with `Build system` I meant the `ghc --make` compile driver, not the build system that builds GHC. Can we have a `Component:` Trac category for that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 16:29:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 16:29:07 -0000 Subject: [GHC] #15920: Implement a flag which disables safe Haskell In-Reply-To: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> References: <049.d301d55053115f68824dccb46a4e2fc6@haskell.org> Message-ID: <064.1d515bac101d35df63b4acf1e58b93ca@haskell.org> #15920: Implement a flag which disables safe Haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5360 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: normal => high * differential: => Phab:D5360 * milestone: 8.6.3 => 8.8.1 Comment: See D5360 - https://phabricator.haskell.org/D5360 I'm blocked without this fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 18:44:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 18:44:14 -0000 Subject: [GHC] #15922: Can't make a `binary-dist` on MacOS with Hadrian In-Reply-To: <050.1b314a27eae75b0a6acd46a801d11095@haskell.org> References: <050.1b314a27eae75b0a6acd46a801d11095@haskell.org> Message-ID: <065.c8e7a1d79f1dd04430294bcbb059cdd4@haskell.org> #15922: Can't make a `binary-dist` on MacOS with Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5361 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => Phab:D5361 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 21:16:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 21:16:01 -0000 Subject: [GHC] #15908: Hadrian: Spurious build failure on fresh build In-Reply-To: <048.a89ef557e46194c4c1aec9053cb7e09a@haskell.org> References: <048.a89ef557e46194c4c1aec9053cb7e09a@haskell.org> Message-ID: <063.44ee811c6635b5637035cd5d55f1d398@haskell.org> #15908: Hadrian: Spurious build failure on fresh build -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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 snowleopard): There are two closed issues on GitHub which seem related to the `unable to rename` failure: https://github.com/snowleopard/hadrian/issues/203 https://github.com/snowleopard/hadrian/issues/238 In both cases we were unable to reliable reproduce the problem and eventually closed the issues. The `GHC.Prim` issue seem unrelated. Can you reproduce it reliably? If yes, it may deserve a separate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 21:27:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 21:27:33 -0000 Subject: [GHC] #15908: Hadrian: Spurious build failure on fresh build In-Reply-To: <048.a89ef557e46194c4c1aec9053cb7e09a@haskell.org> References: <048.a89ef557e46194c4c1aec9053cb7e09a@haskell.org> Message-ID: <063.26d192cf882d10f65e1d7bf132bc5b92@haskell.org> #15908: Hadrian: Spurious build failure on fresh build -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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 heisenbug): I see. You should be able to reproduce the `GHC.Prim` issue by `git reset --hard 36fcf9edee~1` (be sure to check `git status` first, and save all your work). Now zap your `_build` and redo it. Then `git reset --hard 36fcf9edee` and do an incremental build. This should result in the same error. The reason is probably that when new primitives are introduced, some generators (`genPrim` or such?) need to run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 23:24:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 23:24:10 -0000 Subject: [GHC] #15671: Link errors due to forcibly exporting findPtr In-Reply-To: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> References: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> Message-ID: <059.e2603efa9d5e25de13aaebf7c18aa82e@haskell.org> #15671: Link errors due to forcibly exporting findPtr -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: alpmestan Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10955dyn | T10955 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5138 Wiki Page: | Phab:D5356 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: Phab:D5138 => Phab:D5138 Phab:D5356 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 20 23:57:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Nov 2018 23:57:53 -0000 Subject: [GHC] #15669: T7040_ghci has a suspicious testcase failure In-Reply-To: <044.9d1f4438ef24291d12c76127056f4c24@haskell.org> References: <044.9d1f4438ef24291d12c76127056f4c24@haskell.org> Message-ID: <059.2dc63230251e9e4d0f9a487f331321fc@haskell.org> #15669: T7040_ghci has a suspicious testcase failure ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5364 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D5364 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 00:06:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 00:06:51 -0000 Subject: [GHC] #15674: GADT's displayed type is misleading In-Reply-To: <043.9b768266188379838903cb47df1bf014@haskell.org> References: <043.9b768266188379838903cb47df1bf014@haskell.org> Message-ID: <058.83d22dd083a123a672158b6c54057440@haskell.org> #15674: GADT's displayed type is misleading -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 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 Phyx-): * os: Windows => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple Comment: Not a Windows specific issue, reclassifying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 00:10:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 00:10:23 -0000 Subject: [GHC] #15687: Type synonym unused binds no warning? In-Reply-To: <043.df7d8d1951a81ca970949512dabe7d62@haskell.org> References: <043.df7d8d1951a81ca970949512dabe7d62@haskell.org> Message-ID: <058.cbcaf5992d1366cdab01c8615cb287d2@haskell.org> #15687: Type synonym unused binds no warning? -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * os: Windows => Unknown/Multiple Comment: Not Windows specific, reclassifying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 00:10:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 00:10:26 -0000 Subject: [GHC] #15926: conversion from Integer to Double rounds differently depending on the value Message-ID: <049.39610d5cc42b3ed1fb3230c7d197cb55@haskell.org> #15926: conversion from Integer to Double rounds differently depending on the value --------------------------------------+------------------------------------ Reporter: drvirgilio | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Compiler | Version: 8.6.2 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: --------------------------------------+------------------------------------ I'm not sure if this is intended behavior or a bug. For values less than 2^53^, the the Integer can be represented exactly as a Double so there is no issue. For values from 2^53^ to 2^63^, {{{fromInteger n}}} rounds to the nearest {{{Double}}}, where ties go toward the {{{Double}}} with even least significant bit. This matches the behavior of {{{read}}}. For values between 2^63^ and 2^1024^, {{{fromInteger n}}} ''rounds down'' to the next representable {{{Double}}}. Steps to reproduce: These values are all the same except the last one because it falls just below the threshold for the "round to nearest, ties to even" rule. In this example, (2^63^) and (2^63^-2^10^) are the consecutive values of type {{{Double}}}. {{{#!hs > fromInteger (2^63) :: Double -- exactly 9223372036854775808 9.223372036854776e18 > fromInteger (2^63 - 1) :: Double -- rounded up 9.223372036854776e18 > fromInteger (2^63 - 2^9) :: Double -- rounded up 9.223372036854776e18 > fromInteger (2^63 - 2^9 - 1) :: Double -- rounded down 9.223372036854775e18 > fromInteger (2^63 - 2^10) :: Double -- exactly 9223372036854774784 9.223372036854775e18 }}} Here you can see the behavior of {{{fromInteger}}} matches that of {{{read . show}}} {{{#!hs > (read . show) (2^63) :: Double -- exactly 9223372036854775808 9.223372036854776e18 > (read . show) (2^63 - 1) :: Double -- rounded up 9.223372036854776e18 > (read . show) (2^63 - 2^9) :: Double -- rounded up 9.223372036854776e18 > (read . show) (2^63 - 2^9 - 1) :: Double -- rounded down 9.223372036854775e18 > (read . show) (2^63 - 2^10) :: Double -- exactly 9223372036854774784 9.223372036854775e18 }}} Here you can see {{{fromInteger}}} is rounding down. In this example, (2^64^) and (2^64^-2^11^) are the consecutive values of type {{{Double}}}. {{{#!hs > fromInteger (2^64) :: Double -- exactly 18446744073709551616 1.8446744073709552e19 > fromInteger (2^64 - 1) :: Double -- rounded down 1.844674407370955e19 > fromInteger (2^64 - 2^10) :: Double -- rounded down 1.844674407370955e19 > fromInteger (2^64 - 2^10 - 1) :: Double -- rounded down 1.844674407370955e19 > fromInteger (2^64 - 2^11) :: Double -- exactly 18446744073709549568 1.844674407370955e19 }}} Here you can see the behavior of {{{fromInteger}}} does ''not'' match the behavior of {{{read . show}}} {{{#!hs > (read . show) (2^64) :: Double -- exactly 18446744073709551616 1.8446744073709552e19 > (read . show) (2^64 - 1) :: Double -- rounded up 1.8446744073709552e19 > (read . show) (2^64 - 2^10) :: Double -- rounded up 1.8446744073709552e19 > (read . show) (2^64 - 2^10 - 1) :: Double -- rounded down 1.844674407370955e19 > (read . show) (2^64 - 2^11) :: Double -- exactly 18446744073709549568 1.844674407370955e19 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 06:34:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 06:34:15 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.1fb496e45ab90925776a94ad2602055f@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15578 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 10:30:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 10:30:34 -0000 Subject: [GHC] #15927: Weird interaction between fundeps and overlappable instances Message-ID: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> #15927: Weird interaction between fundeps and overlappable instances -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code {{{#!hs class MyState s m | m -> s where getMyState :: m s instance {-# OVERLAPPABLE #-} (MyState s m, MonadTrans t, Monad m) => MyState s (t m) where getMyState = lift getMyState instance Monad m => MyState s (StateT s m) where getMyState = get f :: (MyState Int m, MyState Char m, MonadIO m) => m () f = do int <- getMyState str <- getMyState liftIO $ putStrLn (replicate int str) works1 :: (MyState s m, Show s, MonadIO m) => m () works1 = do a <- getMyState liftIO (print a) works2 = runStateT (runStateT f (5 :: Int)) 'a' }}} It defines a class similar to `MonadState` of mtl. There is a functional dependency in place, just like with `MonadState` and we can see that it works the same because `works1` compiles where `a` would have an ambiguous type otherwise. The `f` function "shouldn't" compile because it's using two different states at once subverting the functional dependency restriction. It does however compile because an explicit type signature is provided with an unsolvable constraint. Now the really weird part is that `works2` also compiles and produces the expected result even though it's using `f`. Here's what I think is happening: instance resolution is looking for `MyState Int (StateT Char m)` and it finds the `MyState s (StateT s m)` instance. Instead of complaining that `Int` doesn't match `Char` (due to the fundep), it just rejects the instance and takes the overlappable one that does match. In the case where the state is unknown (i.e. both instances match), the fundep kicks in. That's why `runStateT works1 True` works. Is this intended behavior? It seems pretty useful in some situations and I've tested this with 8.2 and 8.6 with the same results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 11:48:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 11:48:31 -0000 Subject: [GHC] #15923: Skip performance tests if not in a git repo In-Reply-To: <045.e5c4020e231e1edc79694f98c0600925@haskell.org> References: <045.e5c4020e231e1edc79694f98c0600925@haskell.org> Message-ID: <060.6d3160c98a78ebfde5d2f0e98ec81c52@haskell.org> #15923: Skip performance tests if not in a git repo -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12758 | Differential Rev(s): Wiki Page: | Performance/Tests | -------------------------------------+------------------------------------- Changes (by davide): * owner: (none) => davide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 11:48:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 11:48:53 -0000 Subject: [GHC] #15924: Do not save performance test results if work tree is dirty In-Reply-To: <045.121dd3b656d573c0db8dc6ca80ec8252@haskell.org> References: <045.121dd3b656d573c0db8dc6ca80ec8252@haskell.org> Message-ID: <060.225e8fee0a33b417478e20f523e776f9@haskell.org> #15924: Do not save performance test results if work tree is dirty -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12758 | Differential Rev(s): Wiki Page: | Performance/Tests | -------------------------------------+------------------------------------- Changes (by davide): * owner: (none) => davide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 11:49:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 11:49:45 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.a1d1e1cd7933101830c1f75a44648280@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): D5367 Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * differential: => D5367 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 11:51:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 11:51:21 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.7d36a4c3b57d9a900a3ed2d8051746cc@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): D5312 Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * differential: D5367 => D5312 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 11:52:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 11:52:19 -0000 Subject: [GHC] #15923: Skip performance tests if not in a git repo In-Reply-To: <045.e5c4020e231e1edc79694f98c0600925@haskell.org> References: <045.e5c4020e231e1edc79694f98c0600925@haskell.org> Message-ID: <060.032f6960e6c76bc7ccb99229de659de0@haskell.org> #15923: Skip performance tests if not in a git repo -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12758 | Differential Rev(s): D5367 Wiki Page: | Performance/Tests | -------------------------------------+------------------------------------- Changes (by davide): * differential: => D5367 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 12:09:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 12:09:31 -0000 Subject: [GHC] #15923: Skip performance tests if not in a git repo In-Reply-To: <045.e5c4020e231e1edc79694f98c0600925@haskell.org> References: <045.e5c4020e231e1edc79694f98c0600925@haskell.org> Message-ID: <060.4ddc899445e7ed45c6ca05fca3c7f8b1@haskell.org> #15923: Skip performance tests if not in a git repo -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12758 | Differential Rev(s): D5367 Wiki Page: | Performance/Tests | -------------------------------------+------------------------------------- Comment (by osa1): > When the ghc root directory is not a git repository, skip all performance tests. Is this really what we want? It doesn't make sense to me to skip performance tests simply because we're not in a git repo, as it doesn't indicate that I'm not interested in performance tests. Why not just skip recording perf numbers when not in a git repo instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 12:54:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 12:54:18 -0000 Subject: [GHC] #15928: Reduction stack overflow when using "coerce" Message-ID: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> #15928: Reduction stack overflow when using "coerce" -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the following snippet results in a "Reduction stack overflow" error message: {{{#!hs {-# Language ScopedTypeVariables #-} {-# Language RankNTypes #-} import Data.Functor.Identity import Data.Coerce newtype Stream m a = Stream { unStream :: forall r. (Stream m a -> m r) -> m r } newtype SerialT m a = SerialT (Stream m a) g :: SerialT Identity a -> Identity Bool g m = undefined idSerial :: SerialT Identity a -> SerialT Identity a idSerial = id f :: SerialT Identity a -> Identity Bool f = g . idSerial . coerce main = undefined }}} The following error message is produced on compiling this with ghc-8.6.2: {{{ xy.hs:26:20: error: • Reduction stack overflow; size = 201 When simplifying the following type: Coercible ((Stream Identity a -> Identity r) -> Identity r) ((Stream Identity a0 -> Identity r) -> Identity r) 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 second argument of ‘(.)’, namely ‘coerce’ In the second argument of ‘(.)’, namely ‘idSerial . coerce’ In the expression: g . idSerial . coerce | 26 | f = g . idSerial . coerce | ^^^^^^ }}} When I use an inline signature like this: {{{#!hs f :: SerialT Identity a -> Identity Bool f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce main = undefined }}} It again results in the same error: {{{ xy.hs:18:60: error: • Reduction stack overflow; size = 201 When simplifying the following type: Coercible ((Stream Identity a -> Identity r) -> Identity r) ((Stream Identity a0 -> Identity r) -> Identity r) 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 second argument of ‘(.)’, namely ‘coerce’ In the second argument of ‘(.)’, namely ‘(id :: SerialT Identity a -> SerialT Identity a) . coerce’ In the expression: g . (id :: SerialT Identity a -> SerialT Identity a) . coerce | 18 | f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce | ^^^^^^ }}} Everything works fine is I use an inline signature with a `forall` keyword like this: {{{#!hs f :: forall a. SerialT Identity a -> Identity Bool f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce }}} I have following questions: 1) Why the first version results in a panic? Is that a bug? 2) The second version might possibly be incorrect code because the types do not unify, but still it should not result in a panic, because of the panic I could not figure out what the problem is. It took a long time to isolate the code and then do some trial and error on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 12:55:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 12:55:52 -0000 Subject: [GHC] #15924: Do not save performance test results if worktree is dirty (was: Do not save performance test results if work tree is dirty) In-Reply-To: <045.121dd3b656d573c0db8dc6ca80ec8252@haskell.org> References: <045.121dd3b656d573c0db8dc6ca80ec8252@haskell.org> Message-ID: <060.f995d087a5b82774f2cf7153ab1f91d1@haskell.org> #15924: Do not save performance test results if worktree is dirty -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12758 | Differential Rev(s): D5368 Wiki Page: | Performance/Tests | -------------------------------------+------------------------------------- Changes (by davide): * differential: => D5368 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 14:12:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 14:12:50 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack In-Reply-To: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> References: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> Message-ID: <061.cc504df18a73813e9a04c7e95d625bb4@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: qnikst Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Profiling | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15287 | Differential Rev(s): Phab:D5351 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.6.3 Comment: Let's try to get this in to 8.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 14:50:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 14:50:56 -0000 Subject: [GHC] #15924: Do not save performance test results if worktree is dirty In-Reply-To: <045.121dd3b656d573c0db8dc6ca80ec8252@haskell.org> References: <045.121dd3b656d573c0db8dc6ca80ec8252@haskell.org> Message-ID: <060.8d38d449da1a99847ea1e9fa02367fbd@haskell.org> #15924: Do not save performance test results if worktree is dirty -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12758 | Differential Rev(s): D5368 Wiki Page: | Performance/Tests | -------------------------------------+------------------------------------- Comment (by osa1): Are we currently generating these notes in the committer's system? What happens if I commit without running perf tests? What happens if my computer is too slow or fast and generates deviated numbers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 15:49:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 15:49:37 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.68c3e1710d247da09089c825bfa34b58@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > Nofib is the standard tool GHC developers use to benchmark changes to the > compiler. Its overall design is OK but it's had no love and care for many > years and has bittrotted such that it isn't useful in a lot of > situations. > > This task is about making nofib useful again. > > The breakdown for this is something like: > > 1. Think and maybe fix nofib framework design. It has 'ways' which I > think correspond to compilation method but more in the sense of 'dynamic' > vs 'static', seems it may not suite being able to use ways for 'fasm' vs > 'fllvm'. There is also the concept of 'modes' which corresponds to > different benchmark input. So 'normal' and 'slow' for getting different > run-times. At moment no easy way to select which benchmark groups to run, > so may want to change that. I guess we should just decide, what knobs do > we want to be able to easily tweak, and see how well the current design > allows that. > > '''Note''' there is a shake build system attached that does a lot of this > (done by Neil Mitchell!). An explanation of it can be found here: > http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using- > shake.html > > The design discussion of it is mostly lost as it was done on private > email sorry. > > 2. Fixup the runtimes for benchmarks to be significant. This might be > best done by changing the way we run benchmarks and collect results to > make sure they are meaningful. > > E.g., Lots of great discussion and links to papers on this thread > > http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html > > 3. Above task is to fix normal but we may want to fixup slow as well and > perhaps add a 'fast' mode where benchmarks run in around 1 second. > > 4. Maybe add more benchmarks to the suite (text, bytestring, performance > regressions from ghc testsuite, vector....) New description: Nofib is the standard tool GHC developers use to benchmark changes to the compiler. Its overall design is OK but it's had no love and care for many years and has bittrotted such that it isn't useful in a lot of situations. This task is about making nofib useful again. The breakdown for this is something like: 1. Think and maybe fix nofib framework design. It has 'ways' which I think correspond to compilation method but more in the sense of 'dynamic' vs 'static', seems it may not suite being able to use ways for 'fasm' vs 'fllvm'. There is also the concept of 'modes' which corresponds to different benchmark input. So 'normal' and 'slow' for getting different run-times. At moment no easy way to select which benchmark groups to run, so may want to change that. I guess we should just decide, what knobs do we want to be able to easily tweak, and see how well the current design allows that. '''Note''' there is a shake build system attached that does a lot of this (done by Neil Mitchell!). An explanation of it can be found here: http://neilmitchell.blogspot.com/2013/02/a-nofib-build-system-using- shake.html The design discussion of it is mostly lost as it was done on private email sorry. 2. Fixup the runtimes for benchmarks to be significant. This might be best done by changing the way we run benchmarks and collect results to make sure they are meaningful (cf. #15357). E.g., Lots of great discussion and links to papers on this thread http://www.haskell.org/pipermail/ghc-devs/2013-February/000307.html 3. Above task is to fix normal but we may want to fixup slow as well and perhaps add a 'fast' mode where benchmarks run in around 1 second. 4. Maybe add more benchmarks to the suite (text, bytestring, performance regressions from ghc testsuite, vector....) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 16:13:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 16:13:45 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.a67292ca3af72677360d6b36c19c7885@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 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): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > In Trac #14346 we proposed the new `with#` primop > {{{ > with# :: a -> (State# s -> (# State# s, b #)) -> State# s -> (# State# s, > b #) > }}} > This ticket is to track progress. > > See ​Phab:D4110. New description: In Trac #14346 we proposed the new `with#` primop {{{#hs with# :: a -> (State# s -> (# State# s, b #)) -> State# s -> (# State# s, b #) }}} This ticket is to track progress. See ​Phab:D4110. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 17:30:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 17:30:23 -0000 Subject: [GHC] #15906: Stable name allocation causes heap corruption when GC is triggered in the primop In-Reply-To: <043.dc1662ef67173abf865b687c84575bba@haskell.org> References: <043.dc1662ef67173abf865b687c84575bba@haskell.org> Message-ID: <058.a7a87d306fdd632efbf779789137b805@haskell.org> #15906: Stable name allocation causes heap corruption when GC is triggered in the primop -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5342 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"691aa715cf43bf9d88ee32bca37e471bae35adfb/ghc" 691aa715/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="691aa715cf43bf9d88ee32bca37e471bae35adfb" Fix heap corruption during stable name allocation See #15906 for the problem. To fix we simply call `allocate()` instead of `ALLOC_PRIM()`. `allocate()` does not trigger GC when the nursery is full, instead it extends it. Test Plan: This validates. memo001 now passes with `-debug` compile parameter. I'll add another test that runs memo001 with `-debug` once I figure out how to use stdout files for multiple tests. Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15906 Differential Revision: https://phabricator.haskell.org/D5342 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 17:31:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 17:31:15 -0000 Subject: [GHC] #15906: Stable name allocation causes heap corruption when GC is triggered in the primop In-Reply-To: <043.dc1662ef67173abf865b687c84575bba@haskell.org> References: <043.dc1662ef67173abf865b687c84575bba@haskell.org> Message-ID: <058.7fc1a3cf18c2b27d293e2daac6a00b77@haskell.org> #15906: Stable name allocation causes heap corruption when GC is triggered in the primop -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.3 Component: Runtime System | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5342 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 18:45:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 18:45:01 -0000 Subject: [GHC] #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile Message-ID: <049.49521fa347356f7d5677b43e8c7f8d37@haskell.org> #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- LLVM has support for XRay which is a tracing framework developed by Google. It might be possible to add the relevant function attributes to the IR we generate to get access to detailed traces which can be analysed using existing tooling. https://llvm.org/docs/XRay.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 19:09:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 19:09:31 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.df289877e476f1adf62b1a0bdb287aa6@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Phab:D5312 Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * differential: D5312 => Phab:D5312 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 19:59:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 19:59:42 -0000 Subject: [GHC] #15927: Weird interaction between fundeps and overlappable instances In-Reply-To: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> References: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> Message-ID: <063.53a517e1e4829d2915a7ad2e71bc4dc5@haskell.org> #15927: Weird interaction between fundeps and overlappable instances -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 15632 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AntC): * keywords: => FunctionalDependencies * related: => 10675, 15632 Comment: Yes you could always evade FunDep consistency like that -- see #10675 at "bogus"; or #15632 for a cut-down example. Well done for getting that inconsistency into the same constraint! There's nothing stopping you putting a bunch of constraints that are together unsatisfiable. That would usually mean you couldn't use `f`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 20:02:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 20:02:48 -0000 Subject: [GHC] #15632: Undependable Dependencies In-Reply-To: <043.01997ce1746c591111a0a2273155036b@haskell.org> References: <043.01997ce1746c591111a0a2273155036b@haskell.org> Message-ID: <058.e2b8a45db0cfb46886632b66869f3d7b@haskell.org> #15632: Undependable Dependencies -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | FunctionalDependencies, | OverlappingInstances Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 9210, | Differential Rev(s): 8634, 15135, 15927 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by AntC): * related: 10675, 9210, 8634, 15135 => 10675, 9210, 8634, 15135, 15927 Comment: See #15927, where inconsistent constraints are put on the same function, and apparently do something useful(?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 20:08:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 20:08:01 -0000 Subject: [GHC] #15930: Add @since-annotations to the Foldable methods Message-ID: <046.1181e048db0e902f4cec12b70c302d38@haskell.org> #15930: Add @since-annotations to the Foldable methods -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Core | Version: 8.6.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Methods like `sum` were added some time after `Foldable`'s inception. It would be nice to know when exactly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 20:12:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 20:12:25 -0000 Subject: [GHC] #15931: MonoLocalBinds + MonomorphismRestriction prevents generalization for a top level definition Message-ID: <051.08b58951f32661e25ca9a568a4419cd9@haskell.org> #15931: MonoLocalBinds + MonomorphismRestriction prevents generalization for a top level definition -------------------------------------+------------------------------------- Reporter: theindigamer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple MonoLocalBinds, | MonomorphismRestriction | 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 code sample {{{#!haskell {-# LANGUAGE MonoLocalBinds #-} {-# LANGUAGE MonomorphismRestriction #-} tmp = 10 picker x y = if tmp > 11 then x else y main = do print (picker "x" "y") print (picker 10 11) }}} It fails with the misleading error message "* No instance for (Num [Char]) arising from the literal `10'...", from what seems to be an interaction between MonoLocalBinds and MonomorphismRestriction (turn either off and the error goes away). Should this be happening only for local bindings, or is it correct for this error to occur for top-level definitions too? In either case, would it be possible to give a better error message here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 21:01:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 21:01:05 -0000 Subject: [GHC] #15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered Message-ID: <045.3f184822d5d026ff6ca31854ce0f9e7a@haskell.org> #15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered -------------------------------------+------------------------------------- Reporter: davean | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.3 Component: Code Coverage | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When testing coverage of test cases, HPC does not report some instances as receiving coverage even though it seems they are. Particularly, when one hand derives the functions they show full coverage. The specific instances in question appear to be ones derived via DeriveFunctor and GeneralizedNewtypeDeriving. Problems have been observed with at least Functor, Applicative, and Monad. A minimal example is attached, and available as a cabal project at https://code.xkrd.net/davean/minimal-coverage-test. To reproduce, run "cabal v2-test --enable-coverage" and view the resulting coverage HTML files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 21:01:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 21:01:40 -0000 Subject: [GHC] #15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered In-Reply-To: <045.3f184822d5d026ff6ca31854ce0f9e7a@haskell.org> References: <045.3f184822d5d026ff6ca31854ce0f9e7a@haskell.org> Message-ID: <060.3b87d64d1a31659dce9cf12bcf1615a7@haskell.org> #15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered -------------------------------------+------------------------------------- Reporter: davean | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.3 Component: Code Coverage | Version: 8.6.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: | -------------------------------------+------------------------------------- Changes (by davean): * Attachment "Cov.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 21:01:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 21:01:51 -0000 Subject: [GHC] #15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered In-Reply-To: <045.3f184822d5d026ff6ca31854ce0f9e7a@haskell.org> References: <045.3f184822d5d026ff6ca31854ce0f9e7a@haskell.org> Message-ID: <060.6b7cbfc1bbc86caaa4b1cc18d2709699@haskell.org> #15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered -------------------------------------+------------------------------------- Reporter: davean | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.3 Component: Code Coverage | Version: 8.6.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: | -------------------------------------+------------------------------------- Changes (by davean): * Attachment "test.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 22:20:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 22:20:35 -0000 Subject: [GHC] #15927: Weird interaction between fundeps and overlappable instances In-Reply-To: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> References: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> Message-ID: <063.1bb9e6f9edeba1ab018536f0925d308d@haskell.org> #15927: Weird interaction between fundeps and overlappable instances -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 15632 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Darwin226): I'm sorry if you addressed this in your comment and I'm just not getting it, but note that I'm not just declaring `f` with and unsatisfyable constraint. I'm also able to satisfy it! So writing {{{#!hs g :: StateT Int (StateT Char IO) () g = f }}} works. So are you saying that this behavior can be relied on? Is my code likely to get broken in newer GHC versions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 22:46:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 22:46:56 -0000 Subject: [GHC] #15931: MonoLocalBinds + MonomorphismRestriction prevents generalization for a top level definition In-Reply-To: <051.08b58951f32661e25ca9a568a4419cd9@haskell.org> References: <051.08b58951f32661e25ca9a568a4419cd9@haskell.org> Message-ID: <066.a7fa6ca8f542f41631487f522ef0169d@haskell.org> #15931: MonoLocalBinds + MonomorphismRestriction prevents generalization for a top level definition -------------------------------------+------------------------------------- Reporter: theindigamer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | MonoLocalBinds, | MonomorphismRestriction 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): Hmm. Here is what is happening. * `tmp` is not generalise because of the monomorphism restriction. So we get `tmp :: alpha`, for some as-yet-unknown type `alpha`; plus the constraint `Num alpha`. * `MonoLocalBinds` prevents generalisation of a binding if it mentions anything that has an open type; that is, a type with free type variables. `tmp` does, so `picker` is not generalised. So it gets type `picker :: gamma -> gamma -> gamma`. * Now we apply picker to both `[Char]` (from `picker "x" "y"`) and `delta` (where we also need `Num delta`) from `picker 10 11`. So we say `gamma := delta := [Char]` and get stuck on `Num [Char]`. That's the diagnosis. The error message is unhelpful -- but it's not obvious to me how to improve it. What error message would you like? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 23:02:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 23:02:35 -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.2ae9efb34198f47815f9fd28039b272c@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.8.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 tuxArg): Hi, It seems this bug is affecting me. I'm benchmarking my code (not test suites) with stack. The code does many zipWith, map and foldl over storable vectors with double values. Here are some rts stats comparison between 8.0.2 (last stack ok, lts-9.21) and 8.2.2 (lts-10.0): {{{ ghc 8.0.2: 66,593,737,608 bytes allocated in the heap 930,040,096 bytes copied during GC 15 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 10101 colls, 0 par 1.424s 1.548s 0.0002s 0.0014s Gen 1 879 colls, 0 par 0.408s 0.377s 0.0004s 0.0018s Total time 74.408s ( 75.442s elapsed) %GC time 2.5% (2.6% elapsed) Alloc rate 917,572,442 bytes per MUT second Productivity 97.5% of total user, 97.4% of total elapsed ghc 8.2.2: 317,181,489,136 bytes allocated in the heap 1,806,653,248 bytes copied during GC 15 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 68766 colls, 0 par 3.700s 3.448s 0.0001s 0.0024s Gen 1 1542 colls, 0 par 0.164s 0.157s 0.0001s 0.0009s Total time 118.112s (119.443s elapsed) %GC time 3.3% (3.0% elapsed) Alloc rate 2,776,254,193 bytes per MUT second Productivity 96.7% of total user, 97.0% of total elapsed }}} Is there any known workaround?. This issue is not allowing me to upgrade from ghc 8.0.2. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 21 23:27:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Nov 2018 23:27:11 -0000 Subject: [GHC] #15931: MonoLocalBinds + MonomorphismRestriction prevents generalization for a top level definition In-Reply-To: <051.08b58951f32661e25ca9a568a4419cd9@haskell.org> References: <051.08b58951f32661e25ca9a568a4419cd9@haskell.org> Message-ID: <066.a81358e02c7b7211a5865f4d18a9d717@haskell.org> #15931: MonoLocalBinds + MonomorphismRestriction prevents generalization for a top level definition -------------------------------------+------------------------------------- Reporter: theindigamer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | MonoLocalBinds, | MonomorphismRestriction 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 theindigamer): ==== Proposal 1 (somewhat radical) In my experience, such error messages (the ones which are inaccurate, in contrast to most other messages) very often involve the MonomorphismRestriction in one way or another, as well as some function in the middle not having an explicit signature. Often the problem will go away once you add that missing signature. So, if you get an error with MonomorphismRestriction on, and the error involves functions which do not have explicit signatures ("involves" would need to be more precisely defined...) - try turning it off and see if the error goes away. If it does, inform the user the "hey, MonomorphismRestriction is causing a problem, so please annotate foo with the type X" that I inferred with NoMonomorphismRestriction. I don't know how practical this is or whether it could lead to undesirable consequences. ==== Proposal 2 In this particular case at least, a better error message would be with the substituted types - {{{ Inferred picker :: [Char] -> [Char] -> [Char] due to 7 | picker "x" "y" and also picker :: Num a => a -> a -> a due to 8 | picker 10 11 which conflict. Looks like picker doesn't have an explicit type signature - try providing one to fix the issue, or get a more informative error message. }}} Of course, the exact wording itself is not important, but now it is much clearer what the source of the problem is. I'm not sure what the appropriate level of generality is here (to give this kind of error message). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 07:50:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 07:50:00 -0000 Subject: [GHC] #15927: Weird interaction between fundeps and overlappable instances In-Reply-To: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> References: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> Message-ID: <063.867e13c8e1129564ac32467500062e11@haskell.org> #15927: Weird interaction between fundeps and overlappable instances -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 15632 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:2 Darwin226]: > I'm sorry if you addressed this in your comment and I'm just not getting it, but note that I'm not just declaring `f` with and unsatisfyable constraint. I'm also able to satisfy it! > Sorry if I was a bit oblique. I'm totally impressed that works. I would never have thought of trying it. > > So are you saying that this behavior can be relied on? Is my code likely to get broken in newer GHC versions? Good questions! I'll leave GHC HQ to answer definitively. Here's my take: This behaviour has been around since at least 2004: it's exploited in the HList paper, but the authors felt very uncomfortable about it. If you read #10675, SPJ describes GHC's behaviour as "bogus" and not supported by any of the academic theory around FunDeps -- including the 2006 paper of which he is a co-author. So yes your code might break in future releases, except ... There is a lot of code out there that exploits this loophole. (Usually with overlapping instances + FunDeps, but not exactly your ruse of putting contrary constraints on the same function.) So as my comments conclude on #10675, 'fixing' this will probably cause howls of outrage/break a fair amount of code. AFAICT nobody at GHC HQ is interested in anything around FunDeps/Overlaps, and hasn't been for a long time. So they will probably say: a) No, that behaviour can't be relied on. b) We're not going to 'fix' it, so you can get away with it for probably another decade. c) Use Closed Type Families instead of the FunDep, and make `MyState` a single parameter typeclass. I was going to try your code in my version of Haskell that (I think) takes a more principled approach. Just hang on a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 10:14:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 10:14:05 -0000 Subject: [GHC] #15844: Error fetching msys2 tarballs - crt-git In-Reply-To: <044.bfc9857a19082596b12202bbb22c13f4@haskell.org> References: <044.bfc9857a19082596b12202bbb22c13f4@haskell.org> Message-ID: <059.e3c0150ef919e22466bb11650a2401c0@haskell.org> #15844: Error fetching msys2 tarballs - crt-git -------------------------------------+------------------------------------- Reporter: Viwor | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (make) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Viwor): I don't think so, as if I remove the verify code: {{{ if test "$verify" = "1" then grep "${dest_file}$" mk/win32-tarballs.md5sum | md5sum --quiet -c - || fail "ERROR: ${description} appears to be corrupted, please delete it and try again." fi }}} Everything works just fine. I checked and the md5 it checks against is correct. Maybe it is a problem with get-win32-tarballs.sh -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 10:38:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 10:38:36 -0000 Subject: [GHC] #15933: Wrong size for int for callbacks into Haskell from foreign code Message-ID: <047.fc6e566f0d6e51e90623ea788d553629@haskell.org> #15933: Wrong size for int for callbacks into Haskell from foreign code -------------------------------------+------------------------------------- Reporter: iliastsi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 (FFI) | 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: -------------------------------------+------------------------------------- The following code produces different results on amd64 (64-bit little endian) and s390x (64-bit big endian). `foo.h:` {{{#!c typedef void(*hs_callback)(int x); extern void function_in_c(hs_callback cb); }}} `foo.c:` {{{#!c #include "foo.h" void function_in_c(hs_callback cb) { int x = 10; cb(x); } }}} `Foo.hs:` {{{#!hs module Main(main) where import Foreign import Foreign.C type HsCallback = CInt -> IO () foreign import ccall "foo.h function_in_c" functionInC :: FunPtr HsCallback -> IO () foreign import ccall "wrapper" wrap :: HsCallback -> IO (FunPtr HsCallback) main = do f <- wrap $ \x -> print x functionInC f freeHaskellFunPtr f }}} On amd64 the output is 10, but on s390x is 0. On both machines, `sizeOf (undefined :: CInt) == sizeof(int) == 4`. When changing `HsCallback` to: {{{#!hs type HsCallback = Int -> IO () }}} both produce the same, correct result, but the above seems wrong, as `sizeOf (undefined :: Int) == 8`. This has been reproduced with both ghc-8.4 and ghc-8.2, and causes dbus to fail to build on s390x (https://github.com/rblaze/haskell-dbus/issues/26), as it relies on libxml-sax which contains the above (simplified) code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 11:06:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 11:06:32 -0000 Subject: [GHC] #15934: Building ghc with dwarf information and profiling libraries fails on windows. Message-ID: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> #15934: Building ghc with dwarf information and profiling libraries fails on windows. ----------------------------------------+--------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Seems like we create too many sections in a single file on windows. {{{ C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801) C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Assembler messages: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't write 4 bytes to section .rdata$c1w2b_str of C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o because: 'File too big' C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801) C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't close C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: File too big `gcc.exe' failed in phase `Assembler'. (Exit code: 1) make[1]: *** [libraries/template-haskell/ghc.mk:4: libraries/template- haskell/dist-install/build/Language/Haskell/TH/Syntax.p_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:128: all] Error 2 }}} build.mk {{{ ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcLibHcOpts += -g1 GhcRtsHcOpts += -g1 # GhcStage2HcOpts += -g3 BUILD_PROF_LIBS=YES # Don't strip debug and other unneeded symbols from libraries and executables. STRIP_CMD = : HADDOCK_DOCS = NO BUILD_SPHINX_HTML = NO BUILD_SPHINX_PDF = NO BUILD_MAN = NO }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 11:10:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 11:10:46 -0000 Subject: [GHC] #15934: Building ghc with dwarf information and profiling libraries fails on windows. In-Reply-To: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> References: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> Message-ID: <062.d6464ddd1da981a738ed9781136f596d@haskell.org> #15934: Building ghc with dwarf information and profiling libraries fails on windows. ---------------------------------+---------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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 AndreasK): Not actively looking into this but there might be flags to make this work without big issues. See: * https://sourceware.org/ml/binutils/2014-03/msg00114.html * https://stackoverflow.com/questions/16596876/object-file-has-too-many- sections -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 11:27:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 11:27:38 -0000 Subject: [GHC] #15930: Add @since-annotations to the Foldable methods In-Reply-To: <046.1181e048db0e902f4cec12b70c302d38@haskell.org> References: <046.1181e048db0e902f4cec12b70c302d38@haskell.org> Message-ID: <061.778b017b2cfe9047607997057583b335@haskell.org> #15930: Add @since-annotations to the Foldable methods -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Core Libraries | Version: 8.6.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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomers Comment: Indeed. Based on my testing (i.e., [https://github.com/nfrisby/invariant- functors/blob/ed51d2f0343c060076672e41f588447a179babda/src/Data/Functor/Invariant.hs#L581-L594 here]), we need the following `@since` annotations: * Introduced in `base-4.6.0.0`: * `foldr'` * `foldl'` * Introduced in `base-4.8.0.0`: * `toList` * `null` * `length` * `elem` * `maximum` * `minimum` * `sum` * `product` Any volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 11:27:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 11:27:46 -0000 Subject: [GHC] #15927: Weird interaction between fundeps and overlappable instances In-Reply-To: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> References: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> Message-ID: <063.06f8bca286056d95639355eea74771a4@haskell.org> #15927: Weird interaction between fundeps and overlappable instances -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 15632 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): A more-principled FunDep consistency (see #15632) says: * The two instances for `MyState`are fine (but see below): - the FunDep is full; - the instance heads are in a strict substitution order; - on the more specific instance, its argument side `(StateT s m)` is strictly more specific -- i.e. than `(t m)`. However the signature for `f` gets rejected: * "Constraints are not consistent with Functional Dependencies" d'uh. If I comment out the signature, that type gets inferred anyway, and rejected for the same reason. Whereas in GHC, `works2` does indeed work and produce the expected output. (I needed to give it a signature to say it's in `IO`.) And using your `g` works, as you say, without a signature: {{{#!hs works3 = runStateT (runStateT g (7 :: Int)) 'b' }}} >> Instead of complaining that Int doesn't match Char (due to the fundep), it just rejects the instance and takes the overlappable one that does match. Yes your analysis is correct. And that's a folk-art way to subvert the FunDep. To prove your analysis, change the more-specific instance: {{{#!hs instance (Monad m, s ~ s') => MyState s' (StateT s m) where getMyState = get }}} By avoiding the repeated `s` in your original instance this says: * If the wanted `m` is of the form `(StateT s m)`, * then match anything for the `s'` (because it's a distinct bare variable), * and improve the `s'` to `s` from the `StateT`. We still get the definition of `f` accepted, but we can't use it: {{{#!hs * Couldn't match type `Int' with `Char' arising from a use of `f' * In the first argument of `runStateT', namely `f' In the first argument of `runStateT', namely `(runStateT f (5 :: Int))' In the expression: runStateT (runStateT f (5 :: Int)) 'a' }}} What that revised instance is doing, with the `~` constraint, is making explicit the 'official' semantics for improvement under a FunDep, as per the `FunDeps through CHRs` paper. That's also the semantics followed for a Closed Type Family. >> behavior ... seems pretty useful in some situations Yeah. Add the example to the "dysfunctional Functional Dependencies" #8634. Wise counsel would be not to rely on it/can you refactor your code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 12:58:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 12:58:27 -0000 Subject: [GHC] #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile In-Reply-To: <049.49521fa347356f7d5677b43e8c7f8d37@haskell.org> References: <049.49521fa347356f7d5677b43e8c7f8d37@haskell.org> Message-ID: <064.498fef0bb89166fdb0aa420d6b6e610f@haskell.org> #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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): I tried this out. The diff to add support was very simple. https://github.com/mpickering/ghc/commit/42c3df674e684fc33bcd472db8b55ace3d4385ca I then tried to compile the following program and to enable the XRay trace. {{{ module Main where main :: IO () main = print "abc" >> print (f 1000) >> print (g 1000) >> print (qux B) data T = A | B deriving Show f 0 = 1 f x = f (x -1) + 1 g 1 = 0 g x = g (x - 1) + f (x - 1) {-# NOINLINE qux #-} qux A = A qux B = qux A }}} The first thing to note was that it was necessary to use `clang-7.0.0` which I achieved by using this diff to `ghc.nix`. https://gist.github.com/mpickering/f1317ea6aac955eb9ecb1e2e1ef0fba7 Then I compiled with the following sequence of commands: {{{ inplace/bin/ghc-stage2 -fllvm -ddump-llvm llvm.hs -opta="-v" -pgma=clang -pgmc=clang -pgml=clang -optl="-fxray-instrument" -optl="-fxray- instruction-threshold=1" -O2 -fforce-recomp XRAY_OPTIONS="patch_premain=true xray_mode=xray-basic verbosity=1" ./llvm }}} Then the log file was analysed using the following command {{{ llvm-xray account -sort=sum -sortorder=dsc -instr_map ./llvm xray- log.llvm.XEyh0y }}} Which produced the very unhelpful profiling output. {{{ Functions with latencies: 7 funcid count [ min, med, 90p, 99p, max] sum function 7 18 [ 0.000006, 0.000006, 0.000021, 0.000040, 0.000040] 0.000175 :0:0: @(422fd0) 5 14 [ 0.000006, 0.000006, 0.000014, 0.000021, 0.000021] 0.000110 :0:0: @(422e90) 10 8 [ 0.000006, 0.000006, 0.000042, 0.000042, 0.000042] 0.000104 :0:0: @(4231a8) 8 10 [ 0.000006, 0.000006, 0.000040, 0.000040, 0.000040] 0.000096 :0:0: @(423070) 6 14 [ 0.000006, 0.000006, 0.000006, 0.000006, 0.000006] 0.000086 :0:0: @(422f30) 11 13 [ 0.000006, 0.000006, 0.000006, 0.000008, 0.000008] 0.000082 :0:0: @(423260) 9 7 [ 0.000006, 0.000006, 0.000014, 0.000014, 0.000014] 0.000055 :0:0: @(423110) }}} Should be easy now for someone else more familiar with LLVM to investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 13:02:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 13:02:34 -0000 Subject: [GHC] #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile In-Reply-To: <049.49521fa347356f7d5677b43e8c7f8d37@haskell.org> References: <049.49521fa347356f7d5677b43e8c7f8d37@haskell.org> Message-ID: <064.78e301f28ec1b7f80bfede61ab86da02@haskell.org> #15929: Explore whether adding XRay attributes to LLVM IR is worthwhile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 13:20:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 13:20:47 -0000 Subject: [GHC] #15935: TYPE is not generated by genprimops Message-ID: <045.2606d1b64e6a3965cd0d01fee77ae7f3@haskell.org> #15935: TYPE is not generated by genprimops -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.6.2 Libraries | Keywords: GHC.Magic | Operating System: Unknown/Multiple TYPE haddock GHC.Prim genprimops | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- During validation, GHC.Magic must build without warning, and must also type check with Haddock without warnings. This causes some awkwardness in GHC.Magic (see the comment above the imports regarding genprimops) because TYPE is exported from GHC.Prim and reexported by GHC.Types. We are forced to explicitly import it via GHC.Types (and not from GHC.Prim to avoid an unused import warnings). Importing via GHC.Prim would not type check with Haddock as genprimops doesn't generate TYPE for GHC.Prim. This issue surfaced in patch D5312. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 13:36:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 13:36:52 -0000 Subject: [GHC] #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 In-Reply-To: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> References: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> Message-ID: <060.88653292c5767387a14e4b677098e404@haskell.org> #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5348 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 16:50:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 16:50:47 -0000 Subject: [GHC] #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 In-Reply-To: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> References: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> Message-ID: <060.245929f5249e578eac8c5d5a37335332@haskell.org> #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5348 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 17:10:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 17:10:15 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.be456d2ed3b0a13a295e737786e04d74@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1241, #2247, | Differential Rev(s): Phab:D69 #8356, #9103, #9227 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by ByteEater): Is it possible to separate the parts requiring 7.6 behaviour and the newest Accelerate which requires at least 7.8 and compile them separately with different versions of GHC, then link? If so, would it be a viable solution for you, Wojciech (@danilo2)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 17:18:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 17:18:39 -0000 Subject: [GHC] #15925: Production quality bindists for hadrian In-Reply-To: <048.0f796c5db706ecf53494ae820b60c312@haskell.org> References: <048.0f796c5db706ecf53494ae820b60c312@haskell.org> Message-ID: <063.fa58faf58854ba1fa681d9ad54045212@haskell.org> #15925: Production quality bindists for hadrian -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | 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:D5371 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: new => patch * differential: => Phab:D5371 Comment: I have a patch at https://phabricator.haskell.org/D5371 We now systematically generate wrappers when doing `make install`, but the bindist is already usable as-is, with the `{bin, lib}` dirs from the unpacked archive (and even if you move them, as long as they sit next to each other). We also didn't ship `haddock` nor generated docs, too. The differential fixes this as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:42:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:42:41 -0000 Subject: [GHC] #15856: GhostScript not available for hp2ps tests In-Reply-To: <042.38af0a545c08ca985911b262b0de4318@haskell.org> References: <042.38af0a545c08ca985911b262b0de4318@haskell.org> Message-ID: <057.afbfe443bf9b30bbe3181a22a78aecc9@haskell.org> #15856: GhostScript not available for hp2ps tests -------------------------------------+------------------------------------- Reporter: jrp | Owner: monoidal Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: ghostscript | gs hp2ps testsuite Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T7919 T14761c Blocked By: | Blocking: Related Tickets: #15736 | Differential Rev(s): Phab:D5298 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"011e39d7fe533ca772beeed8529749c4750d4817/ghc" 011e39d7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="011e39d7fe533ca772beeed8529749c4750d4817" Fix GhostScript detection (Trac #15856) The option `confdir` (used in GhostScript test) was set correctly via `--config` in `test.mk` and incorrectly via `config/ghc`. AFAICT, some time ago this was working because the incorrect assignment was done first, and later it broke. Hardian doesn't pass `confdir`. I removed `confdir` and use `config.top` to determine the directory of the `good.ps` and `bad.ps` files. This is simpler. I also removed some redundant assignments in `config/ghc`. Test Plan: manually set config.have_profiling and make test Reviewers: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15856 Differential Revision: https://phabricator.haskell.org/D5298 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:42:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:42:56 -0000 Subject: [GHC] #15715: problematic openFile with named pipes In-Reply-To: <042.429251213bdecb6b7a1355c60029957a@haskell.org> References: <042.429251213bdecb6b7a1355c60029957a@haskell.org> Message-ID: <057.a20ec3d3985293957a059eeb848b86da@haskell.org> #15715: problematic openFile with named pipes -------------------------------------+------------------------------------- Reporter: adp | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect API | (amd64) annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5295 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4ba3fa31ddfa12b428bd67216a2d4118dc9e8311/ghc" 4ba3fa31/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4ba3fa31ddfa12b428bd67216a2d4118dc9e8311" base: Mention openFile throwing does-not-exist-errors on FIFOs As discussed in #15715, the POSIX specification specifies that attempting to open a FIFO in write-only mode when the FIFO has no readers will fail with -ENOENT. [skip ci] Test Plan: Read it Reviewers: hvr Subscribers: rwbarton, carter GHC Trac Issues: #15715 Differential Revision: https://phabricator.haskell.org/D5295 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:43:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:43:11 -0000 Subject: [GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation In-Reply-To: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> References: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> Message-ID: <062.5d07ab41f0a7b88951d0a7334c560b39@haskell.org> #15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13587, #15835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ea01517247c9667b0728daadc5f687ef8fcf945e/ghc" ea015172/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ea01517247c9667b0728daadc5f687ef8fcf945e" Add test for #15437 Reviewers: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15437 Differential Revision: https://phabricator.haskell.org/D5291 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:43:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:43:42 -0000 Subject: [GHC] #15669: T7040_ghci has a suspicious testcase failure In-Reply-To: <044.9d1f4438ef24291d12c76127056f4c24@haskell.org> References: <044.9d1f4438ef24291d12c76127056f4c24@haskell.org> Message-ID: <059.0775a24d65ff44871a0e5fe826c0a923@haskell.org> #15669: T7040_ghci has a suspicious testcase failure ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5364 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"06a09a5b5764717121be41d32f7b30f58ae33e08/ghc" 06a09a5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="06a09a5b5764717121be41d32f7b30f58ae33e08" rts: Fix bss initialization on Windows This patch fixes BSS initialization such that it is initialized to 0 as you'd expect. Test Plan: ./validate, test T7040_ghci Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15669 Differential Revision: https://phabricator.haskell.org/D5364 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:44:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:44:57 -0000 Subject: [GHC] #15922: Can't make a `binary-dist` on MacOS with Hadrian In-Reply-To: <050.1b314a27eae75b0a6acd46a801d11095@haskell.org> References: <050.1b314a27eae75b0a6acd46a801d11095@haskell.org> Message-ID: <065.eb09c61f52d74608cde8e0d4f4dd0723@haskell.org> #15922: Can't make a `binary-dist` on MacOS with Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5361 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"19ffddc1f479fcd5a0f265330cc1041366e8c43d/ghc" 19ffddc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="19ffddc1f479fcd5a0f265330cc1041366e8c43d" Hadrian: work around Cabal's/GHC's different Arch/OS strings The path to the 'include' subdirectory of 'rts' includes a folder that whose name is generated by Cabal and mentiones the architecture and OS. For example: _build/stage1/lib/x86_64-osx-ghc-8.7.20181120/rts-1.0/include Hadrian needs to be aware that Cabal renders architectures and OSes in a slightly different way than GHC. There is already symmetric logic in Cabal (for working with GHC environment files, which follow GHC's naming conventions). Test Plan: ./hadrian/build.sh -c "binary-dist" # on mac Reviewers: snowleopard, alpmestan, bgamari Reviewed By: snowleopard Subscribers: rwbarton, carter GHC Trac Issues: #15922 Differential Revision: https://phabricator.haskell.org/D5361 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:45:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:45:13 -0000 Subject: [GHC] #15671: Link errors due to forcibly exporting findPtr In-Reply-To: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> References: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> Message-ID: <059.b4ebd0115d7c791dca2c26e91747ef36@haskell.org> #15671: Link errors due to forcibly exporting findPtr -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: alpmestan Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10955dyn | T10955 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5138 Wiki Page: | Phab:D5356 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"561748cb507505bd5b7bd76bdc57796d896b62a2/ghc" 561748cb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="561748cb507505bd5b7bd76bdc57796d896b62a2" rts.cabal.in: force inclusion of findPtr/_findPtr symbol only with debug flag The previous strategy caused problems on Windows, as pointed out at [1] [1]: https://phabricator.haskell.org/rGHC900c47f88784#133905 Reviewers: Phyx, bgamari, erikd, simonmar Reviewed By: Phyx Subscribers: rwbarton, carter GHC Trac Issues: #15671 Differential Revision: https://phabricator.haskell.org/D5356 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:45:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:45:29 -0000 Subject: [GHC] #15216: plugins10 broken In-Reply-To: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> References: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> Message-ID: <061.80585c7bbf95ba9a21f94ab3fd3d4a79@haskell.org> #15216: plugins10 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5350 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1f74f7dd9ffec3540b9bd74225665dfa1519c46e/ghc" 1f74f7dd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f74f7dd9ffec3540b9bd74225665dfa1519c46e" plugins10 no longer broken Reviewers: bgamari, tdammers Reviewed By: tdammers Subscribers: rwbarton, carter GHC Trac Issues: #15216 Differential Revision: https://phabricator.haskell.org/D5350 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:45:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:45:59 -0000 Subject: [GHC] #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 In-Reply-To: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> References: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> Message-ID: <060.3686fb1408a5c041ac8e12c34267b60f@haskell.org> #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5348 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"599eaada382d04722219bfc319bde94591be3fb1/ghc" 599eaada/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="599eaada382d04722219bfc319bde94591be3fb1" Load plugins in interactive session Reviewers: bgamari, tdammers Reviewed By: tdammers Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #15633 Differential Revision: https://phabricator.haskell.org/D5348 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:46:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:46:16 -0000 Subject: [GHC] #15904: hp2ps fail with parse error when the command args contains double quotes In-Reply-To: <046.fc408ba87d45914eacede67a1118c1d0@haskell.org> References: <046.fc408ba87d45914eacede67a1118c1d0@haskell.org> Message-ID: <061.014ce38a04ad99ad265f6639c21d6b5a@haskell.org> #15904: hp2ps fail with parse error when the command args contains double quotes -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.7 Resolution: | Keywords: hp2ps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5346 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"390df8b51b917fb6409cbde8e73fe838d61d8832/ghc" 390df8b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="390df8b51b917fb6409cbde8e73fe838d61d8832" Fix uninformative hp2ps error when the cmdline contains double quotes The format of hp file didn't allow double quotes inside strings, and under prof build, we include args in JOB, which may have double quotes. When this happens, the error message is confusing to the user. This can also happen under normal build if the executable name contains double quite, which is unlikely though. We fix this issue by introducing escaping for double quotes inside a string by repeating it twice. We also fix a buffer overflow bug when the length of the string happen to be multiple of 5000. Test Plan: new tests, which used to fail with error message: ``` hp2ps: "T15904".hp, line 2: integer must follow identifier ``` use new ghc and hp2ps to profile a simple program. Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15904 Differential Revision: https://phabricator.haskell.org/D5346 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:46:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:46:48 -0000 Subject: [GHC] #15852: Bad axiom produced for polykinded data family In-Reply-To: <047.481c46c837c01249db862f276fa4c502@haskell.org> References: <047.481c46c837c01249db862f276fa4c502@haskell.org> Message-ID: <062.75694920b5d353e13ed75036be374838@haskell.org> #15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5328 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"014d6c1f08808c4dab6cba80efdc634527d91086/ghc" 014d6c1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="014d6c1f08808c4dab6cba80efdc634527d91086" Fix #15852 by eta expanding data family instance RHSes, too When I defined `etaExpandFamInstLHS`, I blatantly forgot to eta expand the RHSes of data family instances. (Actually, I claimed that they didn't //need// to be eta expanded. I'm not sure what I was thinking.) This fixes the issue by changing `etaExpandFamInstLHS` to `etaExpandFamInst` and, well, making it actually eta expand the RHS. Test Plan: make test TEST=T15852 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15852 Differential Revision: https://phabricator.haskell.org/D5328 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:47:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:47:04 -0000 Subject: [GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags In-Reply-To: <042.e68200604de67ef001a98aff36406689@haskell.org> References: <042.e68200604de67ef001a98aff36406689@haskell.org> Message-ID: <057.a9d4c65c97ace44883c362a8f062ab44@haskell.org> #14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5318 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f2d9fb0c288788abeb796a13d600295a526290cd/ghc" f2d9fb0c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f2d9fb0c288788abeb796a13d600295a526290cd" Calling gcc: Pass optc flags as last options (#14452) Test Plan: make test TEST=T14452 Reviewers: hvr, bgamari, monoidal, thomie, osa1 Reviewed By: osa1 Subscribers: rwbarton, carter GHC Trac Issues: #14452 Differential Revision: https://phabricator.haskell.org/D5318 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:47:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:47:52 -0000 Subject: [GHC] #15871: Revamp -fprint-explicit-kinds In-Reply-To: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> References: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> Message-ID: <062.cd4307f464c8fdded4c532d62f5de2f1@haskell.org> #15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5314 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f5d2083807a03c57f194fcc3a7baf82e34aad524/ghc" f5d2083/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f5d2083807a03c57f194fcc3a7baf82e34aad524" Overhaul -fprint-explicit-kinds to use VKA This patch changes the behavior of `-fprint-explicit-kinds` so that it displays kind argument using visible kind application. In other words, the flag now: 1. Prints instantiations of specified variables with `@(...)`. 2. Prints instantiations of inferred variables with `@{...}`. In addition, this patch removes the `Use -fprint-explicit-kinds to see the kind arguments` error message that often arises when a type mismatch occurs due to different kinds. Instead, whenever there is a kind mismatch, we now enable the `-fprint-explicit-kinds` flag locally to help cue to the programmer where the error lies. (See `Note [Kind arguments in error messages]` in `TcErrors`.) As a result, these funny `@{...}` things can now appear to the user even without turning on the `-fprint-explicit-kinds` flag explicitly, so I took the liberty of documenting them in the users' guide. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15871 Differential Revision: https://phabricator.haskell.org/D5314 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:48:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:48:09 -0000 Subject: [GHC] #15853: Unregisterised GHC panics when building test cgrun018 In-Reply-To: <047.a568cb0e736c463bce20c7d17a5e90c5@haskell.org> References: <047.a568cb0e736c463bce20c7d17a5e90c5@haskell.org> Message-ID: <062.21640b41380d55da91d5abcd5c61d25d@haskell.org> #15853: Unregisterised GHC panics when building test cgrun018 -------------------------------------+------------------------------------- Reporter: iliastsi | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: cgrun018 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"35a897782b6b0a252da7fdcf4921198ad4e1d96c/ghc" 35a8977/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="35a897782b6b0a252da7fdcf4921198ad4e1d96c" UNREG: PprC: Add support for adjacent floats When two 32-bit floats are adjacent for a 64-bit target, there is no padding between them to force alignment, so we must combine their bit representations into a single word. Reviewers: bgamari, simonmar Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15853 Differential Revision: https://phabricator.haskell.org/D5306 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:53:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:53:55 -0000 Subject: [GHC] #15936: Rethink Choice of Baseline Commit for Performance Tests Message-ID: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> #15936: Rethink Choice of Baseline Commit for Performance Tests -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Keywords: performance | Operating System: Unknown/Multiple tests git notes | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- = Intro = Currently we always use the previous commit when running performance tests. This works well in CI where we fully test each commit in sequence (and hence always have test results for the previous commit). Remember, test results are stored in git notes and are not by default shared between repositories (i.e. your local repo will only have performance results run locally on your machine). This is by design: we want to avoid comparing results form different machines. Unfortunately This is not so effective when testing locally. The programmer may have only run a subset of performance tests on the previous commit, and often have not run the tests at all (this is notably true after performing a rebase: the previous commit has changed). We need to rethink how we pick a baseline commit. = Goals = * In all cases, do something sensible. * Giving a warning if conditions are not idea. Provide clear and simple instructions on how to get to the ideal case. * Give control over the baseline commit to the programmer via command line options. * In general, performance tests should just work! No extra knowledge needed by the programmer. * If tests pass without warning now, then they should pass without warning later. = Proposed Solution = * Choose baseline commit * Provide command line arguments to set the baseline commit * If not baseline commit is provided use the "Ideal baseline commit". * If local test results for the baseline are available use those results. * Else if results from CI are available (without fetching), then use those results. * Else Warn user that there are no results available (tests trivially pass), then suggest fetching CI results (quick and easy, give full command, mention you may have to wait for CI to finish if the commit is recent) or running locally (more accurate, mention exact commit to checkout), or manually select a baseline commit. == Ideal baseline commit == * If there are no new changes: 0 ahead and 0 or more behind master. * Ideal baseline commit is the previous commit. * Else 1 or more ahead and 0 or more behind master. * Ideal baseline commit is `merge-base master HEAD` * Assume that the intention is to create a patch where all new commits will ultimately be squashed and placed on top of master. We only want to consider performance changes caused by the new commits, so we use the merge base instead of master HEAD (though these may be the same commit). = Open issues = If commits between HEAD and the baseline commit [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests#ExpectedPerformanceChanges allow changes] in performance numbers, what should the behaviour be? What happens if this is merged? The commits will be squashed: this could affect the commit message and hence the allowed changes which is parsed from the commit messages. = Use cases = TODO This section is a WIP We generally will assume that the master branch corresponds to ghc's master branch (though may be slightly out of date). ||= Case =||= Details =||= Baseline =|| || 0 commits ahead of master || May be on master or branched off master with no new commits || previous commit || || CI pre-merge || || CI post-merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:54:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:54:13 -0000 Subject: [GHC] #15936: Rethink Choice of Baseline Commit for Performance Tests In-Reply-To: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> References: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> Message-ID: <060.50921671f687906c552617b3896d9826@haskell.org> #15936: Rethink Choice of Baseline Commit for Performance Tests -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git 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: | -------------------------------------+------------------------------------- Changes (by davide): * owner: (none) => davide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:58:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:58:15 -0000 Subject: [GHC] #15856: GhostScript not available for hp2ps tests In-Reply-To: <042.38af0a545c08ca985911b262b0de4318@haskell.org> References: <042.38af0a545c08ca985911b262b0de4318@haskell.org> Message-ID: <057.9abd48330bd335cd029eef284a04ed1d@haskell.org> #15856: GhostScript not available for hp2ps tests -------------------------------------+------------------------------------- Reporter: jrp | Owner: monoidal Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.6.1 Resolution: fixed | Keywords: ghostscript | gs hp2ps testsuite Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: T7919 T14761c Blocked By: | Blocking: Related Tickets: #15736 | Differential Rev(s): Phab:D5298 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:58:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:58:26 -0000 Subject: [GHC] #15715: problematic openFile with named pipes In-Reply-To: <042.429251213bdecb6b7a1355c60029957a@haskell.org> References: <042.429251213bdecb6b7a1355c60029957a@haskell.org> Message-ID: <057.1fa7fb5208d3927a1e8c8173848254d9@haskell.org> #15715: problematic openFile with named pipes -------------------------------------+------------------------------------- Reporter: adp | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect API | (amd64) annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5295 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:58:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:58:50 -0000 Subject: [GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation In-Reply-To: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> References: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> Message-ID: <062.a0fc7f11e5e053f82d413b358a0dba6f@haskell.org> #15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T15437 Blocked By: | Blocking: Related Tickets: #13587, #15835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => T15437 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:59:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:59:10 -0000 Subject: [GHC] #15669: T7040_ghci has a suspicious testcase failure In-Reply-To: <044.9d1f4438ef24291d12c76127056f4c24@haskell.org> References: <044.9d1f4438ef24291d12c76127056f4c24@haskell.org> Message-ID: <059.18f1fcf03cac420c4b5ebc29f549103e@haskell.org> #15669: T7040_ghci has a suspicious testcase failure ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.3 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5364 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: 8.6.1 => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:59:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:59:24 -0000 Subject: [GHC] #15922: Can't make a `binary-dist` on MacOS with Hadrian In-Reply-To: <050.1b314a27eae75b0a6acd46a801d11095@haskell.org> References: <050.1b314a27eae75b0a6acd46a801d11095@haskell.org> Message-ID: <065.7fcf96f56deb972e89ad9c76e27e835d@haskell.org> #15922: Can't make a `binary-dist` on MacOS with Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5361 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:59:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:59:38 -0000 Subject: [GHC] #15671: Link errors due to forcibly exporting findPtr In-Reply-To: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> References: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> Message-ID: <059.dc73c2d99fa15403e9f09baf1cd1ddf3@haskell.org> #15671: Link errors due to forcibly exporting findPtr -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: alpmestan Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10955dyn | T10955 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5138 Wiki Page: | Phab:D5356 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:59:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:59:48 -0000 Subject: [GHC] #15922: Can't make a `binary-dist` on MacOS with Hadrian In-Reply-To: <050.1b314a27eae75b0a6acd46a801d11095@haskell.org> References: <050.1b314a27eae75b0a6acd46a801d11095@haskell.org> Message-ID: <065.e6520991396759c5d83d713d8b0c3d6f@haskell.org> #15922: Can't make a `binary-dist` on MacOS with Hadrian -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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:D5361 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.3 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 18:59:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 18:59:59 -0000 Subject: [GHC] #15216: plugins10 broken In-Reply-To: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> References: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> Message-ID: <061.e9b514d55f2e95f5a669a96a7d09d24e@haskell.org> #15216: plugins10 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5350 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 19:00:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 19:00:10 -0000 Subject: [GHC] #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 In-Reply-To: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> References: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> Message-ID: <060.726eb331d7ab0507b9d6c415349c26c8@haskell.org> #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5348 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 19:00:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 19:00:30 -0000 Subject: [GHC] #15904: hp2ps fail with parse error when the command args contains double quotes In-Reply-To: <046.fc408ba87d45914eacede67a1118c1d0@haskell.org> References: <046.fc408ba87d45914eacede67a1118c1d0@haskell.org> Message-ID: <061.8e7644c790ff38a2c9f8d636c4dfbbf8@haskell.org> #15904: hp2ps fail with parse error when the command args contains double quotes -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.7 Resolution: fixed | Keywords: hp2ps Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5346 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 19:00:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 19:00:45 -0000 Subject: [GHC] #15852: Bad axiom produced for polykinded data family In-Reply-To: <047.481c46c837c01249db862f276fa4c502@haskell.org> References: <047.481c46c837c01249db862f276fa4c502@haskell.org> Message-ID: <062.c799b56d18b2dca6ce520fba52c9b5ce@haskell.org> #15852: Bad axiom produced for polykinded data family -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5328 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 19:00:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 19:00:54 -0000 Subject: [GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags In-Reply-To: <042.e68200604de67ef001a98aff36406689@haskell.org> References: <042.e68200604de67ef001a98aff36406689@haskell.org> Message-ID: <057.4a2ad713167315218095411c12b510ce@haskell.org> #14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5318 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 19:01:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 19:01:01 -0000 Subject: [GHC] #15871: Revamp -fprint-explicit-kinds In-Reply-To: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> References: <047.d2b666053e194a09fe2c43e7a7628a54@haskell.org> Message-ID: <062.272a6e39444fee544286ee0aa18d99ca@haskell.org> #15871: Revamp -fprint-explicit-kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5314 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 19:01:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 19:01:12 -0000 Subject: [GHC] #15853: Unregisterised GHC panics when building test cgrun018 In-Reply-To: <047.a568cb0e736c463bce20c7d17a5e90c5@haskell.org> References: <047.a568cb0e736c463bce20c7d17a5e90c5@haskell.org> Message-ID: <062.9e8b5d29f3678f38457c4d5d23b01217@haskell.org> #15853: Unregisterised GHC panics when building test cgrun018 -------------------------------------+------------------------------------- Reporter: iliastsi | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: cgrun018 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 19:06:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 19:06:05 -0000 Subject: [GHC] #15669: T7040_ghci has a suspicious testcase failure In-Reply-To: <044.9d1f4438ef24291d12c76127056f4c24@haskell.org> References: <044.9d1f4438ef24291d12c76127056f4c24@haskell.org> Message-ID: <059.06712d5ae02459e49a2e86d3f318a026@haskell.org> #15669: T7040_ghci has a suspicious testcase failure ---------------------------------+---------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5364 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.6.3 => 8.8.1 Comment: I believe this regression was introduced in 5840734379da5d494a368d0b8a6edf1b1216a7f4, which isn't present in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 19:46:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 19:46:07 -0000 Subject: [GHC] #15937: CI strategy for Gitlab Message-ID: <048.738065983349c6ff7ad5141b89ce5589@haskell.org> #15937: CI strategy for Gitlab -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: Integration | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have been working on the configuration of the staging gitlab instance recently. We managed to hook it up with both Circle CI and Appveyor, for the `ghc/ghc` (''username/repo'') project on our instance. It all works. Things get tricky when it comes to running CI jobs for forks, though. Indeed, our Circle CI script relies on some CI env vars being defined in the CI settings of the project. Those are "secrets" (e.g circle ci API token) that we do not want to make public and encourage everyone to use, which means that CI simply won't work for forks, out of the box, with things as they stand. Ben and I have discussed this a bit and we see 3 different ways to go about this. 1) Forget about the fork-based workflow. We might consider having a reference repo where things get merged and a "sandbox" repo where people could push their branches and get some CI running. They could then create MRs against the "real" repo to get patches merged. This one way or another requires adding new contributors manually to the "sandbox repo". It is quite likely that they could also get "our secrets" by simply tweaking `.gitlab-ci.yml` to print the right env vars, in their branch. 2) We go for a "full gitlab CI" solution, which might require less work than it initially seems as it could use the same docker images and run roughly the same commands as Circle CI. That requires computational resources though, and makes the transition less smooth. We can certainly consider doing some ''additional'' CI with this, if we make the move definitive and end up refining our CI needs, but we definitely don't want to get rid of Circle CI/Appveyor now anyway. 3) We implement a "mediator" service that would have all our secrets and would get hit by gitlab CI jobs to launch builds and report the results & artifacts. It could therefore behave the same regardless of the user/repo/branch that triggers it without exposing anything. This could be put together somewhat quickly but requires enough work that we may not be able to set that up in time for the initial move. It is however the best solution from the user experience (ghc contributor) point of view. People with developer access to the main repo could push there, or in their forks. Others would only push to their forks and create MRs. CI would work the same in all those cases. In my opinion, going with 1) initially and then 3) as soon as possible is the best plan in the long term. It would make for a great contributor experience while requiring very little maintenance. This could also very easily live side by side with some "real" gitlab CI, that doesn't offload the work to an external service. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 20:41:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 20:41:55 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow Message-ID: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single build. This is orders of magnitude worse than `make` so something must be wrong. I'm setting this at high priority since 45 seconds is longer than many complete `make` rebuilds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 20:44:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 20:44:59 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.ee7ad8e88552e100ccad60f7adb324d5@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: 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: alpmestan, snowleopard (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 20:45:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 20:45:55 -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.9e65ac548eba73adccfc02ea0582a74e@haskell.org> #14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: hvr Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Runtime System | 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:D5244 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.6.3 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 20:54:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 20:54:47 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.805ad979989303b823fc4ef0ed4e1f5c@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It gets faster for subsequent rebuilds. I think it got down to about 10s on my machine after running it 3-4 times. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:02:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:02:56 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.984e88aa682b97cc919258081884b7c0@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: None | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"3584bd4255eb59be043252c9b4ef16bcbd835c9b/ghc" 3584bd4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3584bd4255eb59be043252c9b4ef16bcbd835c9b" circleci: Actually build with in-tree GMP on Darwin Fixes #15404. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:05:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:05:33 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.e7685496b518f4b32a7155a25384d58e@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.3 Component: GHC API | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"254890855ee04762cc0392da19e0c42fc039a718/ghc" 25489085/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="254890855ee04762cc0392da19e0c42fc039a718" rts/MachO: Iterate through N (all) symbols, not M external symbols Fixes #15105 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:07:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:07:35 -0000 Subject: [GHC] #11301: Using GHC's parser and rendering the results is unreasonably difficult In-Reply-To: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> References: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> Message-ID: <063.dafb2c21378b56b9fc0d41f7efaa1b52@haskell.org> #11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5aa29231ab7603537284eff5e4caff3a73dba6d2/ghc" 5aa29231/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5aa29231ab7603537284eff5e4caff3a73dba6d2" 'DynFlag'-free version of 'mkParserFlags' Obtaining a `DynFlags` is difficult, making using the lexer/parser for pure parsing/lexing unreasonably difficult, even with `mkPStatePure`. This is despite the fact that we only really need * language extension flags * warning flags * a handful of boolean options The new `mkParserFlags'` function makes is easier to directly construct a `ParserFlags`. Furthermore, since `pExtsBitmap` is just a footgun, I've gone ahead and made `ParserFlags` an abstract type. Reviewers: bgamari, alanz, sjakobi Reviewed By: bgamari, sjakobi Subscribers: mpickering, sjakobi, rwbarton, carter GHC Trac Issues: #11301 Differential Revision: https://phabricator.haskell.org/D5269 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:09:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:09:23 -0000 Subject: [GHC] #15319: Configurable/overridable settings file In-Reply-To: <044.ba7ad8d95aa9a6958eb5b0890b79f3ba@haskell.org> References: <044.ba7ad8d95aa9a6958eb5b0890b79f3ba@haskell.org> Message-ID: <059.678a2c104c2d7c8d339063bb8f9fbecc@haskell.org> #15319: Configurable/overridable settings file -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5317 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8d008b71db53f7a59673f894f329b8d71f84c8ee/ghc" 8d008b71/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d008b71db53f7a59673f894f329b8d71f84c8ee" Don't pass -no-pie when -pgmc is supplied Test Plan: validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15319 Differential Revision: https://phabricator.haskell.org/D5317 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:10:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:10:37 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.c8d05a3f380108a73cc9840ee32fee14@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Phab:D5312 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6353efc7694ba8ec86c091918e02595662169ae2/ghc" 6353efc7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6353efc7694ba8ec86c091918e02595662169ae2" Fix unused-import warnings This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely commit 9376249b6b78610db055a10d05f6592d6bbbea2f Author: Simon Peyton Jones Date: Wed Oct 28 17:16:55 2015 +0000 Fix unused-import stuff in a better way In that patch got the sense of the comparison back to front, and thereby failed to implement the unused-import rules described in Note [Choosing the best import declaration] in RdrName This led to Trac #13064 and #15393 Fixing this bug revealed a bunch of unused imports in libraries; the ones in the GHC repo are part of this commit. The two important changes are * Fix the bug in bestImport * Modified the rules by adding (a) in Note [Choosing the best import declaration] in RdrName Reason: the previosu rules made Trac #5211 go bad again. And the new rule (a) makes sense to me. In unravalling this I also ended up doing a few other things * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the things that are used, rather than [AvailInfo]. This is simpler and more direct. * Rename greParentName to greParent_maybe, to follow GHC naming conventions * Delete dead code RdrName.greUsedRdrName Bumps a few submodules. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27 Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5312 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:10:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:10:37 -0000 Subject: [GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) In-Reply-To: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> References: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> Message-ID: <065.6efb573442c3bbc98061892547f60768@haskell.org> #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6353efc7694ba8ec86c091918e02595662169ae2/ghc" 6353efc7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6353efc7694ba8ec86c091918e02595662169ae2" Fix unused-import warnings This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely commit 9376249b6b78610db055a10d05f6592d6bbbea2f Author: Simon Peyton Jones Date: Wed Oct 28 17:16:55 2015 +0000 Fix unused-import stuff in a better way In that patch got the sense of the comparison back to front, and thereby failed to implement the unused-import rules described in Note [Choosing the best import declaration] in RdrName This led to Trac #13064 and #15393 Fixing this bug revealed a bunch of unused imports in libraries; the ones in the GHC repo are part of this commit. The two important changes are * Fix the bug in bestImport * Modified the rules by adding (a) in Note [Choosing the best import declaration] in RdrName Reason: the previosu rules made Trac #5211 go bad again. And the new rule (a) makes sense to me. In unravalling this I also ended up doing a few other things * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the things that are used, rather than [AvailInfo]. This is simpler and more direct. * Rename greParentName to greParent_maybe, to follow GHC naming conventions * Delete dead code RdrName.greUsedRdrName Bumps a few submodules. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27 Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5312 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:10:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:10:37 -0000 Subject: [GHC] #5211: Missing warning about redundant import for a class instance In-Reply-To: <046.ff68d8ccd44f2e25288f60c7cde8581a@haskell.org> References: <046.ff68d8ccd44f2e25288f60c7cde8581a@haskell.org> Message-ID: <061.3d7f1cd0b3266872bea466f3b1fae7b0@haskell.org> #5211: Missing warning about redundant import for a class instance ---------------------------------+----------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Type of failure: None/Unknown | Test Case: rename/should_fail/T5211 Blocked By: | Blocking: ---------------------------------+----------------------------------------- Comment (by Ben Gamari ): In [changeset:"6353efc7694ba8ec86c091918e02595662169ae2/ghc" 6353efc7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6353efc7694ba8ec86c091918e02595662169ae2" Fix unused-import warnings This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely commit 9376249b6b78610db055a10d05f6592d6bbbea2f Author: Simon Peyton Jones Date: Wed Oct 28 17:16:55 2015 +0000 Fix unused-import stuff in a better way In that patch got the sense of the comparison back to front, and thereby failed to implement the unused-import rules described in Note [Choosing the best import declaration] in RdrName This led to Trac #13064 and #15393 Fixing this bug revealed a bunch of unused imports in libraries; the ones in the GHC repo are part of this commit. The two important changes are * Fix the bug in bestImport * Modified the rules by adding (a) in Note [Choosing the best import declaration] in RdrName Reason: the previosu rules made Trac #5211 go bad again. And the new rule (a) makes sense to me. In unravalling this I also ended up doing a few other things * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the things that are used, rather than [AvailInfo]. This is simpler and more direct. * Rename greParentName to greParent_maybe, to follow GHC naming conventions * Delete dead code RdrName.greUsedRdrName Bumps a few submodules. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27 Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5312 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:21:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:21:50 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.a1966728b2decbb03e3081d24a48250e@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: 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 snowleopard): * cc: NeilMitchell (added) Comment: Thank for reporting. 45 seconds of doing nothing sounds strange, I'm not sure how/why this happened. Is this something you can reliably reproduce by `Ctrl-C`'ing the full build in the middle of building `libraries/base`? Zero build currently takes around 7 seconds on my machine. Neil was optimistic that we'll be able to substantially improve this, so I'm tagging him too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:23:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:23:10 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.07c16d23c8d5f483ac1199d26d779763@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): And today's results are: {{{ ==== STAGE 1 TESTS ==== SUMMARY for test run started at Thu Nov 22 21:13:10 2018 GMT 0:00:04 spent to go through 2 total tests, which gave rise to 10 test cases, of which 0 were skipped 0 had missing libraries 10 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures ==== STAGE 2 TESTS ==== Unexpected results from: TEST="ArithInt16 ArithWord16 T14761c T15904 T2783 T3816 T7919 heapprof001 hpc_fork recomp007 user001" SUMMARY for test run started at Thu Nov 22 20:03:42 2018 GMT 1:09:26 spent to go through 6684 total tests, which gave rise to 30075 test cases, of which 5872 were skipped 260 had missing libraries 23650 expected passes 260 expected failures 0 caused framework failures 0 caused framework warnings 1 unexpected passes 32 unexpected failures 0 unexpected stat failures Unexpected passes: /tmp/ghctest-b9xr3p89/test spaces/rts/T2783.run T2783 [unexpected] (threaded1) Unexpected failures: /tmp/ghctest-b9xr3p89/test spaces/driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) /tmp/ghctest-b9xr3p89/test spaces/hp2ps/T15904.run T15904 [bad stdout] (normal) /tmp/ghctest-b9xr3p89/test spaces/primops/should_run/ArithInt16.run ArithInt16 [bad stderr] (ghci) /tmp/ghctest-b9xr3p89/test spaces/primops/should_run/ArithWord16.run ArithWord16 [bad stderr] (ghci) /tmp/ghctest-b9xr3p89/test spaces/primops/should_run/ArithWord16.run ArithWord16 [exit code non-0] (optllvm) /tmp/ghctest-b9xr3p89/test spaces/primops/should_run/ArithInt16.run ArithInt16 [exit code non-0] (optllvm) /tmp/ghctest-b9xr3p89/test spaces/profiling/should_run/heapprof001.run heapprof001 [bad exit code] (prof_hc_hb) /tmp/ghctest-b9xr3p89/test spaces/rts/T7919.run T7919 [bad exit code] (ghci) /tmp/ghctest-b9xr3p89/test spaces/typecheck/should_compile/T14761c.run T14761c [exit code non-0] (hpc) /tmp/ghctest-b9xr3p89/test spaces/typecheck/should_compile/T14761c.run T14761c [exit code non-0] (optasm) /tmp/ghctest-b9xr3p89/test spaces/typecheck/should_compile/T14761c.run T14761c [exit code non-0] (profasm) /tmp/ghctest-b9xr3p89/test spaces/typecheck/should_compile/T14761c.run T14761c [exit code non-0] (optllvm) /tmp/ghctest-b9xr3p89/test spaces/libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (normal) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (hpc) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (optasm) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (profasm) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (threaded1) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (threaded2) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (dyn) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (profthreaded) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (optllvm) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (normal) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (hpc) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (optasm) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (profasm) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (ghci) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (threaded1) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (threaded2) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (dyn) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (profthreaded) /tmp/ghctest-b9xr3p89/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (optllvm) == Start post-testsuite package check GHC package manager version 8.7.20181122 Timestamp 2018-11-22 20:03:38.351791792 UTC for /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181122/package.conf.d/package.cache using cache: /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181122/package.conf.d/package.cache db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181122/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181122/package.conf.d"] flag db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181122/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181122/package.conf.d"] == End post-testsuite package check ------------------------------------------------------------------- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. ------------------------------------------------------------------- }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:32:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:32:13 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.6b8d25c4829b9269daed28a659dfa705@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): ... and just running {{{make test TEST=...}}} {{{ =====> recomp007(normal) 1 of 11 [0, 0, 0] cd "driver/recomp007/recomp007.run" && $MAKE -s --no-print-directory recomp007 Actual stderr output differs from expected: diff -uw "/dev/null" "driver/recomp007/recomp007.run/recomp007.run.stderr.normalised" --- /dev/null 2018-11-22 18:53:00.700826500 +0000 +++ driver/recomp007/recomp007.run/recomp007.run.stderr.normalised 2018-11-22 21:24:45.101279549 +0000 @@ -0,0 +1,122 @@ +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.Parsec.Common, 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.Flag, + 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.Parsec.Common, 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.Flag, + 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 recomp007(normal) =====> T15904(normal) 2 of 11 [0, 1, 0] cd "hp2ps/T15904.run" && $MAKE -s --no-print-directory T15904 Actual stdout output differs from expected: diff -uw "hp2ps/T15904.run/T15904.stdout.normalised" "hp2ps/T15904.run/T15904.run.stdout.normalised" --- hp2ps/T15904.run/T15904.stdout.normalised 2018-11-22 21:24:46.193284051 +0000 +++ hp2ps/T15904.run/T15904.run.stdout.normalised 2018-11-22 21:24:46.193284051 +0000 @@ -1,6 +1,5 @@ [1 of 1] Compiling T15904 ( T15904.hs, T15904.o ) Linking "T15904" ... {"e": 2.72, "pi": 3.14} - - +$\n \ *** unexpected failure for T15904(normal) =====> ArithInt16(normal) 3 of 11 [0, 2, 0] cd "primops/should_run/ArithInt16.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o ArithInt16 ArithInt16.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "primops/should_run/ArithInt16.run" && ./ArithInt16 =====> ArithWord16(normal) 4 of 11 [0, 2, 0] cd "primops/should_run/ArithWord16.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o ArithWord16 ArithWord16.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "primops/should_run/ArithWord16.run" && ./ArithWord16 =====> heapprof001(profasm) 5 of 11 [0, 2, 0] cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o heapprof001 heapprof001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O -prof -static -fprof-auto cd "profiling/should_run/heapprof001.run" && ./heapprof001 +RTS -hc -p -RTS 7 cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/hp2ps" heapprof001 "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE "profiling/should_run/heapprof001.run/heapprof001.ps" =====> heapprof001(prof) 5 of 11 [0, 2, 0] cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o heapprof001 heapprof001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -prof -static -fprof-auto -fasm cd "profiling/should_run/heapprof001.run" && ./heapprof001 +RTS -p -RTS 7 =====> heapprof001(prof_hc_hb) 5 of 11 [0, 2, 0] cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o heapprof001 heapprof001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O -prof -static -fprof-auto cd "profiling/should_run/heapprof001.run" && ./heapprof001 +RTS -hc -hbvoid -RTS 7 cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/hp2ps" heapprof001 "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE "profiling/should_run/heapprof001.run/heapprof001.ps" =====> heapprof001(prof_hb) 5 of 11 [0, 2, 0] cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o heapprof001 heapprof001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O -prof -static -fprof-auto cd "profiling/should_run/heapprof001.run" && ./heapprof001 +RTS -hb -RTS 7 cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/hp2ps" heapprof001 "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE "profiling/should_run/heapprof001.run/heapprof001.ps" =====> heapprof001(prof_hd) 5 of 11 [0, 2, 0] cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o heapprof001 heapprof001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O -prof -static -fprof-auto cd "profiling/should_run/heapprof001.run" && ./heapprof001 +RTS -hd -RTS 7 cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/hp2ps" heapprof001 "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE "profiling/should_run/heapprof001.run/heapprof001.ps" =====> heapprof001(prof_hy) 5 of 11 [0, 2, 0] cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o heapprof001 heapprof001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O -prof -static -fprof-auto cd "profiling/should_run/heapprof001.run" && ./heapprof001 +RTS -hy -RTS 7 cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/hp2ps" heapprof001 "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE "profiling/should_run/heapprof001.run/heapprof001.ps" =====> heapprof001(prof_hr) 5 of 11 [0, 2, 0] cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o heapprof001 heapprof001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -O -prof -static -fprof-auto cd "profiling/should_run/heapprof001.run" && ./heapprof001 +RTS -hr -RTS 7 cd "profiling/should_run/heapprof001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/hp2ps" heapprof001 "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE "profiling/should_run/heapprof001.run/heapprof001.ps" =====> T2783(normal) 6 of 11 [0, 2, 0] cd "rts/T2783.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc- stage2" -o T2783 T2783.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output cd "rts/T2783.run" && ./T2783 =====> T7919(normal) 7 of 11 [0, 2, 0] cd "rts/T7919.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc- stage2" -o T7919 T7919.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output -dynamic cd "rts/T7919.run" && ./T7919 =====> T14761c(normal) 8 of 11 [0, 2, 0] cd "typecheck/should_compile/T14761c.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -c T14761c.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -Werror=compat -dno-debug-output -fno-warn- incomplete-patterns =====> hpc_fork(normal) 9 of 11 [0, 2, 0] cd "libraries/hpc/tests/fork/hpc_fork.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o hpc_fork hpc_fork.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -fhpc cd "libraries/hpc/tests/fork/hpc_fork.run" && perl hpcrun.pl --clear --exeext= --hpc="/home/jrp/Projects/ghc/inplace/test spaces/hpc" ./hpc_fork =====> user001(normal) 10 of 11 [0, 2, 0] cd "libraries/unix/tests/user001.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o user001 user001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -package unix cd "libraries/unix/tests/user001.run" && ./user001 Actual stdout output differs from expected: diff -uw "libraries/unix/tests/user001.run/user001.stdout.normalised" "libraries/unix/tests/user001.run/user001.run.stdout.normalised" --- libraries/unix/tests/user001.run/user001.stdout.normalised 2018-11-22 21:25:17.853414712 +0000 +++ libraries/unix/tests/user001.run/user001.run.stdout.normalised 2018-11-22 21:25:17.853414712 +0000 @@ -6,6 +6,6 @@ getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK -getAllGroupEntries: OK +getAllGroupEntries: ERROR: getAllGroupEntries: does not exist (No such file or directory) getUserEntryForID: OK -getAllUserEntries: OK +getAllUserEntries: ERROR: getAllUserEntries: does not exist (No such file or directory) *** unexpected failure for user001(normal) =====> T3816(normal) 11 of 11 [0, 3, 0] cd "libraries/unix/tests/T3816.run" && "/home/jrp/Projects/ghc/inplace/test spaces/ghc-stage2" -o T3816 T3816.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -package unix cd "libraries/unix/tests/T3816.run" && ./T3816 Wrong exit code for T3816(normal)(expected 0 , actual 1 ) Stderr ( T3816 ): T3816: getAllGroupEntries: does not exist (No such file or directory) *** unexpected failure for T3816(normal) Unexpected results from: TEST="T15904 T3816 recomp007 user001" SUMMARY for test run started at Thu Nov 22 21:24:33 2018 GMT 0:00:46 spent to go through 11 total tests, which gave rise to 93 test cases, of which 76 were skipped 0 had missing libraries 13 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 4 unexpected failures 0 unexpected stat failures Unexpected failures: driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) hp2ps/T15904.run T15904 [bad stdout] (normal) libraries/unix/tests/user001.run user001 [bad stdout] (normal) libraries/unix/tests/T3816.run T3816 [bad exit code] (normal) Appending 0 stats to git notes. make[1]: *** [../mk/test.mk:342: test] Error 1 make[1]: Leaving directory '/home/jrp/Projects/ghc/testsuite/tests' make: *** [Makefile:224: test] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:50:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:50:15 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.a5dfe182ebfbc485c4331dcaf74bde92@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): @snowleopard: Ben reported the following to me in private: - when re-running hadrian the second time with `-VVV`, Ben saw: {{{ | Building Stage1 libraries: binary, Cabal, ghc, ghc-boot, ghc-boot- th, ghc-heap, ghci, hpc, mtl, parsec, template-haskell, text, transformers, terminfo, array, base, bytestring, containers, deepseq, directory, filepath, ghc-compact, ghc-prim, haskeline, integer-gmp, pretty, process, rts, stm, time, xhtml, libiserv, unix | Building Stage1 programs : ghc, ghc-pkg, hsc2hs, unlit, hpc, ghc- iserv, runghc # _build/stage1/lib/package.conf.d/ghc-8.7.conf # _build/stage1/lib/package.conf.d/Cabal-2.4.0.1.conf # _build/stage1/lib/package.conf.d/ghci-8.7.conf # _build/stage2/bin/ghctags # _build/stage2/bin/haddock # _build/stage1/lib/package.conf.d/text-1.2.3.1.conf # _build/stage1/lib/package.conf.d/parsec-3.1.13.0.conf # _build/stage1/lib/bin/ghc-iserv # _build/stage1/bin/hsc2hs # _build/stage1/bin/ghc # _build/stage1/lib/package.conf.d/haskeline-0.7.4.3.conf # _build/stage1/lib/package.conf.d/libiserv-8.7.1.conf # _build/stage1/bin/ghc-pkg # _build/stage0/lib/package.conf.d/directory-1.3.1.5.conf }}} and it just pauses there for ~15 seconds before it finally starts issuing build commands. - using -j16 or -j1 doesn't seem to affect the "pause" time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:50:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:50:57 -0000 Subject: [GHC] #15787: GHC panic using kind application In-Reply-To: <051.88158355ed422210999943d4c175f35d@haskell.org> References: <051.88158355ed422210999943d4c175f35d@haskell.org> Message-ID: <066.474ee2b59a34db04ecdf4ffc716ed336@haskell.org> #15787: GHC panic using kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15787 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5275 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged for 8.6.2 in 7a439e7b13f350e1ac6163f1bfa60e30924dbeea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:51:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:51:24 -0000 Subject: [GHC] #15796: Core Lint error with invalid newtype declaration In-Reply-To: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> References: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> Message-ID: <066.20293aa63bd734b01d5c96b881f2ad7f@haskell.org> #15796: Core Lint error with invalid newtype declaration -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T15796 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged for 8.6.2 in 41f0f6c2f571ea05c49f9f6ed64beebdc5a9f9fc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 21:59:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 21:59:49 -0000 Subject: [GHC] #15906: Stable name allocation causes heap corruption when GC is triggered in the primop In-Reply-To: <043.dc1662ef67173abf865b687c84575bba@haskell.org> References: <043.dc1662ef67173abf865b687c84575bba@haskell.org> Message-ID: <058.6b6f2f39d4ee5c56323bcc8f359987d0@haskell.org> #15906: Stable name allocation causes heap corruption when GC is triggered in the primop -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.3 Component: Runtime System | Version: 8.7 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:D5342 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 22cd729abc4bcda999e3563759d8cb33160e6af6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 22:00:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 22:00:27 -0000 Subject: [GHC] #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 In-Reply-To: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> References: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> Message-ID: <060.b715adce0a36e209ec0018a84b7e705a@haskell.org> #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1-beta1 Resolution: fixed | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5348 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with e67bebbf735db498c2cbf191d1878644ca5ed5cc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 22:00:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 22:00:40 -0000 Subject: [GHC] #15892: Segmentation fault with ByteString In-Reply-To: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> References: <043.1d75841dfccef07e6bafee040c5bbdcf@haskell.org> Message-ID: <058.1474c5e0bbea492c87af3a790106f9be@haskell.org> #15892: Segmentation fault with ByteString ----------------------------------+-------------------------------------- Reporter: akio | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5334 Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 4519d98d5399c2a958b2592b0ab50d89980d48b5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 22:01:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 22:01:10 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.6b4b4def463af4409b10999d833339b1@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.3 Component: None | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * version: => 8.6.1 * resolution: => fixed Comment: Merged with b6d2d8375e4c1425690e26d1f6bc1578f7ed1043. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 22:01:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 22:01:40 -0000 Subject: [GHC] #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH In-Reply-To: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> References: <050.a57b50b77df5fd7c6386ac1485c8460f@haskell.org> Message-ID: <065.c9482724d6a5a385c8ce08ae2a3ecff9@haskell.org> #15105: `typecheckModule` from GHC API crashes on MacOS for files with TH ----------------------------------+---------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.3 Component: GHC API | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged with 11fd7df565897fb98cda9273dab28ccc654a6d95. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 22:05:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 22:05:33 -0000 Subject: [GHC] #15715: problematic openFile with named pipes In-Reply-To: <042.429251213bdecb6b7a1355c60029957a@haskell.org> References: <042.429251213bdecb6b7a1355c60029957a@haskell.org> Message-ID: <057.dae9b2fca8700519731c5dbb6c8c23b6@haskell.org> #15715: problematic openFile with named pipes -------------------------------------+------------------------------------- Reporter: adp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: libraries/base | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect API | (amd64) annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5295 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 64a5044543bdcd7983787b215a44bdfb70c9c40b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 22:05:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 22:05:35 -0000 Subject: [GHC] #15859: Dependent quantification, GHC panic In-Reply-To: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> References: <051.f05fe870fb942184e37a5ef9d7a7afd5@haskell.org> Message-ID: <066.82353b6f4e1f15f765f096baef2829ff@haskell.org> #15859: Dependent quantification, GHC panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T15859 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 2594ea25641e4b27327449d40c5dd2d46d837af1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 22:05:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 22:05:40 -0000 Subject: [GHC] #15875: Detection of ranlib by binary distribution is broken In-Reply-To: <046.b6e27acc1336ece3a6d2d7b8c747c824@haskell.org> References: <046.b6e27acc1336ece3a6d2d7b8c747c824@haskell.org> Message-ID: <061.a94d46bbed8215d3c0dd3699403bbaa2@haskell.org> #15875: Detection of ranlib by binary distribution is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 Comment: Merged in 130b91dbdca6ef3a82e2b178e04bda0a694a4ca4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 22:41:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 22:41:39 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.6d8bbdc26bceb00a88a652fc6f8aae79@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 22 23:32:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Nov 2018 23:32:47 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.222a30a18a4b4565e653b71f898c6b63@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Aha, I see. One theory I have is that the cache oracles we added for various Cabal parsing actions [1] have not been recorded in the database on `Ctrl-C`, hence we need to rerun them. Perhaps, Shake saves these cached oracles only on successful completion of a build? [1] https://github.com/snowleopard/hadrian/pull/692 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 05:07:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 05:07:29 -0000 Subject: [GHC] #15939: StgLint fails because Stg bindings are not dependency-ordered Message-ID: <043.2c303ed169474c399bb1733aa9ca13da@haskell.org> #15939: StgLint fails because Stg bindings are not dependency-ordered -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | 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: #9718 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After Phab:D5370 if I enable `-dstg-lint` when running the test suite I get about a dozen failures. I didn't check all, but most of them are because Stg bindings are not dependency-ordered, so some bindings come later in the list of bindings than their uses. I added a few debug prints to figure out if we ever have the bindings ordered in the pipeline. As far as I can see, by the time we desugar we have dependency-ordered bindings, but simplifier breaks the ordering by introducing uses. There are also "implicit" bindings introduced after simplifications (e.g. in CorePrep). Because of this by the time we start Stg generation we already have incorrect ordering. I think we have these options: - Don't assume dependency ordering in StgLint. Bring all top-level binders into the scope before linting bindings. - Somehow maintain dependency ordering in all of the Core passes so that by the time we start generating Stg we have an ordered list of bindings. (seems hard) - Sort Stg bindings in `CoreToStg`. (1) and (3) are equally simple, but (3) requires an extra pass over bindings. However, to be able to do the `CafInfo` analysis for #9718 efficiently we need (3), so I suggest implementing (3). We can then enable `-dstg-lint` in the test suite for all tests (add it to `TEST_HC_OPTS` in `testsuite/mk/test/mk`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 06:09:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 06:09:30 -0000 Subject: [GHC] #15939: StgLint fails because Stg bindings are not dependency-ordered In-Reply-To: <043.2c303ed169474c399bb1733aa9ca13da@haskell.org> References: <043.2c303ed169474c399bb1733aa9ca13da@haskell.org> Message-ID: <058.0a3708774e8c6af9ad06819025fb5e68@haskell.org> #15939: StgLint fails because Stg bindings are not dependency-ordered -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new 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: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Another problem with (3) is that it needs to traverse the whole program, we can't resuse free variable fields of `CgStgTopBinding` because those don't include top-level free vars, but we need those for the dependency analysis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 06:27:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 06:27:11 -0000 Subject: [GHC] #602: Warning Suppression In-Reply-To: <047.d851345fc677a304d933040775d25d45@haskell.org> References: <047.d851345fc677a304d933040775d25d45@haskell.org> Message-ID: <062.5e8c600e031837fb9e15a60ee6091fe1@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 | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 09:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 09:28:04 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.a04fc081872dd6fffb29f0a78ea44239@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: | Keywords: 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 Tritlo): * cc: Tritlo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 09:38:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 09:38:13 -0000 Subject: [GHC] #15937: CI strategy for Gitlab In-Reply-To: <048.738065983349c6ff7ad5141b89ce5589@haskell.org> References: <048.738065983349c6ff7ad5141b89ce5589@haskell.org> Message-ID: <063.1331c4612aa3f7b3cf7bc650f1a00b47@haskell.org> #15937: CI strategy for Gitlab -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 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: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: bgamari => alpmestan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 09:49:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 09:49:13 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.dfdb9ed64bf64a33028363b96d19c072@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Phab:D5312 Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * status: new => closed * resolution: => fixed Old description: > With a simple package: > > issue.cabal: > {{{ > name: issue > version: 0 > cabal-version: >= 1.10 > build-type: Simple > > library > build-depends: base, binary, binary-orphans==0.1.5.2 > exposed-modules: Issue > }}} > > Issue.hs: > {{{ > {-# LANGUAGE DeriveGeneric #-} > {-# OPTIONS_GHC -Wall #-} > module Issue (T (..)) where > > import Prelude () > import Data.Binary.Orphans > import Data.Binary (Binary (..)) > import GHC.Generics (Generic) > import Data.Aeson (Value) > > data T = T Value deriving (Generic) > > instance Binary T > }}} > > GHC 7.10.3 correctly reports: > {{{ > Issue.hs:7:1: Warning: > The import of ‘Data.Binary’ is redundant > except perhaps to import instances from ‘Data.Binary’ > To import instances alone, use: import Data.Binary() > }}} > > GHC 8.0.1 incorrectly (!!!) reports: > > {{{ > Issue.hs:6:1: warning: [-Wunused-imports] > The import of ‘Data.Binary.Orphans’ is redundant > except perhaps to import instances from ‘Data.Binary.Orphans’ > To import instances alone, use: import Data.Binary.Orphans( > }}} > > but `Binary Value` instance is imported from `Data.Binary.Orphans`. > > --- > > In real life while compiling https://github.com/futurice/haskell-mega- > repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- > github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't > reported, as `Futurice.Prelude` exports other stuff, which is used. See > https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for > minimal imports reported with `-ddump-minimal-imports`. > > ## Status > > I've submitted some PRs to fix the impending unused import warnings: > > * MERGED https://github.com/haskell/cabal/pull/5673 > * https://github.com/kolmodin/binary/pull/159 > * MERGED https://github.com/haskell/bytestring/pull/168 > * MERGED https://github.com/haskell/containers/pull/576 > * MERGED https://github.com/haskell/text/pull/240 > > I've also added a new ghc patch here: > * https://phabricator.haskell.org/D5312 New description: With a simple package: issue.cabal: {{{ name: issue version: 0 cabal-version: >= 1.10 build-type: Simple library build-depends: base, binary, binary-orphans==0.1.5.2 exposed-modules: Issue }}} Issue.hs: {{{ {-# LANGUAGE DeriveGeneric #-} {-# OPTIONS_GHC -Wall #-} module Issue (T (..)) where import Prelude () import Data.Binary.Orphans import Data.Binary (Binary (..)) import GHC.Generics (Generic) import Data.Aeson (Value) data T = T Value deriving (Generic) instance Binary T }}} GHC 7.10.3 correctly reports: {{{ Issue.hs:7:1: Warning: The import of ‘Data.Binary’ is redundant except perhaps to import instances from ‘Data.Binary’ To import instances alone, use: import Data.Binary() }}} GHC 8.0.1 incorrectly (!!!) reports: {{{ Issue.hs:6:1: warning: [-Wunused-imports] The import of ‘Data.Binary.Orphans’ is redundant except perhaps to import instances from ‘Data.Binary.Orphans’ To import instances alone, use: import Data.Binary.Orphans( }}} but `Binary Value` instance is imported from `Data.Binary.Orphans`. --- In real life while compiling https://github.com/futurice/haskell-mega- repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't reported, as `Futurice.Prelude` exports other stuff, which is used. See https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for minimal imports reported with `-ddump-minimal-imports`. ## Status I've submitted some PRs to fix the impending unused import warnings: * MERGED https://github.com/haskell/cabal/pull/5673 * MERGED https://github.com/kolmodin/binary/pull/159 * MERGED https://github.com/haskell/bytestring/pull/168 * MERGED https://github.com/haskell/containers/pull/576 * MERGED https://github.com/haskell/text/pull/240 I've also added a new ghc patch here: * MERGED https://phabricator.haskell.org/D5312 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 11:32:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 11:32:47 -0000 Subject: [GHC] #15936: Rethink Choice of Baseline Commit for Performance Tests In-Reply-To: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> References: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> Message-ID: <060.a71b8aec78b4ec7bb55c3ce708fd6d7f@haskell.org> #15936: Rethink Choice of Baseline Commit for Performance Tests -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git 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: | -------------------------------------+------------------------------------- Description changed by davide: Old description: > = Intro = > > Currently we always use the previous commit when running performance > tests. This works well in CI where we fully test each commit in sequence > (and hence always have test results for the previous commit). Remember, > test results are stored in git notes and are not by default shared > between repositories (i.e. your local repo will only have performance > results run locally on your machine). This is by design: we want to avoid > comparing results form different machines. > > Unfortunately This is not so effective when testing locally. The > programmer may have only run a subset of performance tests on the > previous commit, and often have not run the tests at all (this is notably > true after performing a rebase: the previous commit has changed). We need > to rethink how we pick a baseline commit. > > = Goals = > > * In all cases, do something sensible. > * Giving a warning if conditions are not idea. Provide clear and simple > instructions on how to get to the ideal case. > * Give control over the baseline commit to the programmer via command > line options. > * In general, performance tests should just work! No extra knowledge > needed by the programmer. > * If tests pass without warning now, then they should pass without > warning later. > > = Proposed Solution = > > * Choose baseline commit > * Provide command line arguments to set the baseline commit > * If not baseline commit is provided use the "Ideal baseline commit". > * If local test results for the baseline are available use those results. > * Else if results from CI are available (without fetching), then use > those results. > * Else Warn user that there are no results available (tests trivially > pass), then suggest fetching CI results (quick and easy, give full > command, mention you may have to wait for CI to finish if the commit is > recent) or running locally (more accurate, mention exact commit to > checkout), or manually select a baseline commit. > > == Ideal baseline commit == > > * If there are no new changes: 0 ahead and 0 or more behind master. > * Ideal baseline commit is the previous commit. > * Else 1 or more ahead and 0 or more behind master. > * Ideal baseline commit is `merge-base master HEAD` > * Assume that the intention is to create a patch where all new commits > will ultimately be squashed and placed on top of master. We only want to > consider performance changes caused by the new commits, so we use the > merge base instead of master HEAD (though these may be the same commit). > > = Open issues = > > If commits between HEAD and the baseline commit > [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests#ExpectedPerformanceChanges > allow changes] in performance numbers, what should the behaviour be? What > happens if this is merged? The commits will be squashed: this could > affect the commit message and hence the allowed changes which is parsed > from the commit messages. > > = Use cases = > > TODO This section is a WIP > > We generally will assume that the master branch corresponds to ghc's > master branch (though may be slightly out of date). > > ||= Case =||= Details =||= Baseline =|| > || 0 commits ahead of master || May be on master or branched off master > with no new commits || previous commit || > || CI pre-merge || > || CI post-merge New description: = Intro = Currently we always use the previous commit when running performance tests. This works well in CI where we fully test each commit in sequence (and hence always have test results for the previous commit). Remember, test results are stored in git notes and are not by default shared between repositories (i.e. your local repo will only have performance results run locally on your machine). This is by design: we want to avoid comparing results form different machines. Unfortunately This is not so effective when testing locally. The programmer may have only run a subset of performance tests on the previous commit, and often have not run the tests at all (this is notably true after performing a rebase: the previous commit has changed). We need to rethink how we pick a baseline commit. = Goals = * In all cases, do something sensible. * Giving a warning if conditions are not idea. Provide clear and simple instructions on how to get to the ideal case. * Give control over the baseline commit to the programmer via command line options. * Give control over the baseline of local or ci to the programmer via command line options. * In general, performance tests should just work! No extra knowledge needed by the programmer. * If tests pass without warning now, then they should pass without warning later. = Proposed Solution = * Choose baseline commit * Provide command line arguments to set the baseline commit * If not baseline commit is provided use the "Ideal baseline commit". * If local test results for the baseline are available use those results. * Else if results from CI are available (without fetching), then use those results. * Else Warn user that there are no results available (tests trivially pass), then suggest fetching CI results (quick and easy, give full command, mention you may have to wait for CI to finish if the commit is recent) or running locally (more accurate, mention exact commit to checkout), or manually select a baseline commit. == Ideal baseline commit == * If there are no new changes: 0 ahead and 0 or more behind master. * Ideal baseline commit is the previous commit. * Else 1 or more ahead and 0 or more behind master. * Ideal baseline commit is `merge-base master HEAD` * Assume that the intention is to create a patch where all new commits will ultimately be squashed and placed on top of master. We only want to consider performance changes caused by the new commits, so we use the merge base instead of master HEAD (though these may be the same commit). An easy way to implement this is: {{{ mergeBase = merge-base master HEAD baseline = if mergeBase == HEAD then HEAD^ else mergeBase }}} = Open issues = If commits between HEAD and the baseline commit [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests#ExpectedPerformanceChanges allow changes] in performance numbers, what should the behaviour be? What happens if this is merged? The commits will be squashed: this could affect the commit message and hence the allowed changes which is parsed from the commit messages. TODO assume programmer only adds such annotations as tests fail, and doesn't want to renter them in full. We still test against baseline. Combine all allowed changes, prefering latest when there is overlap (I think thats right... think about adding a commit that decreases a metric, then you add another commit that increases it (compared to baseline), then overall this is an increase and we can ignore the intermediate decrease, thanks to the commits ultimately being squashed). Warn about what to put in squashed commit. We must figure out what commit messages will be used in GitLab on merge. = Use cases = * We do not distinguish between full/partial performance results being available for the baseline commit: that would require checking out the baseline commit and extracting the full list of tests. * == Locally validate a commit from master == {{{ git checkout master~5 ./validate }}} Baseline Commit: HEAD^ == master~6 || BaselinelocalResults || BaselineCIResults || Infos || Warnings || ||||= Case =||||||= Behaviour =|| ||= Baseline local Results? =||= Baseline CI Results? =||= Baseline local/CI =||= Infos =||= Warnings =|| || Yes/Partial || - || Local || If HEAD tests is not subset or eq to Baseline tests: "If relevant tests exist on baseline, checkout baseline and running those tests OR fetch notes and use --baseline-ci || Warnings || || No || Yes || CI || "Using CI numbers, suggest running locally for more accurate results" || Warnings || || No || No || - || || "No baseline results, tests trivially pass" + suggest fetch notes or locally run tests on baseline || == Locally validate a commit from master == {{{ git checkout master~5 ./validate }}} Baseline Commit: HEAD^ == master~6 || BaselinelocalResults || BaselineCIResults || Infos || Warnings || ||||= Case =||||||= Behaviour =|| ||= Baseline local Results? =||= Baseline CI Results? =||= Baseline local/CI =||= Infos =||= Warnings =|| || Yes/Partial || - || Local || If HEAD tests is not subset or eq to Baseline tests: "If relevant tests exist on baseline, checkout baseline and running those tests OR fetch notes and use --baseline-ci || Warnings || || No || Yes || CI || "Using CI numbers, suggest running locally for more accurate results" || Warnings || || No || No || - || || "No baseline results, tests trivially pass" + suggest fetch notes or locally run tests on baseline || = From the perspective of the CI = ?? From CI, "local" is actually "CI". SO replace "is CI results available" with "no" and replace "Is local results available" with "is CI results available" = When to automatically fetch CI results? = If baseline commit doesn't have local nor CI results, and is old enough such that we expect CI to have been run (WARNING we would need to know the merge time, not the time that the commit was created, which could be long before it was merged? Or will GitLab bump the commit time on merge?) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 13:26:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 13:26:14 -0000 Subject: [GHC] #15940: Source plugins should be able to opt-out from appearing in dependencies Message-ID: <056.69264ef623468a97047b946b3e8db6f3@haskell.org> #15940: Source plugins should be able to opt-out from appearing in dependencies -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: source | Operating System: Unknown/Multiple plugins | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently when ghc build a module M using a source plugin in a package P, P shows up in the interface file of M (`M.hi`). According to `--show-iface`, P shows up in the `package dependencies` section, and in an `addDependentFile` entry. Presumably, this is necessary to recompile M if P ever changes. But unfortunately, including P in the interface file is the wrong thing to do when the plugin does not affect the result of the compilation of M. It is only fair to wonder what the point would be in using a plugin which does not modify the compilation. I hit this case when using the upcoming haskell-indexer-plugin, which extracts source code information for later examination. If the indexer plugin changes, there is no point in rebuilding M, unless the user really wants to reindex the source code. Can we change the plugin interface to opt-out of tracking dependencies? Or would it work better to provide a ghc flag to control this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 13:26:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 13:26:36 -0000 Subject: [GHC] #15940: Source plugins should be able to opt-out from appearing in dependencies In-Reply-To: <056.69264ef623468a97047b946b3e8db6f3@haskell.org> References: <056.69264ef623468a97047b946b3e8db6f3@haskell.org> Message-ID: <071.98838e8406d11de266f18867a10d56de@haskell.org> #15940: Source plugins should be able to opt-out from appearing in dependencies -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: source | 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 facundo.dominguez): * cc: robinpp (removed) * cc: robinp (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 13:30:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 13:30:51 -0000 Subject: [GHC] #15940: Source plugins should be able to opt-out from appearing in dependencies In-Reply-To: <056.69264ef623468a97047b946b3e8db6f3@haskell.org> References: <056.69264ef623468a97047b946b3e8db6f3@haskell.org> Message-ID: <071.f7c250cdef4064986d7407836f55945f@haskell.org> #15940: Source plugins should be able to opt-out from appearing in dependencies -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: source | 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: | -------------------------------------+------------------------------------- Description changed by facundo.dominguez: Old description: > Currently when ghc build a module M using a source plugin in a package P, > P shows up in the interface file of M (`M.hi`). > > According to `--show-iface`, P shows up in the `package dependencies` > section, and in an `addDependentFile` entry. > > Presumably, this is necessary to recompile M if P ever changes. But > unfortunately, including P in the interface file is the wrong thing to do > when the plugin does not affect the result of the compilation of M. > > It is only fair to wonder what the point would be in using a plugin which > does not modify the compilation. I hit this case when using the upcoming > haskell-indexer-plugin, which extracts source code information for later > examination. > > If the indexer plugin changes, there is no point in rebuilding M, unless > the user really wants to reindex the source code. > > Can we change the plugin interface to opt-out of tracking dependencies? > Or would it work better to provide a ghc flag to control this? New description: Currently when ghc build a module M using a source plugin in a package P, P shows up in the interface file of M (`M.hi`). According to `--show-iface`, P shows up in the `package dependencies` section, and in an `addDependentFile` entry. Presumably, this is necessary to recompile M if P ever changes. But unfortunately, including P in the interface file is the wrong thing to do when the plugin does not affect the result of the compilation of M. It is only fair to wonder what the point would be in using a plugin which does not modify the compilation. I hit this case when using the upcoming haskell-indexer-plugin, which extracts source code information for later examination. If the indexer plugin changes, there is no point in rebuilding M, unless the user really wants to reindex the source code. As things stand, `ghc` wants to know where the plugin is every time it is mentioned in the dependencies of a module which is being linked, even though the plugin won't be used for anything. This sometimes can make the plugin harder to use in a large project. Can we change the plugin interface to opt-out of tracking dependencies? Or would it work better to provide a ghc flag to control this? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 13:31:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 13:31:51 -0000 Subject: [GHC] #15940: Source plugins should be able to opt-out from appearing in dependencies In-Reply-To: <056.69264ef623468a97047b946b3e8db6f3@haskell.org> References: <056.69264ef623468a97047b946b3e8db6f3@haskell.org> Message-ID: <071.21f8e16dc6bac1aa07cbe27b98bb4c69@haskell.org> #15940: Source plugins should be able to opt-out from appearing in dependencies -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: source | plugins 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 facundo.dominguez): * failure: None/Unknown => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 13:35:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 13:35:46 -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.acbc69269a36b80841ad69bbcdccf661@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.8.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 osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 14:17:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 14:17:38 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.40fbcc71a8c83a66f1f719b231eda0ca@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.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 RyanGlScott): * status: patch => new * differential: Phab:D5301 => Comment: I made a good-faith attempt to get Phab:D5301 past the review process, but I simply couldn't muster the energy to finish it. I've abandoned Phab:D5301, although I would gladly support anyone who wishes to pick it back up again and see it to completion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 15:12:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 15:12:58 -0000 Subject: [GHC] #15319: Configurable/overridable settings file In-Reply-To: <044.ba7ad8d95aa9a6958eb5b0890b79f3ba@haskell.org> References: <044.ba7ad8d95aa9a6958eb5b0890b79f3ba@haskell.org> Message-ID: <059.099777f7192983ea0de03e3ce1fc5845@haskell.org> #15319: Configurable/overridable settings file -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5317 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Hopefully this should address the primary concern of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 15:17:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 15:17:12 -0000 Subject: [GHC] #11301: Using GHC's parser and rendering the results is unreasonably difficult In-Reply-To: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> References: <048.755603274e92f5cd3f9164017f9ed403@haskell.org> Message-ID: <063.b96e91aca12845a5b2ae9ccef118a82e@haskell.org> #11301: Using GHC's parser and rendering the results is unreasonably difficult -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The above patch has decoupled `DynFlags` from `ParserFlags`: {{{#!hs mkParserFlags' :: EnumSet WarningFlag -- ^ warnings flags enabled -> EnumSet LangExt.Extension -- ^ permitted language extensions enabled -> UnitId -- ^ key of package currently being compiled -> Bool -- ^ are safe imports on? -> Bool -- ^ keeping Haddock comment tokens -> Bool -- ^ keep regular comment tokens -> ParserFlags }}} However, I suspect there is still more to be done here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 15:26:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 15:26:50 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.1d1448db6c8fe467f3bb4e1b4ec45df0@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by Sebastian Graf ): In [changeset:"b2950e03b551d82d62ec25eb232284aaf121b4e2/ghc" b2950e03/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b2950e03b551d82d62ec25eb232284aaf121b4e2" Implement late lambda lift Summary: This implements a selective lambda-lifting pass late in the STG pipeline. Lambda lifting has the effect of avoiding closure allocation at the cost of having to make former free vars available at call sites, possibly enlarging closures surrounding call sites in turn. We identify beneficial cases by means of an analysis that estimates closure growth. There's a Wiki page at https://ghc.haskell.org/trac/ghc/wiki/LateLamLift. Reviewers: simonpj, bgamari, simonmar Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #9476 Differential Revision: https://phabricator.haskell.org/D5224 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 16:26:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 16:26:16 -0000 Subject: [GHC] #15810: Kind inference error in classes In-Reply-To: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> References: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> Message-ID: <062.806105b19b89945a25ca849eaba0862d@haskell.org> #15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): Phab:D5305 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmph. Given {{{ class C a where meth :: Proxy (a :: k) }}} where is the implicit forall for that `k`? Currently it's quantifed at the `::`, thus: {{{ class C a where meth :: forall k. Proxy (a :: k) }}} And indeed that is ill-typed, and elicits {{{ T15810.hs:9:18: error: • Expected kind ‘k’, but ‘a’ has kind ‘k0’ • In the first argument of ‘Proxy’, namely ‘(a :: k)’ In the type signature: meth :: Proxy (a :: k) }}} If you brought `k` into scope further out it'd be fine {{{ class C a where meth :: Proxy (a :: k) }}} In short I say this is not a bug. Do you disagree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 16:36:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 16:36:35 -0000 Subject: [GHC] #15936: Rethink Choice of Baseline Commit for Performance Tests In-Reply-To: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> References: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> Message-ID: <060.765c4db432062356336572547c8f97b5@haskell.org> #15936: Rethink Choice of Baseline Commit for Performance Tests -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git 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: | -------------------------------------+------------------------------------- Description changed by davide: Old description: > = Intro = > > Currently we always use the previous commit when running performance > tests. This works well in CI where we fully test each commit in sequence > (and hence always have test results for the previous commit). Remember, > test results are stored in git notes and are not by default shared > between repositories (i.e. your local repo will only have performance > results run locally on your machine). This is by design: we want to avoid > comparing results form different machines. > > Unfortunately This is not so effective when testing locally. The > programmer may have only run a subset of performance tests on the > previous commit, and often have not run the tests at all (this is notably > true after performing a rebase: the previous commit has changed). We need > to rethink how we pick a baseline commit. > > = Goals = > > * In all cases, do something sensible. > * Giving a warning if conditions are not idea. Provide clear and simple > instructions on how to get to the ideal case. > * Give control over the baseline commit to the programmer via command > line options. > * Give control over the baseline of local or ci to the programmer via > command line options. > * In general, performance tests should just work! No extra knowledge > needed by the programmer. > * If tests pass without warning now, then they should pass without > warning later. > > = Proposed Solution = > > * Choose baseline commit > * Provide command line arguments to set the baseline commit > * If not baseline commit is provided use the "Ideal baseline commit". > * If local test results for the baseline are available use those results. > * Else if results from CI are available (without fetching), then use > those results. > * Else Warn user that there are no results available (tests trivially > pass), then suggest fetching CI results (quick and easy, give full > command, mention you may have to wait for CI to finish if the commit is > recent) or running locally (more accurate, mention exact commit to > checkout), or manually select a baseline commit. > > == Ideal baseline commit == > > * If there are no new changes: 0 ahead and 0 or more behind master. > * Ideal baseline commit is the previous commit. > * Else 1 or more ahead and 0 or more behind master. > * Ideal baseline commit is `merge-base master HEAD` > * Assume that the intention is to create a patch where all new commits > will ultimately be squashed and placed on top of master. We only want to > consider performance changes caused by the new commits, so we use the > merge base instead of master HEAD (though these may be the same commit). > > An easy way to implement this is: > {{{ > mergeBase = merge-base master HEAD > baseline = if mergeBase == HEAD > then HEAD^ > else mergeBase > }}} > > = Open issues = > > If commits between HEAD and the baseline commit > [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests#ExpectedPerformanceChanges > allow changes] in performance numbers, what should the behaviour be? What > happens if this is merged? The commits will be squashed: this could > affect the commit message and hence the allowed changes which is parsed > from the commit messages. > > TODO assume programmer only adds such annotations as tests fail, and > doesn't want to renter them in full. We still test against baseline. > Combine all allowed changes, prefering latest when there is overlap (I > think thats right... think about adding a commit that decreases a metric, > then you add another commit that increases it (compared to baseline), > then overall this is an increase and we can ignore the intermediate > decrease, thanks to the commits ultimately being squashed). Warn about > what to put in squashed commit. > > We must figure out what commit messages will be used in GitLab on merge. > > = Use cases = > > * We do not distinguish between full/partial performance results being > available for the baseline commit: that would require checking out the > baseline commit and extracting the full list of tests. > * > > == Locally validate a commit from master == > > {{{ > git checkout master~5 > ./validate > }}} > > Baseline Commit: HEAD^ == master~6 > > || BaselinelocalResults || BaselineCIResults || Infos || Warnings || > > ||||= Case =||||||= Behaviour =|| > ||= Baseline local Results? =||= Baseline CI Results? =||= Baseline > local/CI =||= Infos =||= Warnings =|| > || Yes/Partial || - || Local || If HEAD tests is not subset or eq to > Baseline tests: "If relevant tests exist on baseline, checkout baseline > and running those tests OR fetch notes and use --baseline-ci || Warnings > || > || No || Yes || CI || "Using CI numbers, suggest running locally for more > accurate results" || Warnings || > || No || No || - || || "No baseline results, tests trivially pass" + > suggest fetch notes or locally run tests on baseline || > > == Locally validate a commit from master == > > {{{ > git checkout master~5 > ./validate > }}} > > Baseline Commit: HEAD^ == master~6 > > || BaselinelocalResults || BaselineCIResults || Infos || Warnings || > > ||||= Case =||||||= Behaviour =|| > ||= Baseline local Results? =||= Baseline CI Results? =||= Baseline > local/CI =||= Infos =||= Warnings =|| > || Yes/Partial || - || Local || If HEAD tests is not subset or eq to > Baseline tests: "If relevant tests exist on baseline, checkout baseline > and running those tests OR fetch notes and use --baseline-ci || Warnings > || > || No || Yes || CI || "Using CI numbers, suggest running locally for more > accurate results" || Warnings || > || No || No || - || || "No baseline results, tests trivially pass" + > suggest fetch notes or locally run tests on baseline || > > = From the perspective of the CI = > > ?? From CI, "local" is actually "CI". SO replace "is CI results > available" with "no" and replace "Is local results available" with "is CI > results available" > > = When to automatically fetch CI results? = > > If baseline commit doesn't have local nor CI results, and is old enough > such that we expect CI to have been run (WARNING we would need to know > the merge time, not the time that the commit was created, which could be > long before it was merged? Or will GitLab bump the commit time on merge?) New description: = Intro = Currently we always use the previous commit when running performance tests. This works well in CI where we fully test each commit in sequence (and hence always have test results for the previous commit). Remember, test results are stored in git notes and are not by default shared between repositories (i.e. your local repo will only have performance results run locally on your machine). This is by design: we want to avoid comparing results form different machines. Unfortunately This is not so effective when testing locally. The programmer may have only run a subset of performance tests on the previous commit, and often have not run the tests at all (this is notably true after performing a rebase: the previous commit has changed). We need to rethink how we pick a baseline commit. = Goals = * In all cases, do something sensible. * Giving a warning if conditions are not idea. Provide clear and simple instructions on how to get to the ideal case. * Give control over the baseline commit to the programmer via command line options. * Could make it a baseline branch where we still do git merge-base. That would be useful if you are branching from a different branch than master. * Give control over the baseline of local or ci to the programmer via command line options. * In general, performance tests should just work! No extra knowledge needed by the programmer. * If tests pass without warning now, then they should pass without warning later. = Proposed Solution = * When running performance tests, results will be compared to a baseline commit that is the merge base with master (most recent commit from master). If HEAD is already in master, then the previous commit is used instead. * If any locally generated performance results exist, they are used exclusively for the baseline. * Else if any CI generated performance results exist (and have been fetched), they are used exclusively for the baseline. * Else performance tests trivially pass, and a warning is given to the user. To find the baseline commit: {{{ mergeBase = merge-base master HEAD baselineCommit = if mergeBase == HEAD then HEAD^ else mergeBase }}} == Reasoning == * We want each commit in master not to introduce a significant change in performance: hence we compare commits in mater to the previous commit. * If not on master (1 or more ahead and 0 or more commits behind master). We assume that the intention is to create a patch where all new commits will ultimately be squashed and placed on top of master as a single commit. On the other hand we don't want to consider changes in master from after we branched. Instead of using master HEAD as the baseline, we use the commit from which we branched from master (i.e. the merge base). In other words we are concerned only with the change in performance introduced by the newly crated commits. = Handling Expected changes = See [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests#ExpectedPerformanceChanges expected performance changes]. If on master or an ancestor commit, the baseline is the previous commit and we can simply allow performance changes as specified in the current commit's message (this is already the behaviour of the test driver). If we have branched from master, then we may have multiple commits from the baseline commit to HEAD, each of which may have, possibly contradictory, expected performance changes. If any expected changes exist, aggregate them. We introduce an explicit "Metric Unchanged" option and aggregate per test taking the newest commit. "Metric Unchanged" is necessary in the case that a new commit undoes a performance change such that a metric returns to the baseline value. The aggregate version should be output so that the programmer knows what to put in the commit message after squashing the commits. == Reasoning == creating new commits with expected changes is an interactive process. The programmer adds a 1 or more commits, runs the tests, then adds expected performance changes to a commit message. It would be too inconvenient to force the programmer to change old commit messages, and too verbose/annoying to have them enter a full list of expected changes in each commit. Hence we must aggregate the expected changes. This is of a bit risky as it is a context sensitive change in the semantics of expected changes. If we e.g. intend not to squash the commits, then all the sudden the expected changes mean something very different (change to the previous commit, not some distant baseline commit). Perhaps we just show a warning in this case. We must figure out what commit messages will be used in GitLab on merge. Does the programmer have to remember to sort out expected changes before merge some how? = Use cases = * We do not distinguish between full/partial performance results being available for the baseline commit: that would require checking out the baseline commit and extracting the full list of tests. * == Locally validate a commit from master == {{{ git checkout master~5 ./validate }}} Baseline Commit: HEAD^ == master~6 || BaselinelocalResults || BaselineCIResults || Infos || Warnings || ||||= Case =||||||= Behaviour =|| ||= Baseline local Results? =||= Baseline CI Results? =||= Baseline local/CI =||= Infos =||= Warnings =|| || Yes/Partial || - || Local || If HEAD tests is not subset or eq to Baseline tests: "If relevant tests exist on baseline, checkout baseline and running those tests OR fetch notes and use --baseline-ci || Warnings || || No || Yes || CI || "Using CI numbers, suggest running locally for more accurate results" || Warnings || || No || No || - || || "No baseline results, tests trivially pass" + suggest fetch notes or locally run tests on baseline || == Locally validate a commit from master == {{{ git checkout master~5 ./validate }}} Baseline Commit: HEAD^ == master~6 || BaselinelocalResults || BaselineCIResults || Infos || Warnings || ||||= Case =||||||= Behaviour =|| ||= Baseline local Results? =||= Baseline CI Results? =||= Baseline local/CI =||= Infos =||= Warnings =|| || Yes/Partial || - || Local || If HEAD tests is not subset or eq to Baseline tests: "If relevant tests exist on baseline, checkout baseline and running those tests OR fetch notes and use --baseline-ci || Warnings || || No || Yes || CI || "Using CI numbers, suggest running locally for more accurate results" || Warnings || || No || No || - || || "No baseline results, tests trivially pass" + suggest fetch notes or locally run tests on baseline || = From the perspective of the CI = ?? From CI, "local" is actually "CI". SO replace "is CI results available" with "no" and replace "Is local results available" with "is CI results available" = When to automatically fetch CI results? = If baseline commit doesn't have local nor CI results, and is old enough such that we expect CI to have been run (WARNING we would need to know the merge time, not the time that the commit was created, which could be long before it was merged? Or will GitLab bump the commit time on merge?) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 19:04:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 19:04:27 -0000 Subject: [GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) In-Reply-To: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> References: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> Message-ID: <065.da8bb8ead4a5f6c731eedc993c4bb6d5@haskell.org> #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): Not sure whether this commit is breaking the current {{{validate --slow}}} build: {{{ "inplace/bin/ghc-stage1" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -this-unit-id containers-0.6.0.1 -hide-all-packages -i -ilibraries/containers/. -ilibraries/containers/dist-install/build -Ilibraries/containers/dist-install/build -ilibraries/containers/dist- install/build/./autogen -Ilibraries/containers/dist- install/build/./autogen -Ilibraries/containers/include -Ilibraries/containers/dist-install/build/include -optP-include -optPlibraries/containers/dist-install/build/./autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id deepseq-1.4.4.0 -package-id ghc-prim-0.5.3 -O2 -Wall -XHaskell98 -O -dcore-lint -dno-debug-output -no-user-package-db -rtsopts -Wno- deprecated-flags -Wnoncanonical-monad-instances -odir libraries/containers/dist-install/build -hidir libraries/containers/dist- install/build -stubdir libraries/containers/dist-install/build -c libraries/containers/./Data/Sequence/Internal.hs -o libraries/containers /dist-install/build/Data/Sequence/Internal.p_o -dyno libraries/containers /dist-install/build/Data/Sequence/Internal.dyn_o libraries/containers/Data/Set/Internal.hs:239:1: error: [-Wunused-imports, -Werror=unused-imports] The import of ‘<>’ from module ‘Data.Semigroup’ is redundant | 239 | import Data.Semigroup (Semigroup((<>), stimes), stimesIdempotentMonoid) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ make[1]: *** [libraries/containers/ghc.mk:4: libraries/containers/dist- install/build/Data/Set/Internal.p_o] Error 1 make[1]: *** Waiting for unfinished jobs.... libraries/containers/Data/IntSet/Internal.hs:198:1: error: [-Wunused- imports, -Werror=unused-imports] The import of ‘<>’ from module ‘Data.Semigroup’ is redundant | 198 | import Data.Semigroup (Semigroup((<>), stimes), stimesIdempotentMonoid) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libraries/containers/Data/IntSet/Internal.hs:220:1: error: [-Wunused- imports, -Werror=unused-imports] The import of ‘Data.Foldable’ is redundant except perhaps to import instances from ‘Data.Foldable’ To import instances alone, use: import Data.Foldable() | 220 | import Data.Foldable (Foldable()) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ make[1]: *** [libraries/containers/ghc.mk:4: libraries/containers/dist- install/build/Data/IntSet/Internal.p_o] Error 1 make: *** [Makefile:128: all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 19:38:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 19:38:58 -0000 Subject: [GHC] #15875: Detection of ranlib by binary distribution is broken In-Reply-To: <046.b6e27acc1336ece3a6d2d7b8c747c824@haskell.org> References: <046.b6e27acc1336ece3a6d2d7b8c747c824@haskell.org> Message-ID: <061.e1aacb35ffb7b2af4676481763130ef9@haskell.org> #15875: Detection of ranlib by binary distribution is broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0a126a32d1bbdb3bb70030a77e01415e19ea8b6e/ghc" 0a126a32/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0a126a32d1bbdb3bb70030a77e01415e19ea8b6e" distrib/configure: Set RanlibCmd This fixes #15875. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 20:12:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 20:12:34 -0000 Subject: [GHC] #15941: Pretty-printing of invisible arguments to (->) Message-ID: <047.398646946505bae0b9a71adeab6b5eee@haskell.org> #15941: Pretty-printing of invisible arguments to (->) -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 invisible arguments to `(->)` are currently printed as: {{{ λ> :set -XKindSignatures -fprint-explicit-runtime-reps -fprint-explicit- kinds λ> type T = ((->) :: * -> * -> *) λ> :i T type T = @{'GHC.Types.LiftedRep} -> @{'GHC.Types.LiftedRep} :: * -> * -> * }}} I'd expect {{{ type T = (->) @{'GHC.Types.LiftedRep} @{'GHC.Types.LiftedRep} :: * -> * -> * }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 20:16:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 20:16:26 -0000 Subject: [GHC] #15942: Type family used invisibly (with Visible Kind Applications) Message-ID: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> #15942: Type family used invisibly (with Visible Kind Applications) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to run the following past you (using [https://phabricator.haskell.org/D5229 Visible Kind Applications] but may be unrelated). The following compiles {{{#!hs {-# Language DataKinds #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language AllowAmbiguousTypes #-} import Data.Kind type Cat ob = Bool -> Type data Fun :: Cat Type class F (bool :: Bool) where type Not bool :: Bool foo :: Fun (Not bool) }}} but quantifying `Bool` invisibly all of a sudden I can't use `Not` {{{#!hs {-# Language DataKinds #-} {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language AllowAmbiguousTypes #-} import Data.Kind type Cat ob = forall (b :: Bool). Type data Fun :: Cat Type class F (bool :: Bool) where type Not bool :: Bool foo :: Fun @(Not bool) }}} {{{ $ ghc-stage2 --interactive -ignore-dot-ghci 739_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 739_bug.hs, interpreted ) 739_bug.hs:17:16: error: • Type constructor ‘Not’ cannot be used here (it is defined and used in the same recursive group) • In the first argument of ‘Fun’, namely ‘(Not bool)’ In the type signature: foo :: Fun @(Not bool) In the class declaration for ‘F’ | 17 | foo :: Fun @(Not bool) | ^^^ Failed, no modules loaded. }}} Is this restriction warranted -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 20:25:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 20:25:14 -0000 Subject: [GHC] #15942: Type family used invisibly (with Visible Kind Applications) In-Reply-To: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> References: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> Message-ID: <066.cefe3aabb66fc96e26852b13475747e6@haskell.org> #15942: Type family used invisibly (with Visible Kind Applications) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: > I want to run the following past you (using > [https://phabricator.haskell.org/D5229 Visible Kind Applications] but may > be unrelated). The following compiles > > {{{#!hs > {-# Language DataKinds #-} > {-# Language KindSignatures #-} > {-# Language TypeFamilies #-} > {-# Language AllowAmbiguousTypes #-} > > import Data.Kind > > type Cat ob = Bool -> Type > > data Fun :: Cat Type > > class F (bool :: Bool) where > type Not bool :: Bool > foo :: Fun (Not bool) > }}} > > but quantifying `Bool` invisibly all of a sudden I can't use `Not` > > {{{#!hs > {-# Language DataKinds #-} > {-# Language RankNTypes #-} > {-# Language TypeApplications #-} > {-# Language PolyKinds #-} > {-# Language KindSignatures #-} > {-# Language TypeFamilies #-} > {-# Language AllowAmbiguousTypes #-} > > import Data.Kind > > type Cat ob = forall (b :: Bool). Type > > data Fun :: Cat Type > > class F (bool :: Bool) where > type Not bool :: Bool > foo :: Fun @(Not bool) > }}} > > {{{ > $ ghc-stage2 --interactive -ignore-dot-ghci 739_bug.hs > GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( 739_bug.hs, interpreted ) > > 739_bug.hs:17:16: error: > • Type constructor ‘Not’ cannot be used here > (it is defined and used in the same recursive group) > • In the first argument of ‘Fun’, namely ‘(Not bool)’ > In the type signature: foo :: Fun @(Not bool) > In the class declaration for ‘F’ > | > 17 | foo :: Fun @(Not bool) > | ^^^ > Failed, no modules loaded. > }}} > > Is this restriction warranted New description: I want to run the following past you (using [https://phabricator.haskell.org/D5229 Visible Kind Applications] but may be unrelated). The following compiles {{{#!hs {-# Language DataKinds #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language AllowAmbiguousTypes #-} import Data.Kind type Cat = Bool -> Type data Fun :: Cat class F (bool :: Bool) where type Not bool :: Bool foo :: Fun (Not bool) }}} but quantifying `Bool` invisibly all of a sudden I can't use `Not` {{{#!hs {-# Language DataKinds #-} {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language AllowAmbiguousTypes #-} import Data.Kind type Cat = forall (b :: Bool). Type data Fun :: Cat class F (bool :: Bool) where type Not bool :: Bool foo :: Fun @(Not bool) }}} {{{ $ ghc-stage2 --interactive -ignore-dot-ghci 739_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 739_bug.hs, interpreted ) 739_bug.hs:17:16: error: • Type constructor ‘Not’ cannot be used here (it is defined and used in the same recursive group) • In the first argument of ‘Fun’, namely ‘(Not bool)’ In the type signature: foo :: Fun @(Not bool) In the class declaration for ‘F’ | 17 | foo :: Fun @(Not bool) | ^^^ Failed, no modules loaded. }}} Is this restriction warranted -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 20:25:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 20:25:55 -0000 Subject: [GHC] #15942: Type family used invisibly (with Visible Kind Applications) In-Reply-To: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> References: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> Message-ID: <066.fca30a0db1aff491e955c292c6832352@haskell.org> #15942: Type family used invisibly (with Visible Kind Applications) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: > I want to run the following past you (using > [https://phabricator.haskell.org/D5229 Visible Kind Applications] but may > be unrelated). The following compiles > > {{{#!hs > {-# Language DataKinds #-} > {-# Language KindSignatures #-} > {-# Language TypeFamilies #-} > {-# Language AllowAmbiguousTypes #-} > > import Data.Kind > > type Cat = Bool -> Type > > data Fun :: Cat > > class F (bool :: Bool) where > type Not bool :: Bool > foo :: Fun (Not bool) > }}} > > but quantifying `Bool` invisibly all of a sudden I can't use `Not` > > {{{#!hs > {-# Language DataKinds #-} > {-# Language RankNTypes #-} > {-# Language TypeApplications #-} > {-# Language PolyKinds #-} > {-# Language KindSignatures #-} > {-# Language TypeFamilies #-} > {-# Language AllowAmbiguousTypes #-} > > import Data.Kind > > type Cat = forall (b :: Bool). Type > > data Fun :: Cat > > class F (bool :: Bool) where > type Not bool :: Bool > foo :: Fun @(Not bool) > }}} > > {{{ > $ ghc-stage2 --interactive -ignore-dot-ghci 739_bug.hs > GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( 739_bug.hs, interpreted ) > > 739_bug.hs:17:16: error: > • Type constructor ‘Not’ cannot be used here > (it is defined and used in the same recursive group) > • In the first argument of ‘Fun’, namely ‘(Not bool)’ > In the type signature: foo :: Fun @(Not bool) > In the class declaration for ‘F’ > | > 17 | foo :: Fun @(Not bool) > | ^^^ > Failed, no modules loaded. > }}} > > Is this restriction warranted New description: I want to run the following past you (using [https://phabricator.haskell.org/D5229 Visible Kind Applications] but may be unrelated). The following compiles {{{#!hs {-# Language DataKinds #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language AllowAmbiguousTypes #-} import Data.Kind type G = Bool -> Type data Fun :: G class F (bool :: Bool) where type Not bool :: Bool foo :: Fun (Not bool) }}} but quantifying `Bool` invisibly all of a sudden I can't use `Not` {{{#!hs {-# Language DataKinds #-} {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language AllowAmbiguousTypes #-} import Data.Kind type G = forall (b :: Bool). Type data Fun :: G class F (bool :: Bool) where type Not bool :: Bool foo :: Fun @(Not bool) }}} {{{ $ ghc-stage2 --interactive -ignore-dot-ghci 739_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 739_bug.hs, interpreted ) 739_bug.hs:17:16: error: • Type constructor ‘Not’ cannot be used here (it is defined and used in the same recursive group) • In the first argument of ‘Fun’, namely ‘(Not bool)’ In the type signature: foo :: Fun @(Not bool) In the class declaration for ‘F’ | 17 | foo :: Fun @(Not bool) | ^^^ Failed, no modules loaded. }}} Is this restriction warranted -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 20:32:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 20:32:44 -0000 Subject: [GHC] #15936: Rethink Choice of Baseline Commit for Performance Tests In-Reply-To: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> References: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> Message-ID: <060.5b95bf39fb7f64c716bae756d8d16f0b@haskell.org> #15936: Rethink Choice of Baseline Commit for Performance Tests -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git 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: | -------------------------------------+------------------------------------- Description changed by davide: Old description: > = Intro = > > Currently we always use the previous commit when running performance > tests. This works well in CI where we fully test each commit in sequence > (and hence always have test results for the previous commit). Remember, > test results are stored in git notes and are not by default shared > between repositories (i.e. your local repo will only have performance > results run locally on your machine). This is by design: we want to avoid > comparing results form different machines. > > Unfortunately This is not so effective when testing locally. The > programmer may have only run a subset of performance tests on the > previous commit, and often have not run the tests at all (this is notably > true after performing a rebase: the previous commit has changed). We need > to rethink how we pick a baseline commit. > > = Goals = > > * In all cases, do something sensible. > * Giving a warning if conditions are not idea. Provide clear and simple > instructions on how to get to the ideal case. > * Give control over the baseline commit to the programmer via command > line options. > * Could make it a baseline branch where we still do git merge-base. > That would be useful if you are branching from a different branch than > master. > * Give control over the baseline of local or ci to the programmer via > command line options. > * In general, performance tests should just work! No extra knowledge > needed by the programmer. > * If tests pass without warning now, then they should pass without > warning later. > > = Proposed Solution = > > * When running performance tests, results will be compared to a baseline > commit that is the merge base with master (most recent commit from > master). If HEAD is already in master, then the previous commit is used > instead. > * If any locally generated performance results exist, they are used > exclusively for the baseline. > * Else if any CI generated performance results exist (and have been > fetched), they are used exclusively for the baseline. > * Else performance tests trivially pass, and a warning is given to the > user. > > To find the baseline commit: > {{{ > mergeBase = merge-base master HEAD > baselineCommit = if mergeBase == HEAD > then HEAD^ > else mergeBase > }}} > > == Reasoning == > > * We want each commit in master not to introduce a significant change in > performance: hence we compare commits in mater to the previous commit. > * If not on master (1 or more ahead and 0 or more commits behind master). > We assume that the intention is to create a patch where all new commits > will ultimately be squashed and placed on top of master as a single > commit. On the other hand we don't want to consider changes in master > from after we branched. Instead of using master HEAD as the baseline, we > use the commit from which we branched from master (i.e. the merge base). > In other words we are concerned only with the change in performance > introduced by the newly crated commits. > > = Handling Expected changes = > > See > [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests#ExpectedPerformanceChanges > expected performance changes]. > > If on master or an ancestor commit, the baseline is the previous commit > and we can simply allow performance changes as specified in the current > commit's message (this is already the behaviour of the test driver). > > If we have branched from master, then we may have multiple commits from > the baseline commit to HEAD, each of which may have, possibly > contradictory, expected performance changes. If any expected changes > exist, aggregate them. We introduce an explicit "Metric Unchanged" option > and aggregate per test taking the newest commit. "Metric Unchanged" is > necessary in the case that a new commit undoes a performance change such > that a metric returns to the baseline value. The aggregate version should > be output so that the programmer knows what to put in the commit message > after squashing the commits. > > == Reasoning == > > creating new commits with expected changes is an interactive process. The > programmer adds a 1 or more commits, runs the tests, then adds expected > performance changes to a commit message. It would be too inconvenient to > force the programmer to change old commit messages, and too > verbose/annoying to have them enter a full list of expected changes in > each commit. Hence we must aggregate the expected changes. > > This is of a bit risky as it is a context sensitive change in the > semantics of expected changes. If we e.g. intend not to squash the > commits, then all the sudden the expected changes mean something very > different (change to the previous commit, not some distant baseline > commit). Perhaps we just show a warning in this case. > > We must figure out what commit messages will be used in GitLab on merge. > Does the programmer have to remember to sort out expected changes before > merge some how? > > = Use cases = > > * We do not distinguish between full/partial performance results being > available for the baseline commit: that would require checking out the > baseline commit and extracting the full list of tests. > * > > == Locally validate a commit from master == > > {{{ > git checkout master~5 > ./validate > }}} > > Baseline Commit: HEAD^ == master~6 > > || BaselinelocalResults || BaselineCIResults || Infos || Warnings || > > ||||= Case =||||||= Behaviour =|| > ||= Baseline local Results? =||= Baseline CI Results? =||= Baseline > local/CI =||= Infos =||= Warnings =|| > || Yes/Partial || - || Local || If HEAD tests is not subset or eq to > Baseline tests: "If relevant tests exist on baseline, checkout baseline > and running those tests OR fetch notes and use --baseline-ci || Warnings > || > || No || Yes || CI || "Using CI numbers, suggest running locally for more > accurate results" || Warnings || > || No || No || - || || "No baseline results, tests trivially pass" + > suggest fetch notes or locally run tests on baseline || > > == Locally validate a commit from master == > > {{{ > git checkout master~5 > ./validate > }}} > > Baseline Commit: HEAD^ == master~6 > > || BaselinelocalResults || BaselineCIResults || Infos || Warnings || > > ||||= Case =||||||= Behaviour =|| > ||= Baseline local Results? =||= Baseline CI Results? =||= Baseline > local/CI =||= Infos =||= Warnings =|| > || Yes/Partial || - || Local || If HEAD tests is not subset or eq to > Baseline tests: "If relevant tests exist on baseline, checkout baseline > and running those tests OR fetch notes and use --baseline-ci || Warnings > || > || No || Yes || CI || "Using CI numbers, suggest running locally for more > accurate results" || Warnings || > || No || No || - || || "No baseline results, tests trivially pass" + > suggest fetch notes or locally run tests on baseline || > > = From the perspective of the CI = > > ?? From CI, "local" is actually "CI". SO replace "is CI results > available" with "no" and replace "Is local results available" with "is CI > results available" > > = When to automatically fetch CI results? = > > If baseline commit doesn't have local nor CI results, and is old enough > such that we expect CI to have been run (WARNING we would need to know > the merge time, not the time that the commit was created, which could be > long before it was merged? Or will GitLab bump the commit time on merge?) New description: = Intro = Currently we always use the previous commit when running performance tests. This works well in CI where we fully test each commit in sequence (and hence always have test results for the previous commit). Remember, test results are stored in git notes and are not by default shared between repositories (i.e. your local repo will only have performance results when they were run locally on your machine). This is by design: we want to avoid comparing results form different machines. Unfortunately This is not so effective when testing locally. The programmer may have only run a subset of performance tests on the previous commit, and often have not run the tests at all (this is notably true after performing a rebase: the previous commit has changed). We need to rethink how we pick a baseline commit. = Goals = * In all cases, do something sensible. * Giving a warning if conditions are not idea. Provide clear and simple instructions on how to get to the ideal case. * Give control over the baseline commit to the programmer via command line options. * Could make it a baseline branch where we still do git merge-base. That would be useful if you are branching from a different branch than master. * Give control over the baseline of local or ci to the programmer via command line options. * In general, performance tests should just work! No extra knowledge needed by the programmer. * If tests pass without warning now, then they should pass without warning later. = Proposed Solution = * When running performance tests, results will be compared to a baseline commit that is the merge base with master (most recent commit from master). If HEAD is already in master, then the previous commit is used instead. * If any locally generated performance results exist, they are used exclusively for the baseline. * Else if any CI generated performance results exist (and have been fetched), they are used exclusively for the baseline. * Else performance tests trivially pass, and a warning is given to the user. To find the baseline commit: {{{ mergeBase = merge-base master HEAD baselineCommit = if mergeBase == HEAD then HEAD^ else mergeBase }}} == Reasoning == * We want each commit in master not to introduce a significant change in performance: hence we compare commits in mater to the previous commit. * If not on master (1 or more ahead and 0 or more commits behind master). We assume that the intention is to create a patch where all new commits will ultimately be squashed and placed on top of master as a single commit. On the other hand we don't want to consider changes in master from after we branched. Instead of using master HEAD as the baseline, we use the commit from which we branched from master (i.e. the merge base). In other words we are concerned only with the change in performance introduced by the newly crated commits. = Handling Expected changes = TODO this is the complicated part. What happens when the programmer is not planning on squashing commits and has many commits with expected changes :-( See [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests#ExpectedPerformanceChanges expected performance changes]. If on master or an ancestor commit, the baseline is the previous commit and we can simply allow performance changes as specified in the current commit's message (this is already the behaviour of the test driver). If we have branched from master, then we may have multiple commits from the baseline commit to HEAD, each of which may have, possibly contradictory, expected performance changes. If any expected changes exist, aggregate them. We introduce an explicit "Metric Unchanged" option and aggregate per test where newer allowed changes overwrite older allowed changes. "Metric Unchanged" is necessary in the case that a new commit undoes a performance change such that a metric returns to the baseline value. The aggregate version should be output so that the programmer knows what to put in the commit message after squashing the commits. A warning should be given if expected changes appear in any commit inbetween HEAD and the baseline commit. In that warning Suggest e.g. "--baseline HEAD^ if not planning on squashing this commit" == Reasoning == creating new commits with expected changes is an interactive process. The programmer adds a 1 or more commits, runs the tests, then adds expected performance changes to a commit message. It would be too inconvenient to force the programmer to change old commit messages, and too verbose/annoying to have them enter a full list of expected changes in each commit. Hence we must aggregate the expected changes. This is of a bit risky as it is a context sensitive change in the semantics of expected changes. If we e.g. intend not to squash the commits, then all the sudden the expected changes mean something very different (change to the previous commit, not some distant baseline commit). Perhaps we just show a warning in this case. We must figure out what commit messages will be used in GitLab on merge. Does the programmer have to remember to sort out expected changes before merge some how? = Use cases = * We do not distinguish between full/partial performance results being available for the baseline commit: that would require checking out the baseline commit and extracting the full list of tests. * || BaselinelocalResults || BaselineCIResults || Infos || Warnings || ||||||= Case =||||||= Behaviour =|| ||= Platform =||= Baseline local Results? =||= Baseline CI Results? =||= Baseline local/CI =||= Infos =||= Warnings =|| || Local || Yes/Partial || - || Local || If HEAD tests is not subset or eq to Baseline tests: "If relevant tests exist on baseline, checkout baseline and running those tests OR fetch notes and use --baseline-ci || || || Local || No || Yes || CI || "Using CI numbers, suggest running locally for more accurate results" || || || Local || No || No || - || || "No baseline results, tests trivially pass" + suggest fetch notes or locally run tests on baseline || || CI |||| Yes || CI || || || || CI |||| No || - || || "No results. CI is not yet finished, or CI has failed for the baseline commit or CI hasn’t fetched" || = When to automatically fetch CI results? = Fetch if: * Testing locally (not a ci run) AND * Baseline commit doesn't have local nor CI results (before fetch) AND * Baseline commit is an ancestor of master. If fetching, suggest a command line option: --no-fetch. This is most convenient for local testing avoids fetch on ci, but may result in unwanted/wasted fetches -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 21:08:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 21:08:17 -0000 Subject: [GHC] #15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered In-Reply-To: <045.3f184822d5d026ff6ca31854ce0f9e7a@haskell.org> References: <045.3f184822d5d026ff6ca31854ce0f9e7a@haskell.org> Message-ID: <060.60f0f37782af1e7f561916cd0250413e@haskell.org> #15932: DeriveFunctor and GeneralizedNewtypeDeriving instances never reporting as covered -------------------------------------+------------------------------------- Reporter: davean | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.3 Component: Code Coverage | Version: 8.6.2 Resolution: | Keywords: newcomer 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): * keywords: => newcomer Comment: I suspect this wouldn't be too hard to fix. The relevant implementation bits can be found in `deSugar/Coverage.hs`; I would start by looking at the `-ddump-ds` output to verify that there are no coverage ticks in the derived instances. If this really is the issue then I suspect a solution should be straightforward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 21:31:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 21:31:16 -0000 Subject: [GHC] #15943: "ASSERT failed" with quantified constraints Message-ID: <051.f4e585065410b8c1f622561bba68547c@haskell.org> #15943: "ASSERT failed" with quantified constraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes #-} {-# Language DataKinds #-} {-# Language KindSignatures #-} {-# Language PolyKinds #-} {-# Language TypeFamilyDependencies #-} {-# Language GADTs #-} {-# Language TypeSynonymInstances #-} {-# Language FlexibleInstances #-} {-# Language QuantifiedConstraints #-} import Data.Type.Equality import Data.Coerce import Data.Type.Coercion import Data.Kind newtype WrapFalse a b = WrapFalse (Hom False a b) newtype WrapTrue a b = WrapTrue (Hom True a b) class (forall (x :: ob) (y :: ob). Coercible (WrapFalse x y) (WrapTrue y x)) => Ríki ob where type Hom (or::Bool) = (res :: ob -> ob -> Type) | res -> or instance Ríki Type where type Hom False = (->) type Hom True = Op newtype Op :: Type -> Type -> Type where Op :: (b -> a) -> Op a b }}} {{{ $ ghc-stage2 --interactive -ignore-dot-ghci 740_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 740_bug.hs, interpreted ) *** Exception: ASSERT failed! file compiler/typecheck/TcFlatten.hs, line 1288 > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 21:43:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 21:43:47 -0000 Subject: [GHC] #15943: "ASSERT failed" with quantified constraints In-Reply-To: <051.f4e585065410b8c1f622561bba68547c@haskell.org> References: <051.f4e585065410b8c1f622561bba68547c@haskell.org> Message-ID: <066.6ce30e89dec99579419bbefdc8404afd@haskell.org> #15943: "ASSERT failed" with quantified constraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): It works if we replace `(->)` with the representationally equal `Fun` {{{#!hs newtype Fun a b = Fun (a -> b) instance Ríki Type where type Hom False = Fun type Hom True = Op }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 21:49:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 21:49:20 -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.7fe63d4149b94e07d5aeece84c74e3fd@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 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): This is tricky in an interesting way. What is the problem with quantified constraints with a type-function in the head? Consider {{{ f :: (forall a. C a => C (F a)) => ... }}} where `F` is a type family. We really, really can't handle this. Suppose we have {{{ type instance F [b] = (b,b) }}} and we are trying to solve `C (t,t)` in `f`'s RHS. Well that's the same as `C (F [t])` and lo, now the quantified constraint matches. It would be utterly different if we had {{{ f :: C (F a) => ... f = ...needs (C (F a))... }}} where the two constraints are patently equal; and it'd be equally fine if we had an enclosing constraint (from a GADT, say) telling us `a ~ [b]`. Then we'd rewrite both the "given" and the "wanted" to `C (F [b])`, and if that in turn rewrites to `C (b,b)` then both will so rewrite. It's all fine. The trouble in the earlier example comes because `F` is applied to a quantified variable. Here's another example it is, by comparison, fine: {{{ type family F2 a :: * -> * f2 :: (forall b. C b => C (F2 x b)) => blah }}} Notice that `F2` has arity 1. And notice that the saturated application `(F2 x)` does not mention the quantified variable `b`. So we could rewrite the signature thus: {{{ f2a :: (y ~ F2 x, forall b. C b => C (y b)) => blah }}} This is fine, and it is accepted today. By binding `F2 x` to `y` ''outside'' the quantification we have shown that the problems described above (about F) can't happen. Alas, `f2` is ''not'' accepted today. Until today I thought that once could always rewrite in the `f2a` style, and that it would be positively good to do so. That's what comment:1 says. But today you have shown me a counter example. I cannot apply that trick to {{{ class (forall b. Show b => Show (T a b)) => C a where type family T a :: * -> * }}} I might try {{{ class (y ~ T a, forall b. Show b => Show (y b)) => C a where type family T a :: * -> * }}} But now `y` is not bound in the class head, and we just don't allow that. (Why not? Because a class turns into a data type declaration {{{ data C a = MkC (..superclass1..) (..superclass2..) etc (..method1..) (..method2..) etc }}} so the superclass types can't mention variables not bound on the left. No we do not want existentials here.) So I am driven to the conclusion: * Perhaps we should allow type-family applications in the head of a quantified constraint, provided that the saturated application of the family does not mention any of the quantified variables. The flattener would have to work a bit harder. Richard, what do you think? Thanks for the example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 21:52:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 21:52:52 -0000 Subject: [GHC] #15943: "ASSERT failed" with quantified constraints In-Reply-To: <051.f4e585065410b8c1f622561bba68547c@haskell.org> References: <051.f4e585065410b8c1f622561bba68547c@haskell.org> Message-ID: <066.32693e9e853f7f820481ca805cec6a5f@haskell.org> #15943: "ASSERT failed" with quantified constraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Seems ok with HEAD, happily. Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 22:04:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 22:04:21 -0000 Subject: [GHC] #15928: Reduction stack overflow when using "coerce" In-Reply-To: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> References: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> Message-ID: <062.5c44366de01d2f5776567013f02d44ba@haskell.org> #15928: Reduction stack overflow when using "coerce" -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Actually the error message is quite informative, isn't it? It says that GHC is trying to solve {{{ Coercible ((Stream Identity a -> Identity r) -> Identity r) ((Stream Identity a0 -> Identity r) -> Identity r) }}} Well the `->` and `Identity` parts are easy. That leaves us with proving {{{ Coercible (Stream Identity a) (Stream Identity a0) }}} How can we do that? Aha! Unwrap the newtype (on both sides). That givs us {{{ Coercible (forall r. (Stream Identity a -> Identity r) -> Identity r) (forall r. (Stream Identity a0 -> Identity r) -> Identity r) }}} How can we prove that? Well, we can dive under the `forall` to give {{{ Coercible ((Stream Identity a -> Identity r) -> Identity r) ((Stream Identity a0 -> Identity r) -> Identity r) }}} And now we are back where we began. This known incompleteness is described in Section 5.3.1 of [https://www.microsoft.com/en- us/research/publication/safe-zero-cost-coercions-haskell/ Safe zero-cost coercions in Haskell]. I don't know how to solve it; the reduction-stack bound gives a decent diagnosis. I grant that what seems decent to me may seem very different to a Haskell programmer. But I don't yet know how to do better. Does the explanation help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 22:31:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 22:31:07 -0000 Subject: [GHC] #15874: Data families with higher-rank kinds In-Reply-To: <051.72eddd9af5815eb989f802af554eb1bb@haskell.org> References: <051.72eddd9af5815eb989f802af554eb1bb@haskell.org> Message-ID: <066.05d088eba39e34b98061865c36c8eaee@haskell.org> #15874: Data families with higher-rank kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 simonpj): I think this is a dup of #15817, comment:1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 22:31:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 22:31:27 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315817=3A_Data_family_quantification?= =?utf-8?b?ID0gR0hDIHBhbmljLCDigJhpbXBvc3NpYmxl4oCZIGhhcHBlbmVk?= In-Reply-To: <051.141a919b387f59325ecc3d36f5a6a348@haskell.org> References: <051.141a919b387f59325ecc3d36f5a6a348@haskell.org> Message-ID: <066.d5cf0ab1b3151a45d7444d24fd5eeb8d@haskell.org> #15817: Data family quantification = GHC panic, ‘impossible’ happened -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): #15874 is another example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 23 23:25:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Nov 2018 23:25:02 -0000 Subject: [GHC] #15944: Wrong warning given ViewPatterns and -Wmonomorphism-restriction Message-ID: <044.1a3ca587dd0aadea754e1c32d7fa2d69@haskell.org> #15944: Wrong warning given ViewPatterns and -Wmonomorphism-restriction -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 understand ghc complaining about `b`, but not about `a`. No warnings when view patterns are not used. {{{#!hs {-# LANGUAGE ViewPatterns #-} {-# OPTIONS -Wmonomorphism-restriction #-} module Foo where {- demo.hs:11:9: warning: [-Wmonomorphism-restriction] • The Monomorphism Restriction applies to the bindings for ‘a’, ‘b’ Consider giving them a type signature • In the expression: let Foo a (round -> b) = f in a + b In an equation for ‘bar’: bar f = let Foo a (round -> b) = f in a + b | 11 | let Foo a (round -> b) = f | ^^^^^^^^^^^^^^^^^^^^^^ -} data Foo = Foo Int Double bar :: Foo -> Int bar f = let Foo a (round -> b) = f in a + b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 02:44:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 02:44:19 -0000 Subject: [GHC] #15928: Reduction stack overflow when using "coerce" In-Reply-To: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> References: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> Message-ID: <062.24b692bedb6811e9393ff04a13dba667@haskell.org> #15928: Reduction stack overflow when using "coerce" -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): I think GHC needs to move on from "by GHC developers for GHC developers" to "by GHC developers for mortal Haskell programmers". You have a lot more context here than a Haskell programmer at large would have. The error needs to be resolved quickly, in a few seconds or perhaps minutes would be fine too. The error message and the documentation does not serve that purpose, it (Data.Coerce) refers to the paper and the roles wiki page (referring to papers is common theme for GHC and Haskell libraries), the paper is accessible to only a very small population, and we should not expect a large population of programmers to go read the paper and spend hours or even days or weeks trying to understand it and having to learning a lot of other things in the process. For that one error message, which can be explained better in just a few more words, it becomes a big digression. I am sorry about that rant, GHC devs are doing a terrific job, it is a wonderful technology but it has a potential to become much more usable by a lot more ordinary programmers like me if the error messages and the documentation become a little better. Keeping that aside, I still have a few questions about the issue at hand, I suspect there is a bug here: 1) Why a and a0 are treated as different types in the first version of the code? If a ~ a0 then there won't be a loop. In fact, this code is coercing a type into itself, which should be trivial. In the second version of the code where it works, the two types have been explicitly forced to be the same via a type signature. 2) This code works fine if the "Stream" type is defined using "data" instead of a "newtype". It puzzles me, why in that case we are not going into a loop? Why in that case the types a and a0 are the same? About the error message, I think it can be improved. First of all, a regular programmer won't have any idea what a "reduction stack" is, they can just guess, it is possibly a GHC internal thing. The error message is for GHC developers, not for users. The flag "-freduction-depth" is only mentioned in "Undecidable Instances section" of the guide, nowhere else. If the programmer is supposed to know about the reduction stack then it should be documented and the concept should be explained. But I guess we can do better even without doing that. The error message can perhaps be phrased something like this, it might be inaccurate, but just to give an idea: {{{ When trying to determine that the representation of type x is the same as that of type y, we expanded the types n times but still could not determine that they are equal, we can go on but we are limited by the reduction stack size which can be changed by using the -freduction-depth option. In some cases where the types are recursively defined, it is possible that the expansion forms an infinite loop that never terminates. For more details and examples see this manual page. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 03:29:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 03:29:19 -0000 Subject: [GHC] #15927: Weird interaction between fundeps and overlappable instances In-Reply-To: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> References: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> Message-ID: <063.cce0ecb7ca25ca05408169b2f96a8cb2@haskell.org> #15927: Weird interaction between fundeps and overlappable instances -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 15632 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): You've clearly unearthed an(other) example of GHC's bogusness with FunDeps+Overlaps. Without wanting to take anything away from that ... Replying to [comment:4 AntC]: > >> behavior ... seems pretty useful in some situations > > ... can you refactor your code? The code as currently is fragile and non-scalable. It relies on the payload content of the `StateT`s having distinct types. You can do this {{{#!hs f :: (MyState Int m, MyState Char m, MyState String m, MonadIO m) => m () -- believe 3 impossible things before breakfast f = do int <- getMyState char <- getMyState str <- getMyState liftIO $ putStrLn ((replicate int char) ++ str) }}} * But it doesn't work if `f` wants two values of the same type. (`getMyState` will always get the first-bound.) `... liftIO $ putStrLn (str1 ++ str2)` I suggest you want either * depth-based access: `getMyState` has an extra parameter for the depth. Or it very cleverly takes the content from this layer and unwraps one layer of State for the next call. Now you need a PolyMonad; or * type-indexed access: wrap each layer's content in a newtype. Make sure they're distinct types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 08:13:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 08:13:54 -0000 Subject: [GHC] #15927: Weird interaction between fundeps and overlappable instances In-Reply-To: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> References: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> Message-ID: <063.65fc67e3481b651a9de24cf17a971b70@haskell.org> #15927: Weird interaction between fundeps and overlappable instances -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 15632 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Darwin226): Well, since the mtl default is to no only disallow multiple states of the same type, but multiple states of ANY type, I wouldn't really call this non-scaleable. It's strictly more flexible than mtl. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 09:30:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 09:30:23 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.be075a60e661377e4e10b57349adb6fb@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): FreeBSD uses ELF so you could just try to add it to the `#ifdef` guards and see how far you get. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 10:05:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 10:05:01 -0000 Subject: [GHC] #15941: Pretty-printing of invisible arguments to (->) In-Reply-To: <047.398646946505bae0b9a71adeab6b5eee@haskell.org> References: <047.398646946505bae0b9a71adeab6b5eee@haskell.org> Message-ID: <062.472d02f3c90e8ce454c293f7716ad9c1@haskell.org> #15941: Pretty-printing of invisible arguments to (->) -------------------------------------+------------------------------------- Reporter: monoidal | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => RyanGlScott * version: 8.6.2 => 8.7 * milestone: 8.6.3 => 8.8.1 Comment: Oops! This one is almost guaranteed to be my fault. I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 10:15:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 10:15:50 -0000 Subject: [GHC] #15942: Type family used invisibly (with Visible Kind Applications) In-Reply-To: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> References: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> Message-ID: <066.2e477b1ae82dd9cf7d9081f3d2e2df63@haskell.org> #15942: Type family used invisibly (with Visible Kind Applications) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't think this has anything to do with VKA. The distinction that GHC appears to be making is whether `Not` is used in a kind position (as opposed to a type position) within `F`. Note that the following is also rejected: {{{#!hs {-# Language DataKinds #-} {-# Language KindSignatures #-} {-# Language PolyKinds #-} {-# Language TypeFamilies #-} {-# Language AllowAmbiguousTypes #-} import Data.Kind import Data.Proxy type G = Bool -> Type data Fun :: G class F (bool :: Bool) where type Not bool :: Bool foo :: Proxy (x :: Proxy (Not bool)) }}} {{{ $ ~/Software/haskell/ghc-8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:16:29: error: • Type constructor ‘Not’ cannot be used here (it is defined and used in the same recursive group) • In the first argument of ‘Proxy’, namely ‘(Not bool)’ In the kind ‘Proxy (Not bool)’ In the first argument of ‘Proxy’, namely ‘(x :: Proxy (Not bool))’ | 16 | foo :: Proxy (x :: Proxy (Not bool)) | ^^^ }}} As for whether this restriction is warranted in the first place, I don't know if I'm qualified to say. I do know that there are other tickets that aim to relax this restriction under certain scenarios: see #11962 and #12612. It's unclear to me whether this ticket is covered by one of those tickets already, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 10:30:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 10:30:40 -0000 Subject: [GHC] #15495: Handling Source Locations via TTG In-Reply-To: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> References: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> Message-ID: <065.fed98843bea9293189355ef2d73ba3a5@haskell.org> #15495: Handling Source Locations via TTG -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new 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:D5036 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"509d5be69c7507ba5d0a5f39ffd1613a59e73eea/ghc" 509d5be6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="509d5be69c7507ba5d0a5f39ffd1613a59e73eea" [TTG: Handling Source Locations] Foundation and Pat This patch removes the ping-pong style from HsPat (only, for now), using the plan laid out at https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations (solution A). - the class `HasSrcSpan`, and its functions (e.g., `cL` and `dL`), are introduced - some instances of `HasSrcSpan` are introduced - some constructors `L` are replaced with `cL` - some patterns `L` are replaced with `dL->L` view pattern - some type annotation are necessarily updated (e.g., `Pat p` --> `Pat (GhcPass p)`) Phab diff: D5036 Trac Issues #15495 Updates haddock submodule }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 10:42:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 10:42:05 -0000 Subject: [GHC] #15941: Pretty-printing of invisible arguments to (->) In-Reply-To: <047.398646946505bae0b9a71adeab6b5eee@haskell.org> References: <047.398646946505bae0b9a71adeab6b5eee@haskell.org> Message-ID: <062.b5a76595905f5a06f12e63f8e39e3340@haskell.org> #15941: Pretty-printing of invisible arguments to (->) -------------------------------------+------------------------------------- Reporter: monoidal | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 RyanGlScott): * version: 8.7 => 8.6.2 Comment: I set the version of this ticket to 8.7, mistakenly thinking that this was a regression introduced in commit f5d2083807a03c57f194fcc3a7baf82e34aad524. But as it turns out, this bug has been lurking even before that! In GHC 8.6.2, you get this: {{{ > :i T type T = 'GHC.Types.LiftedRep -> 'GHC.Types.LiftedRep :: * -> * -> * -- Defined at :3:1 }}} Another observation: this is not unique to `(->)` (which is what I originally thought, since there are many special cases for function arrows throughout the codebase). Any infix type constructor with two invisible arguments will do, as the following GHCi session shows: {{{ > import GHC.Generics > type T2 = (:.:) > :i T2 type T2 = * :.: * :: (* -> *) -> (* -> *) -> * -> * -- Defined at :11:1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 11:13:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 11:13:54 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.5dc580809bad1c253c44a03d53d8594c@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I should also mention that there is actually a feasible workaround to the problem in comment:3: just use `ImpredicativeTypes`! That is to say, the following works: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} module Foo where import Data.Kind data A :: Type -> Type data B a :: A a -> Type type C = B }}} Until someone fixes this bug, I can profitably use this workaround in `singletons`, where the inability to define something like `C` was particularly irksome: https://github.com/goldfirere/singletons/pull/373 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 12:47:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 12:47:47 -0000 Subject: [GHC] #15941: Pretty-printing of invisible arguments to (->) In-Reply-To: <047.398646946505bae0b9a71adeab6b5eee@haskell.org> References: <047.398646946505bae0b9a71adeab6b5eee@haskell.org> Message-ID: <062.64e60a426cf68bcbfe0328a65940be84@haskell.org> #15941: Pretty-printing of invisible arguments to (->) -------------------------------------+------------------------------------- Reporter: monoidal | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5375 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5375 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 13:39:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 13:39:30 -0000 Subject: [GHC] #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o In-Reply-To: <050.a3b7fabd1dfe8f036f7828f2ade0cf8e@haskell.org> References: <050.a3b7fabd1dfe8f036f7828f2ade0cf8e@haskell.org> Message-ID: <065.40297267523aefa6780d92086a851325@haskell.org> #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o -------------------------------------+------------------------------------- Reporter: dramforever | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 18:13:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 18:13:40 -0000 Subject: [GHC] #15942: Type family used invisibly (with Visible Kind Applications) In-Reply-To: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> References: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> Message-ID: <066.d5c49b534b25c79f4b08408ee7a4c6cd@haskell.org> #15942: Type family used invisibly (with Visible Kind Applications) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think this is independent from #12612, though a full fix for #11962 should almost certainly fix both #12612 and this ticket. That said, #11962 is a Major Engineering Project (Google Summer of Code, anyone?) and it's likely a fine idea to take slices off that pie like this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 18:40:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 18:40:32 -0000 Subject: [GHC] #15928: Reduction stack overflow when using "coerce" In-Reply-To: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> References: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> Message-ID: <062.5909a0626d151a0366b0d04437f6a37b@haskell.org> #15928: Reduction stack overflow when using "coerce" -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 harendra]: > I think GHC needs to move on from "by GHC developers for GHC developers" to "by GHC developers for mortal Haskell programmers". ... I agree that we do a poor job of this. I think this needs to be more of a priority for us, which is why I recommended time spent on error messages in the recent survey put out about what to spend 6 months of developer time on. I think the only answer is to have interactive error messages, where an IDE and GHC work together to allow, e.g., a user to right-click on a term in an error message and get a definition, or can right-click on a constraint and get information about how GHC thought that the constraint should be solved. #8809 sets the stage for that future. Short of interactivity, I really don't think we can do better with an error message such as this one. The message says "stack overflow", which a functional programmer can understand as a process than never appears to be ending. It then shows what it's stuck on. Of course, GHC ''could'' show the whole cycle as Simon did above, but then the error message would get very long, which would then lead to complaints about long error messages... which is why I want interactive error messages, so everyone gets the length they want. As for references to papers: better, more accessible documentation would be fantastic. Would you (for any value of "you") care to write some? That, too, is a hard and time-consuming task. > > 1) Why a and a0 are treated as different types in the first version of the code? If a ~ a0 then there won't be a loop. In fact, this code is coercing a type into itself, which should be trivial. `a` there is the type variable used in the input, as given in the type signature for `f`. GHC must figure out, though, what the type variable should be in the argument to `idSerial` (which is the same as the type variable in the argument to `g`, as we learn from `idSerial`'s type signature). GHC calls this `a0`. There's no reason for GHC to assume that `a` and `a0` should be the same, so it doesn't... and this is the crux of the problem. > > 2) This code works fine if the "Stream" type is defined using "data" instead of a "newtype". Yes. That's because the loop is induced by the way that GHC "unwraps" newtypes in trying to find coercions between types. If you use `data`, this unwrapping doesn't happen. > About the error message, I think it can be improved. These are great, concrete suggestions. Thank you! I agree with Simon that accepting the original program would be quite hard (and would require fresh computer science research), but rephrasing an error message is very doable. I propose we make this ticket about rewriting this error message, incorporating your suggestions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 19:07:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 19:07:55 -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.9d84c3cbb95c89dcdddab4a7b00cc1a2@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 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 agree with comment:19. Depending on how you read it, the rule is this: * You cannot mention locally quantified variables in the arguments to a type family. where "locally quantified" is meant to refer to the quantification in a quantified constraint. My "depending on how you read it" is about the fact that `b` isn't really an argument to type family `T` in `T a b`. Instead, `a` is the only argument to `T`, and `b` is an argument to the reduct of `T a`. This is pedantic, but I think it's a healthy way to understand what's going on. I also want to back Simon up in his refusal to allow locally quantified variables in arguments to type families: the problem is all about backtracking. See my comment:6, which spells trouble. I don't think the more nuanced rule described in comment:19 and here will be hard to implement. The flattener already treats the `a` and `b` in `T a b` quite differently. See the difference between `flatten_fam_app` and `flatten_exact_fam_app_fully`. The former takes `T a b` and decomposes to pass only `T a` to the latter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 19:12:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 19:12:36 -0000 Subject: [GHC] #15810: Kind inference error in classes In-Reply-To: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> References: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> Message-ID: <062.e8a499ac2a9f976d26bc9a86c8685128@haskell.org> #15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): Phab:D5305 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Did you mean for the last example in comment:4 to be different than the first? I presume you did. We allow {{{#!hs data T a where MkT :: T (a :: k) }}} today. That `k` is also locally quantified. I can see the argument for rejecting the original program, but it's inconsistent to reject that while accepting the datatype equivalent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 19:33:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 19:33:13 -0000 Subject: [GHC] #15937: CI strategy for Gitlab In-Reply-To: <048.738065983349c6ff7ad5141b89ce5589@haskell.org> References: <048.738065983349c6ff7ad5141b89ce5589@haskell.org> Message-ID: <063.2f9dc30a054dd57966a408997592556a@haskell.org> #15937: CI strategy for Gitlab -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 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 goldfire): Thanks for the careful thought here. If I push to a fork and want CI on my fork, I don't mind a few extra clicks, etc., to get CI working. (E.g., I might need to make an account somewhere and link it somehow.) Would requiring contributors to take a few steps like this unlock a better approach? (Note: I really don't have any idea of what I'm talking about here, and it's not worth your time to offer a long explanation of why such a thing isn't possible. If this comment is not helpful, just say "no" and invest your time in building the solution you think is best.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 21:05:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 21:05:20 -0000 Subject: [GHC] #15810: Kind inference error in classes In-Reply-To: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> References: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> Message-ID: <062.0b3b0c6a2d1fa9a4cccba0af8aab7414@haskell.org> #15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): Phab:D5305 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Did you mean for the last example in comment:4 to be different than the first? Yes I did. Now fixed. Data type decls (in GADT style) are different to class decls. In a data type decl the type variables from the head do not scope over the individual data con signatures. So your example really reads {{{ data T a wher MkT :: forall k a. T (a :: k) }}} and the following would be equally acceptable {{{ data T a wher MkT :: T (b :: k) }}} But with classes the type variables from the class header do indeed scope over the method declarations. So they are already inconsistent in that sense. I still say "no bug here" :-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 21:23:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 21:23:35 -0000 Subject: [GHC] #15945: Unable to compile GHC from source on OpenBSD (-CURRENT) Message-ID: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> #15945: Unable to compile GHC from source on OpenBSD (-CURRENT) -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (make) | Keywords: clang | Operating System: OpenBSD Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am running the following script to build GHC from sources (ghc-8.6.2-src.tar.xz) on OpenBSD (-CURRENT): {{{ #! /bin/sh set -e BUILD_DIR=/usr/local/tmp-build-ghc export AUTOCONF_VERSION=2.69 export AUTOMAKE_VERSION=1.16 if [ ! -n "$1" ]; then echo "ERROR: Provide path for ghc source." exit 1 fi echo "Extracting ghc source files from ${1} to ${BUILD_DIR} ..." mkdir -p $BUILD_DIR cd $BUILD_DIR xzcat $1 | tar xvf - GHC_DIR=`ls | grep ghc` cd $GHC_DIR echo "Cleaning up OpenBSD-incompatible commands..." find . -type f | xargs sed -i -e 's|^ln -f -v |ln -f |' echo "Building GHC... " export CC=/usr/bin/clang ./boot ./configure --with-iconv-libraries=/usr/local/lib \ --with-iconv-includes=/usr/local/include \ --with-gmp-libraries=/usr/local/lib \ --with-gmp-includes=/usr/local/include \ --with-ffi-libraries=/usr/local/lib \ --with-ffi-includes=/usr/local/include \ --with-system-libffi gmake }}} I will file a separate bug report for the **ln** incompatibility with the unsupported **-v** flag. When compiling GHC, I get the following error: {{{ ... "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc- Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc- Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc- Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc- Iincludes/dist-derivedconstants/header -optc-Iincludes/dist- ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing -optc-fno-common -optc- Irts/dist/build/./autogen -optc-Wno-unknown-pragmas -optc-O2 -optc-fomit- frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-ffunction-sections -optc-fdata-sections -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/RtsSymbols.c -o rts/dist/build/RtsSymbols.o rts/RtsSymbols.c:990:1: error: error: redefinition of '_DYNAMIC' as different kind of symbol | 990 | RTS_OPENBSD_ONLY_SYMBOLS | ^ RTS_OPENBSD_ONLY_SYMBOLS ^ rts/RtsSymbols.c:283:22: error: note: expanded from macro 'RTS_OPENBSD_ONLY_SYMBOLS' SymE_NeedsProto(_DYNAMIC) ^ | 283 | SymE_NeedsProto(_DYNAMIC) | ^ /usr/include/sys/exec_elf.h:765:17: error: note: previous definition is here | 765 | extern Elf_Dyn _DYNAMIC[]; | ^ extern Elf_Dyn _DYNAMIC[]; ^ 1 error generated. `clang' failed in phase `C Compiler'. (Exit code: 1) gmake[1]: *** [rts/ghc.mk:315: rts/dist/build/RtsSymbols.o] Error 1 gmake: *** [Makefile:127: all] Error 2 }}} Any suggestions appreciated. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 21:46:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 21:46:17 -0000 Subject: [GHC] #15937: CI strategy for Gitlab In-Reply-To: <048.738065983349c6ff7ad5141b89ce5589@haskell.org> References: <048.738065983349c6ff7ad5141b89ce5589@haskell.org> Message-ID: <063.86c3bcf9d357e89ae453d9881240df8e@haskell.org> #15937: CI strategy for Gitlab -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 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 alpmestan): Hello Richard, Yes, that could have been a possibility, to ask people to get a Circle CI account and get some token from there that they would put in some gitlab settings. But Ben and I decided to try 2) and 3). He's giving a shot at a minimal script that only uses gitlab's CI system, no external service, while I'm implementing 3). I'm confident that we can get at least one of these working sometimes next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 22:12:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 22:12:11 -0000 Subject: [GHC] #15928: Reduction stack overflow when using "coerce" In-Reply-To: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> References: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> Message-ID: <062.0798cc9fbeaad2d3e25566aa21689638@haskell.org> #15928: Reduction stack overflow when using "coerce" -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): > Would you (for any value of "you") care to write some? Considering the case "you" == "me", in fact my (tiny) personal contribution to GHC started with documentation. Though I would love to do that more unfortunately due to lack of funding I cannot devote time on this. > There's no reason for GHC to assume that a and a0 should be the same, so it doesn't I am a bit puzzled, initially I thought the same, but then I wondered why GHC treats them the same in the case when `Stream` is not a newtype. So there seems to be a contradiction here, and that is the origin of this issue, because it was working in one case but not in the other, and it was working with explicit type annotation. Let's start with the types `SerialT Identity a` and `SerialT Identity a0`. In the "data Stream" case it would get expanded to: {{{ Stream Identity a Stream Identity a0 }}} Now why does GHC think that these two types are equal if it thinks `a` is not the same as `a0`. I am sure I am missing something, so please help me understand. Maybe after the representations have been simplified GHC is able to unify a with a0. In the problematic case it is never able to simplify them in the first place so the question of unifying never comes. If ultimately `a` can anyway be unified with `a0` then can it unify them before simplifying? In the explicit annotation case perhaps that is what is happening, the programmer has already told GHC that `a` and `a0` are the same, so the simplification starts with that assumption. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Nov 24 22:35:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Nov 2018 22:35:54 -0000 Subject: [GHC] #15928: Reduction stack overflow when using "coerce" In-Reply-To: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> References: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> Message-ID: <062.11fb39f1d2e2172f21f3e0fb3890a655@haskell.org> #15928: Reduction stack overflow when using "coerce" -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): I am further puzzled, as we know already, this definition works fine: {{{ data Stream m a = Stream { unStream :: forall r. (Stream m a -> m r) -> m r } }}} And this one results in an error: {{{ data Stream (m :: * -> *) a = Stop | Yield a (Stream m a) }}} {{{ xy.hs:26:20: error: • Couldn't match representation of type ‘a0’ with that of ‘a’ arising from a use of ‘coerce’ ‘a’ is a rigid type variable bound by the type signature for: f :: forall a. SerialT Identity a -> Identity Bool at xy.hs:25:1-40 • In the second argument of ‘(.)’, namely ‘coerce’ In the second argument of ‘(.)’, namely ‘idSerial . coerce’ In the expression: g . idSerial . coerce • Relevant bindings include f :: SerialT Identity a -> Identity Bool (bound at xy.hs:26:1) | 26 | f = g . idSerial . coerce | ^^^^^^ }}} If there is no bug then this needs to be explained in some simple way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 01:27:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 01:27:58 -0000 Subject: [GHC] #15946: configure script makes use of argument flag that is not supported in OpenBSD Message-ID: <046.3017f1852ca7a9c69257c8005088ddd6@haskell.org> #15946: configure script makes use of argument flag that is not supported in OpenBSD -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: configure | Operating System: OpenBSD Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After some head-scratching, I found that the configure script makes use of the **-v** verbose flag. This flag does not exist in OpenBSD. It was causing the build process to fail due to some files not existing during the compilation process. I'm getting around this by removing all **-v** occurrences as a pre- compilation step: {{{ find . -type f | xargs sed -i -e 's|^ln -f -v |ln -f |' }}} To make the process a little smoother for other folks, perhaps creating an alias that is conditional based OS type at the header of the script along the lines of would be best: {{{ case "$build_os" in openbsd*) alias mksymlnk="ln -f" ;; *) alias mksymlnk="ln -f -v" ;; esac ... mksymlnk utils/fs/fs.* utils/lndir/ ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 01:30:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 01:30:18 -0000 Subject: [GHC] #15946: configure script makes use of argument flag that is not supported in OpenBSD In-Reply-To: <046.3017f1852ca7a9c69257c8005088ddd6@haskell.org> References: <046.3017f1852ca7a9c69257c8005088ddd6@haskell.org> Message-ID: <061.439c6c36bfcaf01cc7dbb9c25fec8706@haskell.org> #15946: configure script makes use of argument flag that is not supported in OpenBSD -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: configure Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by klomeli: Old description: > After some head-scratching, I found that the configure script makes use > of the **-v** verbose flag. This flag does not exist in OpenBSD. It was > causing the build process to fail due to some files not existing during > the compilation process. > > I'm getting around this by removing all **-v** occurrences as a pre- > compilation step: > > {{{ > find . -type f | xargs sed -i -e 's|^ln -f -v |ln -f |' > }}} > > To make the process a little smoother for other folks, perhaps creating > an alias that is conditional based OS type at the header of the script > along the lines of would be best: > > {{{ > case "$build_os" in > openbsd*) > alias mksymlnk="ln -f" > ;; > *) > alias mksymlnk="ln -f -v" > ;; > esac > > ... > > mksymlnk utils/fs/fs.* utils/lndir/ > ... > > }}} New description: After some head-scratching, I found that the configure script makes use of **ln**'s **-v** verbose flag. This flag does not exist in OpenBSD's version of **ln**. It was causing the build process to fail due to some files not existing during the compilation process. I'm getting around this by removing all **-v** occurrences as a pre- compilation step: {{{ find . -type f | xargs sed -i -e 's|^ln -f -v |ln -f |' }}} To make the process a little smoother for other folks, perhaps creating an alias that is conditional based OS type at the header of the script along the lines of would be best: {{{ case "$build_os" in openbsd*) alias mksymlnk="ln -f" ;; *) alias mksymlnk="ln -f -v" ;; esac ... mksymlnk utils/fs/fs.* utils/lndir/ ... }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 04:06:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 04:06:01 -0000 Subject: [GHC] #15928: Reduction stack overflow when using "coerce" In-Reply-To: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> References: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> Message-ID: <062.e0ad433d09314a1bc1d513367cd79b0b@haskell.org> #15928: Reduction stack overflow when using "coerce" -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If we ask GHC for the role signature on `Stream` (as you can with `:info` in GHCi), we learn that the `a` parameter has a phantom role. This means that `Stream Identity a` shares a representation with `Stream Identity a0` no matter what `a` and `a0` are. So GHC does not unify them. Instead, it simply doesn't care what `a0` is. It chooses `Any`. (We can see this with `-ddump-tc -fprint-typechecker-elaboration`). When you change the definition for `Stream`, `a` then gets a representational role, and so GHC is stuck trying to figure out what `a0` is, giving you the error you observe. If you say `type role Stream representational nominal`, then the program is accepted, because now GHC observes that `a0` must certainly be `a`. It does the unification and then succeeds. > If there is no bug then this needs to be explained in some simple way. I respectfully disagree with this statement. Though simplicity is always a goal, it cannot be achieved in all cases. In the end, the `coerce` feature was added to provide a performance boost when GHC can know that runtime representations of two types are the same. That knowledge -- i.e., knowing when two types are `Coercible` -- is subtle, which is why it took the research community three papers to figure it out. Even now, as you have observed, we have room to improve. (That is, the choice between `data` and `newtype` shouldn't matter here... but it does, because we don't know an algorithm that can work reliably with recursive newtypes.) One might argue that we should have never introduced `coerce` because the theory behind it is too complicated. For better or worse, the Haskell community tends to prefer complicated, powerful solutions over simple, less expressive ones. (Of course, we love simple, powerful ones!) And so we end up where we are today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 04:34:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 04:34:49 -0000 Subject: [GHC] #15927: Weird interaction between fundeps and overlappable instances In-Reply-To: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> References: <048.b218f9f0c121bb2bbe0b66a214f5b04d@haskell.org> Message-ID: <063.bbf9fe044eca80ca870ca38666c5b8b0@haskell.org> #15927: Weird interaction between fundeps and overlappable instances -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 15632 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:6 Darwin226]: > Well, since the mtl default is to not only disallow multiple states of the same type, but multiple states of ANY type, I wouldn't really call this non-scaleable. It's strictly more flexible than mtl. I'm not following: the approach you're using 'allows' multiple states of same type in the sense you can stack a `String` on top of a `String`. But it's useless: `getMyState` as written will only access one of them. Then being "flexible" in this way, is only going to lead to confusion. Monad Transformers used to do this stacking. (I'm talking over 10 years ago.) The `l` in `mtl` stands for library: in general many modules might import `mtl` and declare instances of `MonadTrans`. If `mtl` were still relying on overlapping instances, it would be impossible/difficult to co- ordinate the instances to each use a unique type; and any code in modules using the stack would risk the well-known issues of 'orphan instances'. Perhaps your intended usage has a different pattern, and you're prepared to do the co-ordination manually. But at least for a sanity check, validate when you add a type to the stack that it's unique. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 08:48:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 08:48:37 -0000 Subject: [GHC] #15928: Reduction stack overflow when using "coerce" In-Reply-To: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> References: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> Message-ID: <062.b36f3a2fee463ad0588ca884959eea93@haskell.org> #15928: Reduction stack overflow when using "coerce" -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harendra): Thanks for patiently and promptly explaining the problem. I appreciate that. Phantom role explains the inconsistency and everything falls in place. I did not realize it, to create an absolutely minimal example I removed the use of the parameter and it became phantom, it was not so in the original code. I like the `coerce` feature and I am perfectly ok with the theory as long as the behavior is documented, errors are easy to understand and the documentation is discoverable. So perhaps we can make the error message better, if you think it can be improved. Does it make sense to spit out the role information in the error message? We can also add one or more examples to explain the pitfalls/incompleteness in the user guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 10:52:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 10:52:51 -0000 Subject: [GHC] #15896: GHC API: add function to allow looking up Name for Located RdrName In-Reply-To: <044.aff719817112fa9706a5e690b6a4722f@haskell.org> References: <044.aff719817112fa9706a5e690b6a4722f@haskell.org> Message-ID: <059.ed10eb72ac4cff5e3f2aa47e016faaba@haskell.org> #15896: GHC API: add function to allow looking up Name for Located RdrName -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 8.6.3 Component: GHC API | Version: 8.6.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:D5330 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 13:38:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 13:38:49 -0000 Subject: [GHC] #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o In-Reply-To: <050.a3b7fabd1dfe8f036f7828f2ade0cf8e@haskell.org> References: <050.a3b7fabd1dfe8f036f7828f2ade0cf8e@haskell.org> Message-ID: <065.e331daa8742f119980bef3fd454aa4e5@haskell.org> #15369: GHCi doesn't honor ':set +c' when loading, for a second time, a file that has .hi/.o -------------------------------------+------------------------------------- Reporter: dramforever | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T15369 Blocked By: | Blocking: Related Tickets: #15085 | Differential Rev(s): Phab:D5376 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => make test TEST=T15369 * differential: => Phab:D5376 * related: => #15085 Comment: @dramforever: The patch in Phab:D5376 only recollects the type information if the timestamp of the source (.hs) file has changed. The patch fixes the error in the compairson. Please note, if you don't change the file then GHCi has no reason to recollect. However, if you change the file, GHCi will now recollect! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 13:44:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 13:44:44 -0000 Subject: [GHC] #15085: :type-at/:all-types and :r don't mix In-Reply-To: <044.f4e4f79c3e387be82389134e302aff88@haskell.org> References: <044.f4e4f79c3e387be82389134e302aff88@haskell.org> Message-ID: <059.1b5739b2cf82e9bd66dcf95b5182c10b@haskell.org> #15085: :type-at/:all-types and :r don't mix -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T15369 Blocked By: | Blocking: Related Tickets: #15369 | Differential Rev(s): Phab:D5376 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => closed * testcase: => make test TEST=T15369 * differential: => Phab:D5376 * resolution: => duplicate * related: => #15369 Comment: This has been fixed with #15369, Phab:D5376. Ok, in reality #15369 was a duplicate of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 15:12:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 15:12:49 -0000 Subject: [GHC] #15814: Orphan Instance Overlap Error Message In-Reply-To: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> References: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> Message-ID: <065.430d9d94162d2e6fc1724c40d4edd627@haskell.org> #15814: Orphan Instance Overlap Error Message -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.4.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): D5377 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dminuoso): * status: new => patch * differential: => D5377 Comment: I put up a differential to include the requested feature. The current limitation is that import provenance can only be displayed if either the instances were defined in orphan modules or in the same module you imported it from. That should be sufficient for most cases though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 15:13:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 15:13:59 -0000 Subject: [GHC] #15814: Orphan Instance Overlap Error Message In-Reply-To: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> References: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> Message-ID: <065.48db5165528eb0905d4f70367337277d@haskell.org> #15814: Orphan Instance Overlap Error Message -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.4.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:D5377 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dminuoso): * differential: D5377 => Phab:D5377 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 15:46:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 15:46:32 -0000 Subject: [GHC] #15928: Improve error message: Reduction stack overflow when using "coerce" (was: Reduction stack overflow when using "coerce") In-Reply-To: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> References: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> Message-ID: <062.5071bff2eb66e579ee837f17a6b8e51c@haskell.org> #15928: Improve error message: Reduction stack overflow when using "coerce" -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Compiling the following snippet results in a "Reduction stack overflow" > error message: > > {{{#!hs > {-# Language ScopedTypeVariables #-} > {-# Language RankNTypes #-} > > import Data.Functor.Identity > import Data.Coerce > > newtype Stream m a = > Stream { > unStream :: forall r. (Stream m a -> m r) -> m r > } > > newtype SerialT m a = SerialT (Stream m a) > > g :: SerialT Identity a -> Identity Bool > g m = undefined > > idSerial :: SerialT Identity a -> SerialT Identity a > idSerial = id > > f :: SerialT Identity a -> Identity Bool > f = g . idSerial . coerce > > main = undefined > }}} > > The following error message is produced on compiling this with ghc-8.6.2: > > {{{ > xy.hs:26:20: error: > • Reduction stack overflow; size = 201 > When simplifying the following type: > Coercible > ((Stream Identity a -> Identity r) -> Identity r) > ((Stream Identity a0 -> Identity r) -> Identity r) > 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 second argument of ‘(.)’, namely ‘coerce’ > In the second argument of ‘(.)’, namely ‘idSerial . coerce’ > In the expression: g . idSerial . coerce > | > 26 | f = g . idSerial . coerce > | ^^^^^^ > }}} > > When I use an inline signature like this: > > {{{#!hs > f :: SerialT Identity a -> Identity Bool > f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce > > main = undefined > }}} > > It again results in the same error: > > {{{ > xy.hs:18:60: error: > • Reduction stack overflow; size = 201 > When simplifying the following type: > Coercible > ((Stream Identity a -> Identity r) -> Identity r) > ((Stream Identity a0 -> Identity r) -> Identity r) > 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 second argument of ‘(.)’, namely ‘coerce’ > In the second argument of ‘(.)’, namely > ‘(id :: SerialT Identity a -> SerialT Identity a) . coerce’ > In the expression: > g . (id :: SerialT Identity a -> SerialT Identity a) . coerce > | > 18 | f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce > | ^^^^^^ > }}} > > Everything works fine is I use an inline signature with a `forall` > keyword like this: > > {{{#!hs > f :: forall a. SerialT Identity a -> Identity Bool > f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce > }}} > > I have following questions: > > 1) Why the first version results in a panic? Is that a bug? > 2) The second version might possibly be incorrect code because the types > do not unify, but still it should not result in a panic, because of the > panic I could not figure out what the problem is. It took a long time to > isolate the code and then do some trial and error on it. New description: EDIT: Executive summary: The error messages below are confusing and not perspicuous to users. We should fix. comment:2 has a concrete suggestion to use as a starting point, and comment:7 suggests we print out the role signature of any tycons involved. Compiling the following snippet results in a "Reduction stack overflow" error message: {{{#!hs {-# Language ScopedTypeVariables #-} {-# Language RankNTypes #-} import Data.Functor.Identity import Data.Coerce newtype Stream m a = Stream { unStream :: forall r. (Stream m a -> m r) -> m r } newtype SerialT m a = SerialT (Stream m a) g :: SerialT Identity a -> Identity Bool g m = undefined idSerial :: SerialT Identity a -> SerialT Identity a idSerial = id f :: SerialT Identity a -> Identity Bool f = g . idSerial . coerce main = undefined }}} The following error message is produced on compiling this with ghc-8.6.2: {{{ xy.hs:26:20: error: • Reduction stack overflow; size = 201 When simplifying the following type: Coercible ((Stream Identity a -> Identity r) -> Identity r) ((Stream Identity a0 -> Identity r) -> Identity r) 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 second argument of ‘(.)’, namely ‘coerce’ In the second argument of ‘(.)’, namely ‘idSerial . coerce’ In the expression: g . idSerial . coerce | 26 | f = g . idSerial . coerce | ^^^^^^ }}} When I use an inline signature like this: {{{#!hs f :: SerialT Identity a -> Identity Bool f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce main = undefined }}} It again results in the same error: {{{ xy.hs:18:60: error: • Reduction stack overflow; size = 201 When simplifying the following type: Coercible ((Stream Identity a -> Identity r) -> Identity r) ((Stream Identity a0 -> Identity r) -> Identity r) 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 second argument of ‘(.)’, namely ‘coerce’ In the second argument of ‘(.)’, namely ‘(id :: SerialT Identity a -> SerialT Identity a) . coerce’ In the expression: g . (id :: SerialT Identity a -> SerialT Identity a) . coerce | 18 | f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce | ^^^^^^ }}} Everything works fine is I use an inline signature with a `forall` keyword like this: {{{#!hs f :: forall a. SerialT Identity a -> Identity Bool f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce }}} I have following questions: 1) Why the first version results in a panic? Is that a bug? 2) The second version might possibly be incorrect code because the types do not unify, but still it should not result in a panic, because of the panic I could not figure out what the problem is. It took a long time to isolate the code and then do some trial and error on it. -- Comment (by goldfire): Yes, by all means we can improve that error message, and we should leave this ticket open as an opportunity to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 15:47:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 15:47:11 -0000 Subject: [GHC] #15928: Improve error message: Reduction stack overflow when using "coerce" In-Reply-To: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> References: <047.609600b1accf01a155e7fe7979a7ca31@haskell.org> Message-ID: <062.45d74e76c5cda6f013eabee14386351d@haskell.org> #15928: Improve error message: Reduction stack overflow when using "coerce" -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: ErrorMessages Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => ErrorMessages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 15:48:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 15:48:32 -0000 Subject: [GHC] #15810: Kind inference error in classes In-Reply-To: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> References: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> Message-ID: <062.69c59580042626b40b0456c2187bd1a1@haskell.org> #15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5305 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: Hmmph. Fine, you win. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 16:15:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 16:15:32 -0000 Subject: [GHC] #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol (was: Unable to compile GHC from source on OpenBSD (-CURRENT)) In-Reply-To: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> References: <046.f0013d9482800c7075d7ac8b84b5ee6a@haskell.org> Message-ID: <061.2230a9472471df864480078e7fb6b25d@haskell.org> #15945: Unable to compile GHC from source: redefinition of '_DYNAMIC' as different kind of symbol -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (make) | Resolution: | Keywords: clang Operating System: OpenBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > I am running the following script to build GHC from sources > (ghc-8.6.2-src.tar.xz) on OpenBSD (-CURRENT): > > {{{ > #! /bin/sh > set -e > > BUILD_DIR=/usr/local/tmp-build-ghc > > export AUTOCONF_VERSION=2.69 > export AUTOMAKE_VERSION=1.16 > > if [ ! -n "$1" ]; then > echo "ERROR: Provide path for ghc source." > exit 1 > fi > > echo "Extracting ghc source files from ${1} to ${BUILD_DIR} ..." > mkdir -p $BUILD_DIR > > cd $BUILD_DIR > xzcat $1 | tar xvf - > > GHC_DIR=`ls | grep ghc` > cd $GHC_DIR > > echo "Cleaning up OpenBSD-incompatible commands..." > find . -type f | xargs sed -i -e 's|^ln -f -v |ln -f |' > > echo "Building GHC... " > export CC=/usr/bin/clang > > ./boot > ./configure --with-iconv-libraries=/usr/local/lib \ > --with-iconv-includes=/usr/local/include \ > --with-gmp-libraries=/usr/local/lib \ > --with-gmp-includes=/usr/local/include \ > --with-ffi-libraries=/usr/local/lib \ > --with-ffi-includes=/usr/local/include \ > --with-system-libffi > gmake > }}} > > I will file a separate bug report for the **ln** incompatibility with the > unsupported **-v** flag. > > When compiling GHC, I get the following error: > > {{{ > > ... > > "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wall > -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc- > Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc- > Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc- > Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc- > Iincludes/dist-derivedconstants/header -optc-Iincludes/dist- > ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS > -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing -optc-fno-common -optc- > Irts/dist/build/./autogen -optc-Wno-unknown-pragmas -optc-O2 -optc-fomit- > frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-ffunction-sections > -optc-fdata-sections -static -H32m -O -Wall -Iincludes -Iincludes/dist > -Iincludes/dist-derivedconstants/header -Iincludes/dist- > ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS > -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts > -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen > -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- > monad-instances -c rts/RtsSymbols.c -o rts/dist/build/RtsSymbols.o > > rts/RtsSymbols.c:990:1: error: > error: redefinition of '_DYNAMIC' as different kind of symbol > | > 990 | RTS_OPENBSD_ONLY_SYMBOLS > | ^ > RTS_OPENBSD_ONLY_SYMBOLS > ^ > > rts/RtsSymbols.c:283:22: error: > note: expanded from macro 'RTS_OPENBSD_ONLY_SYMBOLS' > SymE_NeedsProto(_DYNAMIC) > ^ > | > 283 | SymE_NeedsProto(_DYNAMIC) > | ^ > > /usr/include/sys/exec_elf.h:765:17: error: > note: previous definition is here > | > 765 | extern Elf_Dyn _DYNAMIC[]; > | ^ > extern Elf_Dyn _DYNAMIC[]; > ^ > 1 error generated. > `clang' failed in phase `C Compiler'. (Exit code: 1) > gmake[1]: *** [rts/ghc.mk:315: rts/dist/build/RtsSymbols.o] Error 1 > gmake: *** [Makefile:127: all] Error 2 > }}} > > Any suggestions appreciated. Thanks! New description: I am running the following script to build GHC from sources (ghc-8.6.2-src.tar.xz) on OpenBSD (-CURRENT): {{{ #! /bin/sh set -e BUILD_DIR=/usr/local/tmp-build-ghc export AUTOCONF_VERSION=2.69 export AUTOMAKE_VERSION=1.16 if [ ! -n "$1" ]; then echo "ERROR: Provide path for ghc source." exit 1 fi echo "Extracting ghc source files from ${1} to ${BUILD_DIR} ..." mkdir -p $BUILD_DIR cd $BUILD_DIR xzcat $1 | tar xvf - GHC_DIR=`ls | grep ghc` cd $GHC_DIR echo "Cleaning up OpenBSD-incompatible commands..." find . -type f | xargs sed -i -e 's|^ln -f -v |ln -f |' echo "Building GHC... " export CC=/usr/bin/clang ./boot ./configure --with-iconv-libraries=/usr/local/lib \ --with-iconv-includes=/usr/local/include \ --with-gmp-libraries=/usr/local/lib \ --with-gmp-includes=/usr/local/include \ --with-ffi-libraries=/usr/local/lib \ --with-ffi-includes=/usr/local/include \ --with-system-libffi gmake }}} I have filed a separate bug report for the **ln** incompatibility with the unsupported **-v** flag. When compiling GHC, I get the following error: {{{ ... "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc- Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc- Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc- Wredundant-decls -optc-Wundef -optc-Iincludes -optc-Iincludes/dist -optc- Iincludes/dist-derivedconstants/header -optc-Iincludes/dist- ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing -optc-fno-common -optc- Irts/dist/build/./autogen -optc-Wno-unknown-pragmas -optc-O2 -optc-fomit- frame-pointer -optc-g -optc-DRtsWay=\"rts_v\" -optc-ffunction-sections -optc-fdata-sections -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/RtsSymbols.c -o rts/dist/build/RtsSymbols.o rts/RtsSymbols.c:990:1: error: error: redefinition of '_DYNAMIC' as different kind of symbol | 990 | RTS_OPENBSD_ONLY_SYMBOLS | ^ RTS_OPENBSD_ONLY_SYMBOLS ^ rts/RtsSymbols.c:283:22: error: note: expanded from macro 'RTS_OPENBSD_ONLY_SYMBOLS' SymE_NeedsProto(_DYNAMIC) ^ | 283 | SymE_NeedsProto(_DYNAMIC) | ^ /usr/include/sys/exec_elf.h:765:17: error: note: previous definition is here | 765 | extern Elf_Dyn _DYNAMIC[]; | ^ extern Elf_Dyn _DYNAMIC[]; ^ 1 error generated. `clang' failed in phase `C Compiler'. (Exit code: 1) gmake[1]: *** [rts/ghc.mk:315: rts/dist/build/RtsSymbols.o] Error 1 gmake: *** [Makefile:127: all] Error 2 }}} Any suggestions appreciated. Thanks! -- Comment (by klomeli): Updated title to reflect build issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 16:17:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 16:17:33 -0000 Subject: [GHC] #15946: configure script makes use of ln -v flag which is not supported in OpenBSD (was: configure script makes use of argument flag that is not supported in OpenBSD) In-Reply-To: <046.3017f1852ca7a9c69257c8005088ddd6@haskell.org> References: <046.3017f1852ca7a9c69257c8005088ddd6@haskell.org> Message-ID: <061.5c423c5535e3192860243925644a7f88@haskell.org> #15946: configure script makes use of ln -v flag which is not supported in OpenBSD -------------------------------------+------------------------------------- Reporter: klomeli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: configure Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | 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 Nov 25 16:39:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 16:39:22 -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.e13245d43fbdacdf65e031e1912b8082@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: | -------------------------------------+------------------------------------- Changes (by Artyom.Kazak): * cc: Artyom.Kazak (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 16:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 16:40:54 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it has no free variables In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.af19820a111b3141b163f0b7f620849d@haskell.org> #13262: Allow type synonym family application in instance head if it has no free variables -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12680 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Artyom.Kazak): * cc: Artyom.Kazak (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 16:59:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 16:59:53 -0000 Subject: [GHC] #14690: Pattern match failure in GHCi with :steplocal In-Reply-To: <048.4ac9679edbe0cbd1f570bf129c521a7d@haskell.org> References: <048.4ac9679edbe0cbd1f570bf129c521a7d@haskell.org> Message-ID: <063.35d7fef7b94f047fb049d85a1f2dc061@haskell.org> #14690: Pattern match failure in GHCi with :steplocal ---------------------------------+-------------------------------------- Reporter: Philonous | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by RolandSenn): Up to GHC 8.4.4 we get the ''Pattern match failure'' message as shown in the ticket. \\ With GHC 8.6.1 and higher we get a ''panic'' message: {{{ [] Prelude> :steplocal : panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-linux): enclosingTickSpan UnhelpfulSpan }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 17:31:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 17:31:01 -0000 Subject: [GHC] #15810: Kind inference error in classes In-Reply-To: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> References: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> Message-ID: <062.92b10dac5e1369891f9b959042e5ff26@haskell.org> #15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5305 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I hope that means "I reluctantly agree that this is not a bug" rather than I've just worn you out :-)! I'd be happy with a better solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 17:56:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 17:56:52 -0000 Subject: [GHC] #15241: Validate failures in sanity way In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.7e7f362d55b8a477462c1bd319c2d948@haskell.org> #15241: Validate failures in sanity way -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14915, #15906 | Differential Rev(s): Phab:D4839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Current status: (9e47dd32e238ed0c4c39035f47e0843ddccb5175) {{{ Unexpected failures: rts/T7919.run T7919 [bad exit code] (sanity) libraries/base/tests/length001.run length001 [bad exit code] (sanity) libraries/base/tests/memo001.run memo001 [bad exit code] (sanity) libraries/ghc-heap/tests/heap_all.run heap_all [bad exit code] (sanity) libraries/hpc/tests/raytrace/hpc_raytrace.run hpc_raytrace [bad exit code] (sanity) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 18:05:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 18:05:11 -0000 Subject: [GHC] #15810: Kind inference error in classes In-Reply-To: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> References: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> Message-ID: <062.cbee7b469ebe31a7891f848daaff7ab3@haskell.org> #15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5305 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, you got it. I agree with your analysis. But it all makes me wish we had a more regular syntax for these declarations. Between classes, datatypes (with two syntaxes), and type families (both associated and not), we just have a veritable zoo of special cases. This is not a problem to solved right now, right here, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 18:31:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 18:31:06 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) (was: GHC panic from TypeApplications(?)) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.32b506360214e3bef51bf9afcd220b59@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: TypeApplications => QuantifiedConstraints Comment: I don't see anything involving type applications here. Changing ticket accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 19:55:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 19:55:11 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it has no free variables In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.08a86cd42d8bfec430f69307498d2ecb@haskell.org> #13262: Allow type synonym family application in instance head if it has no free variables -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12680 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Artyom.Kazak): > Oh all right. We can wait till someone else pipes in and requests this :) That would be me! My usecase is generating anonymous records and then defining SafeCopy migrations for them (see http://hackage.haskell.org/package/safecopy-0.9.4.1/docs/Data- SafeCopy.html#t:Migrate). Essentially this: {{{ type Foo_v1 = ... type Foo_v2 = AddField "name" Text Foo_v1 type Foo_v3 = RemoveField "age" Foo_v2 }}} All of that is implemented via type families. The problem is that now I can't have instances for these types (e.g. `instance Migrate Foo_v3`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 19:56:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 19:56:02 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it has no free variables In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.48d3ac1eb6ffd5245999c4acbbb8e96a@haskell.org> #13262: Allow type synonym family application in instance head if it has no free variables -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12680 Related Tickets: 13773 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Artyom.Kazak): * related: => 13773 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 19:56:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 19:56:40 -0000 Subject: [GHC] #13262: Allow type synonym family application in instance head if it has no free variables In-Reply-To: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> References: <045.aaf9df7d6d641bc7149803583d5e47fd@haskell.org> Message-ID: <060.7915bdc37b7ff47198e5dd571f5ec949@haskell.org> #13262: Allow type synonym family application in instance head if it has no free variables -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12680 Related Tickets: #13773 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Artyom.Kazak): * related: 13773 => #13773 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 23:41:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 23:41:52 -0000 Subject: [GHC] #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 Message-ID: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 --------------------------------------+--------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: --------------------------------------+--------------------------------- 80 unexpected faillures for make test on mac on ghc 8.6.2; I'm using an 8.6.2 from the binary distribution Xcode 10.1, macos 10.13.6 Attached is the compressed output from "make test >& test.log &" I don't know what the results are on other platforms. {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.2 bash-3.2$ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include- dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin bash-3.2$ python3 --version Python 3.7.0 bash-3.2$ uname -a Darwin iMac27.local 17.7.0 Darwin Kernel Version 17.7.0: Wed Oct 10 23:06:14 PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64 x86_64 bash-3.2$ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags"," ") ,("C compiler supports -no-pie","NO") ,("Haskell CPP command","gcc") ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno- unicode -Wno-trigraphs") ,("ld command","ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","ar") ,("ar flags","qcls") ,("ar supports at file","NO") ,("ranlib command","") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/local/bin/perl") ,("cross compiling","NO") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("target has RTS linker","YES") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("LLVM clang command","clang") ,("Project version","8.6.2") ,("Project Git commit id","41f0f6c2f571ea05c49f9f6ed64beebdc5a9f9fc") ,("Booter version","8.4.4") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Support Backpack","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-8.6.2") ,("Global Package DB","/usr/local/lib/ghc-8.6.2/package.conf.d") ] bash-3.2$ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 23:48:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 23:48:22 -0000 Subject: [GHC] #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 In-Reply-To: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> References: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> Message-ID: <060.6f00eb06ff5284601cbc5386c470c6ae@haskell.org> #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 ---------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by George): * Attachment "test.log.bz2" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 23:49:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 23:49:04 -0000 Subject: [GHC] #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 In-Reply-To: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> References: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> Message-ID: <060.c0772d3d36c5666a9376ab5580ed97dd@haskell.org> #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 ---------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by George): * Attachment "test.log.2.bz2" added. output of "make test" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 23:50:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 23:50:15 -0000 Subject: [GHC] #15948: Hadrian cannot build on Windows Message-ID: <046.fad7028de08314594b0d21c085af049c@haskell.org> #15948: Hadrian cannot build on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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 Hadrian build on Windows currently fails with {{{ 'C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe' exited ghc.exe: could not detect mingw toolchain }}} when trying to build the RTS. I strongly suspect that the problem is that the stage1 toolchain built by Hadrian lives in `_build/stage0/bin/ghc` whereas the mingw tarballs were extracted to `inplace/mingw`. It's quite unclear to me how this ever worked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 23:50:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 23:50:22 -0000 Subject: [GHC] #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 In-Reply-To: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> References: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> Message-ID: <060.a06eb14e7829c9f91025bc8d5f5abf5d@haskell.org> #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 ---------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by George): Please ignore second attachment, it is a duplicate of the first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Nov 25 23:53:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Nov 2018 23:53:07 -0000 Subject: [GHC] #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 In-Reply-To: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> References: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> Message-ID: <060.c34b3730d20af5840040332a1541bd09@haskell.org> #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 ---------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by George): I'm not sure what the milestone and priority should be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 00:03:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 00:03:53 -0000 Subject: [GHC] #15948: Hadrian cannot build on Windows In-Reply-To: <046.fad7028de08314594b0d21c085af049c@haskell.org> References: <046.fad7028de08314594b0d21c085af049c@haskell.org> Message-ID: <061.98936ea4ed1cd7f37b03bb502617130f@haskell.org> #15948: Hadrian cannot build on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed `cp -R inplace/mingw _build` seems to allow the build to proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 00:16:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 00:16:34 -0000 Subject: [GHC] #12232: Opportunity to do better in register allocations In-Reply-To: <047.5bf3923469a5875e46770c25c8cfa650@haskell.org> References: <047.5bf3923469a5875e46770c25c8cfa650@haskell.org> Message-ID: <062.6ec603d82a05913f7e10eef7356c6498@haskell.org> #12232: Opportunity to do better in register allocations -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12231 #14672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: #12231 => #12231 #14672 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 00:19:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 00:19:36 -0000 Subject: [GHC] #12232: Opportunity to do better in register allocations In-Reply-To: <047.5bf3923469a5875e46770c25c8cfa650@haskell.org> References: <047.5bf3923469a5875e46770c25c8cfa650@haskell.org> Message-ID: <062.266d04f1796fe986197a4afc9372461d@haskell.org> #12232: Opportunity to do better in register allocations -------------------------------------+------------------------------------- Reporter: harendra | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12231 #14672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 00:29:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 00:29:33 -0000 Subject: [GHC] #15948: Hadrian cannot build on Windows In-Reply-To: <046.fad7028de08314594b0d21c085af049c@haskell.org> References: <046.fad7028de08314594b0d21c085af049c@haskell.org> Message-ID: <061.a40fb4ac02e2fb9b5de2a041306b98f2@haskell.org> #15948: Hadrian cannot build on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): I think I know what's going on: right now `inplace/mingw` is copied to `_build` only when the `-c` flag is passed, and you prefer to run `configure` manually. See this: https://github.com/ghc/ghc/blob/master/hadrian/src/Rules/Configure.hs#L37-L44 This is a hack, and we should get rid of it, but I couldn't come up with anything significantly better. Do you have any suggestions on how to reliably handle mingw tarballs? It might seem like this is a task for the `configure` script, but unfortunately it doesn't know the build root (`_build` may be overriden). Here is the corresponding issue on GitHub: https://github.com/snowleopard/hadrian/issues/564. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 06:30:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 06:30:23 -0000 Subject: [GHC] #15241: Validate failures in sanity way In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.2f909e403b0db838fac42178e59fb033@haskell.org> #15241: Validate failures in sanity way -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14915, #15906 | Differential Rev(s): Phab:D4839 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Looking at the results again - `T7919`: Timeout, but passes if I wait long enough (a few hours). - `memo001`: Timeout, but passes if I wait long enough. - `hpc_raytrace`: Timeout, but passes if I wait long enough. - `heap_all`: An actual bug, but probably in the `ghc-heap` library. - `length001`: Stack overflow. The test requires `-O` which is not passed in sanity way. If I add `-O` this passes. So I think we're in a good shape. We just need to tweak tests a little bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 06:57:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 06:57:56 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.0297e39d1094fd58981f0f2a8283baa2@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: 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 harpocrates): * cc: harpocrates (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 08:52:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 08:52:27 -0000 Subject: [GHC] #15930: Add @since-annotations to the Foldable methods In-Reply-To: <046.1181e048db0e902f4cec12b70c302d38@haskell.org> References: <046.1181e048db0e902f4cec12b70c302d38@haskell.org> Message-ID: <061.c1b5902ac136a40473fbc444642e2d96@haskell.org> #15930: Add @since-annotations to the Foldable methods -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.3 Component: Core Libraries | Version: 8.6.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): Phab:D5379 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dminuoso): * status: new => patch * differential: => Phab:D5379 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 09:29:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 09:29:56 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.bbb873d7ab581e6594772d69c0649bac@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): Shake records cached oracles immediately and even if the build fails (but not if the parsing of the metadata fails, as you might expect). I'd treat the pause and the slow rebuild as entirely separate issues, since they likely have different causes. Of these, slow rebuild is the easiest one to reproduce - generally you shouldn't be running any command line tools during a rebuild, and if you do, you failed to cache something properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 10:30:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 10:30:22 -0000 Subject: [GHC] #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings In-Reply-To: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> References: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> Message-ID: <066.cc3482868c33ad430944e1c51df39838@haskell.org> #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: shayne- | fletcher-da Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal 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:D5251 Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 11:44:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 11:44:49 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.60a2a66d86980c88a8432acc282709b1@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: davide Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Phab:D5312 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Can someone amend wiki:Migration/8.8 with information about this change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 12:53:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 12:53:06 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.ab864b48322c7e62bf52435a20fae983@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Trac #15918 is another example of the need for `mkTcCastTy`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 13:18:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 13:18:01 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.481d542d5c5334da2744156affda6846@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is another symptom of the bug identified in #15799. In the example of this ticket we have {{{ Elaborated types Rev :: forall k. (k->*) -> Constraint Build :: forall k. ((k->*) -> Constraint) -> k -> * rev :: forall k (f :: k->*) (a :: k). Rev @k f => f a instance forall k (cls :: (k->*) -> Constraint). (forall (xx :: k->*). cls xx => Rev @k xx) => Rev @k (Build @k cls) From the RHS of uu: [W] Rev @k (Build ([] |> co)) [W] co :: (* -> *) ~ ((k->*) -> Constraint) }}} Decompose co, we get {{{ [W] Rev @k (Build ([] |> (co1 -> co2))) [W] co1 :: * ~ (k->*) [W] co2 :: * ~ Constraint }}} Now the first constraint matches the instance, so we get a substitution: {{{ cls :-> ([] |> (co1 -> co2) }}} Now * we apply `substTheta` (this is in `Inst.instDFunType`) to `(cls xx)` * `substTheta` calls `mkAppTy ([] |> (co1 -> co2)) xx` * `mkAppTy` uses `decomposePiCos` (which works) and then calls `mkCastTy` (twice) * Alas, `mkCastTy` considers that `Constraint ~ *`, and we lose `co2` And that's how the assert fails. The underlying cause is the same: `mkCastTy` is using `isReflexiveCo`, and we really want `mkTcCastTy` here. But we don't really want to have a `Tc` variant of `substTy`! Sigh. So much pain from the varying treatment of `Constraint` and `Type`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 13:29:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 13:29:24 -0000 Subject: [GHC] #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux In-Reply-To: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> References: <045.3614405aa9ec33ce6043c2ec7d6d838c@haskell.org> Message-ID: <060.d0b82b669450d759b39bfd1ff740cbf7@haskell.org> #15916: GHC doesn't build on powerpc64 architecture on systems other than GNU / Linux -------------------------------------+------------------------------------- Reporter: pkubaj | Owner: trommler Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: (none) => trommler Comment: I am going to look into this. I just installed FreeBSD on my PowerMac. Do you know if the linux execution environment is available for powerpc64? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 13:54:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 13:54:26 -0000 Subject: [GHC] #15899: Testcase tcfail158 is broken In-Reply-To: <049.7f6552ee392f2083aa812ec96556b9fa@haskell.org> References: <049.7f6552ee392f2083aa812ec96556b9fa@haskell.org> Message-ID: <064.d05a02631d223fe7ae96e42f6382f62c@haskell.org> #15899: Testcase tcfail158 is broken -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12906 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here is a somewhat simplified version of the issue: {{{#!hs module Bug where f, g :: Maybe f = Nothing g = undefined }}} In GHC 8.6.2, this simply errors with: {{{ $ ~/Software/haskell/ghc-8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:3:9: error: • Expecting one more argument to ‘Maybe’ Expected a type, but ‘Maybe’ has kind ‘* -> *’ • In the type signature: f :: Maybe | 3 | f, g :: Maybe | ^^^^^ }}} But in GHC HEAD (as of commit df570d920fa66db631f936fa377e598fe92bd2a1), we get many more errors: {{{ $ ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:3:9: error: • Expecting one more argument to ‘Maybe’ Expected a type, but ‘Maybe’ has kind ‘* -> *’ • In the type signature: f :: Maybe | 3 | f, g :: Maybe | ^^^^^ Bug.hs:4:5: error: • Couldn't match expected type ‘Maybe’ with actual type ‘Maybe a1’ • In the expression: Nothing In an equation for ‘f’: f = Nothing | 4 | f = Nothing | ^^^^^^^ Bug.hs:5:5: error: • Couldn't match kind ‘* -> *’ with ‘*’ When matching types a0 :: * Maybe :: * -> * • In the expression: undefined In an equation for ‘g’: g = undefined | 5 | g = undefined | ^^^^^^^^^ }}} I'll try tracking down which commit introduced this regression when I get a chance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 14:46:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 14:46:46 -0000 Subject: [GHC] #15949: Hadrian needs more convenient build target names Message-ID: <046.a0cda9df357797abce34c12980353145@haskell.org> #15949: Hadrian needs more convenient build target names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- With the `make` build system one can easily build a particular library or executable by `cd`ing into the relevant directory and typing `make`. With `hadrian` there appears to be no convenient way to replicate this. Instead, you need to know the name of the final target which the build will produce which may contain version numbers, platform triples, and all sorts of other ugliness. I suggest we introduce a set of convenience targets to make this easier. For instance one could run: {{{ $ hadrian stage1:lib:ghc }}} to build the stage1 `ghc` library or {{{ $ hadrian stage2:exe:hp2ps }}} to build `hp2ps`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 14:58:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 14:58:05 -0000 Subject: [GHC] #15948: Hadrian cannot build on Windows In-Reply-To: <046.fad7028de08314594b0d21c085af049c@haskell.org> References: <046.fad7028de08314594b0d21c085af049c@haskell.org> Message-ID: <061.e8f44c161f119aef5cdb1358ce7ebbcb@haskell.org> #15948: Hadrian cannot build on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: 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): Ahh, thanks for the quick reply, Andrey! That explanation sounds quite plausible. A slight improvement might be to follow through on the TODO you pointed at and add proper dependency tracking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 14:59:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 14:59:20 -0000 Subject: [GHC] #15934: Building ghc with profiling libraries fails on windows. (was: Building ghc with dwarf information and profiling libraries fails on windows.) In-Reply-To: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> References: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> Message-ID: <062.8781ec98600598a4a8a8035a71f06202@haskell.org> #15934: Building ghc with profiling libraries fails on windows. ---------------------------------+---------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: | ---------------------------------+---------------------------------------- Changes (by AndreasK): * priority: normal => high Old description: > Seems like we create too many sections in a single file on windows. > > {{{ > C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: > C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801) > C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Assembler messages: > C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't write 4 > bytes to section .rdata$c1w2b_str of > C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o because: 'File too big' > C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: > C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801) > C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't close > C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: File too big > `gcc.exe' failed in phase `Assembler'. (Exit code: 1) > make[1]: *** [libraries/template-haskell/ghc.mk:4: libraries/template- > haskell/dist-install/build/Language/Haskell/TH/Syntax.p_o] Error 1 > make[1]: *** Waiting for unfinished jobs.... > make: *** [Makefile:128: all] Error 2 > }}} > > > build.mk > {{{ > ifneq "$(BuildFlavour)" "" > include mk/flavours/$(BuildFlavour).mk > endif > > GhcLibHcOpts += -g1 > GhcRtsHcOpts += -g1 > # GhcStage2HcOpts += -g3 > > BUILD_PROF_LIBS=YES > > # Don't strip debug and other unneeded symbols from libraries and > executables. > STRIP_CMD = : > > HADDOCK_DOCS = NO > BUILD_SPHINX_HTML = NO > BUILD_SPHINX_PDF = NO > BUILD_MAN = NO > > }}} New description: I've initially only hit this when enabling -g, but now I've run into the same issue without a customized build.mk file. ---- Seems like we create too many sections in a single file on windows. {{{ C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801) C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Assembler messages: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't write 4 bytes to section .rdata$c1w2b_str of C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o because: 'File too big' C://ghc//msys64//home//Andi//ghc_head//inplace//mingw//bin/as.exe: C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: too many sections (32801) C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_1.s: Fatal error: can't close C:\\ghc\\msys64\\tmp\\ghc6664_0\\ghc_6.p_o: File too big `gcc.exe' failed in phase `Assembler'. (Exit code: 1) make[1]: *** [libraries/template-haskell/ghc.mk:4: libraries/template- haskell/dist-install/build/Language/Haskell/TH/Syntax.p_o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:128: all] Error 2 }}} build.mk {{{ ifneq "$(BuildFlavour)" "" include mk/flavours/$(BuildFlavour).mk endif GhcLibHcOpts += -g1 GhcRtsHcOpts += -g1 # GhcStage2HcOpts += -g3 BUILD_PROF_LIBS=YES # Don't strip debug and other unneeded symbols from libraries and executables. STRIP_CMD = : HADDOCK_DOCS = NO BUILD_SPHINX_HTML = NO BUILD_SPHINX_PDF = NO BUILD_MAN = NO }}} -- Comment: Update: I've had this just happen even with debugging information disabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 14:59:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 14:59:56 -0000 Subject: [GHC] #15949: Hadrian needs more convenient build target names In-Reply-To: <046.a0cda9df357797abce34c12980353145@haskell.org> References: <046.a0cda9df357797abce34c12980353145@haskell.org> Message-ID: <061.e0f158fa78e66c95326fa37bcedcab6b@haskell.org> #15949: Hadrian needs more convenient build target names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Build System (Hadrian) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 15:03:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 15:03:57 -0000 Subject: [GHC] #15950: Hadrian build fails on Windows Message-ID: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> #15950: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As of {{{ $ hadrian/build.cabal.sh -j5 --flavour=Quick ... $ hadrian/build.cabal.sh -j5 --flavour=Quick | ContextData oracle: resolving data for 'iserv' (Stage1, v)... | Configure package 'iserv' Configuring iserv-8.7.1... creating C:\msys64\home\ben\ghc\builds\0\project-0\_build\stage1\utils\iserv\build "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--numeric-version" ]0;1s (99%)C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe is version 8.7.20181126 "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "--version" C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe is version 8.7.20181126 "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--supported-languages" "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "-- info" Reading installed packages... "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "dump" "--global" "-v0" "--global-package- db=C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage1/lib/package.conf.d" "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--print-libdir" "-ghcversion- file=C:/msys64/home/ben/ghc/builds/0/project-0/_build/generated/ghcversion.h" CallStack (from HasCallStack): die', called at .\Distribution\Simple\Configure.hs:969:20 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configureFinalizedPackage, called at .\Distribution\Simple\Configure.hs:467:12 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configure, called at .\Distribution\Simple.hs:596:20 in Cabal-2.5.0.0-inplace:Distribution.Simple confHook, called at .\Distribution\Simple\UserHooks.hs:67:5 in Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks configureAction, called at .\Distribution\Simple.hs:178:19 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainHelper, called at .\Distribution\Simple.hs:148:3 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainWithHooksNoReadArgs, called at src\Hadrian\Haskell\Cabal\Parse.hs:145:14 in main:Hadrian.Haskell.Cabal.Parse hadrian.exe: Encountered missing dependencies: libiserv ==8.7.* }}} (Ignore garbage characters due to Window's broken ANSI console support) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 15:04:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 15:04:26 -0000 Subject: [GHC] #15950: Hadrian build fails on Windows In-Reply-To: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> References: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> Message-ID: <061.c3f0fc4d8814ab9e50794bebaac3f69a@haskell.org> #15950: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: 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: > As of > {{{ > $ hadrian/build.cabal.sh -j5 --flavour=Quick > ... > $ hadrian/build.cabal.sh -j5 --flavour=Quick > | ContextData oracle: resolving data for 'iserv' (Stage1, v)... > | Configure package 'iserv' > Configuring iserv-8.7.1... > creating > C:\msys64\home\ben\ghc\builds\0\project-0\_build\stage1\utils\iserv\build > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" > "--numeric-version" > ]0;1s > (99%)C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe > is version > 8.7.20181126 > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" > "--version" > C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe > is > version 8.7.20181126 > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" > "--supported-languages" > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "-- > info" > Reading installed packages... > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" > "dump" "--global" "-v0" "--global-package- > db=C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage1/lib/package.conf.d" > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" > "--print-libdir" "-ghcversion- > file=C:/msys64/home/ben/ghc/builds/0/project-0/_build/generated/ghcversion.h" > CallStack (from HasCallStack): > die', called at .\Distribution\Simple\Configure.hs:969:20 in > Cabal-2.5.0.0-inplace:Distribution.Simple.Configure > configureFinalizedPackage, called at > .\Distribution\Simple\Configure.hs:467:12 in > Cabal-2.5.0.0-inplace:Distribution.Simple.Configure > configure, called at .\Distribution\Simple.hs:596:20 in > Cabal-2.5.0.0-inplace:Distribution.Simple > confHook, called at .\Distribution\Simple\UserHooks.hs:67:5 in > Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks > configureAction, called at .\Distribution\Simple.hs:178:19 in > Cabal-2.5.0.0-inplace:Distribution.Simple > defaultMainHelper, called at .\Distribution\Simple.hs:148:3 in > Cabal-2.5.0.0-inplace:Distribution.Simple > defaultMainWithHooksNoReadArgs, called at > src\Hadrian\Haskell\Cabal\Parse.hs:145:14 in > main:Hadrian.Haskell.Cabal.Parse > hadrian.exe: Encountered missing dependencies: > libiserv ==8.7.* > > }}} > (Ignore garbage characters due to Window's broken ANSI console support) New description: As of {{{ $ hadrian/build.cabal.sh -j5 --flavour=Quick ... $ hadrian/build.cabal.sh -j5 --flavour=Quick | ContextData oracle: resolving data for 'iserv' (Stage1, v)... | Configure package 'iserv' Configuring iserv-8.7.1... creating C:\msys64\home\ben\ghc\builds\0\project-0\_build\stage1\utils\iserv\build "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--numeric-version" ]0;1s (99%)C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe is version 8.7.20181126 "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "--version" C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe is version 8.7.20181126 "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--supported-languages" "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "-- info" Reading installed packages... "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "dump" "--global" "-v0" "--global-package- db=C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage1/lib/package.conf.d" "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--print-libdir" "-ghcversion- file=C:/msys64/home/ben/ghc/builds/0/project-0/_build/generated/ghcversion.h" CallStack (from HasCallStack): die', called at .\Distribution\Simple\Configure.hs:969:20 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configureFinalizedPackage, called at .\Distribution\Simple\Configure.hs:467:12 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configure, called at .\Distribution\Simple.hs:596:20 in Cabal-2.5.0.0-inplace:Distribution.Simple confHook, called at .\Distribution\Simple\UserHooks.hs:67:5 in Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks configureAction, called at .\Distribution\Simple.hs:178:19 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainHelper, called at .\Distribution\Simple.hs:148:3 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainWithHooksNoReadArgs, called at src\Hadrian\Haskell\Cabal\Parse.hs:145:14 in main:Hadrian.Haskell.Cabal.Parse hadrian.exe: Encountered missing dependencies: libiserv ==8.7.* ]0;FinishedshakeArgsWith 0.003s 0% Function shake 0.442s 2% Database read 0.851s 3% = With database 0.033s 0% Running rules 20.749s 93% ========================= Total 22.079s 100% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: test at src/Rules/Test.hs:109:5-9: * Depends on: _build/stage1/lib/bin/ghc-iserv.exe at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Program, pkgName = "iserv", pkgPath = "utils/iserv"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36: * Depends on: _build/stage1/utils/iserv/setup-config * Raised the exception: ExitFailure 1 }}} (Ignore garbage characters due to Window's broken ANSI console support) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 15:05:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 15:05:13 -0000 Subject: [GHC] #15950: Hadrian build fails on Windows In-Reply-To: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> References: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> Message-ID: <061.2ee7ab0a90a3fb9e50fc7a9ecd953c9c@haskell.org> #15950: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: 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: alpmestan, snowleopard (added) Old description: > As of > {{{ > $ hadrian/build.cabal.sh -j5 --flavour=Quick > ... > $ hadrian/build.cabal.sh -j5 --flavour=Quick > | ContextData oracle: resolving data for 'iserv' (Stage1, v)... > | Configure package 'iserv' > Configuring iserv-8.7.1... > creating > C:\msys64\home\ben\ghc\builds\0\project-0\_build\stage1\utils\iserv\build > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" > "--numeric-version" > ]0;1s > (99%)C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe > is version > 8.7.20181126 > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" > "--version" > C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe > is > version 8.7.20181126 > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" > "--supported-languages" > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "-- > info" > Reading installed packages... > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" > "dump" "--global" "-v0" "--global-package- > db=C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage1/lib/package.conf.d" > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" > "--print-libdir" "-ghcversion- > file=C:/msys64/home/ben/ghc/builds/0/project-0/_build/generated/ghcversion.h" > CallStack (from HasCallStack): > die', called at .\Distribution\Simple\Configure.hs:969:20 in > Cabal-2.5.0.0-inplace:Distribution.Simple.Configure > configureFinalizedPackage, called at > .\Distribution\Simple\Configure.hs:467:12 in > Cabal-2.5.0.0-inplace:Distribution.Simple.Configure > configure, called at .\Distribution\Simple.hs:596:20 in > Cabal-2.5.0.0-inplace:Distribution.Simple > confHook, called at .\Distribution\Simple\UserHooks.hs:67:5 in > Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks > configureAction, called at .\Distribution\Simple.hs:178:19 in > Cabal-2.5.0.0-inplace:Distribution.Simple > defaultMainHelper, called at .\Distribution\Simple.hs:148:3 in > Cabal-2.5.0.0-inplace:Distribution.Simple > defaultMainWithHooksNoReadArgs, called at > src\Hadrian\Haskell\Cabal\Parse.hs:145:14 in > main:Hadrian.Haskell.Cabal.Parse > hadrian.exe: Encountered missing dependencies: > libiserv ==8.7.* > ]0;FinishedshakeArgsWith 0.003s 0% > Function shake 0.442s 2% > Database read 0.851s 3% = > With database 0.033s 0% > Running rules 20.749s 93% ========================= > Total 22.079s 100% > Error when running Shake build system: > at src/Main.hs:58:30-42: > * Depends on: test > at src/Rules/Test.hs:109:5-9: > * Depends on: _build/stage1/lib/bin/ghc-iserv.exe > at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: > * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = > Package {pkgType = Program, pkgName = "iserv", pkgPath = "utils/iserv"}, > way = v})) > at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36: > * Depends on: _build/stage1/utils/iserv/setup-config > * Raised the exception: > ExitFailure 1 > > }}} > (Ignore garbage characters due to Window's broken ANSI console support) New description: As of {{{ $ hadrian/build.cabal.sh -j5 --flavour=Quick ... $ hadrian/build.cabal.sh -j5 --flavour=Quick | ContextData oracle: resolving data for 'iserv' (Stage1, v)... | Configure package 'iserv' Configuring iserv-8.7.1... creating C:\msys64\home\ben\ghc\builds\0\project-0\_build\stage1\utils\iserv\build "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--numeric-version" ]0;1s (99%)C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe is version 8.7.20181126 "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "--version" C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe is version 8.7.20181126 "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--supported-languages" "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "-- info" Reading installed packages... "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "dump" "--global" "-v0" "--global-package- db=C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage1/lib/package.conf.d" "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--print-libdir" "-ghcversion- file=C:/msys64/home/ben/ghc/builds/0/project-0/_build/generated/ghcversion.h" CallStack (from HasCallStack): die', called at .\Distribution\Simple\Configure.hs:969:20 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configureFinalizedPackage, called at .\Distribution\Simple\Configure.hs:467:12 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configure, called at .\Distribution\Simple.hs:596:20 in Cabal-2.5.0.0-inplace:Distribution.Simple confHook, called at .\Distribution\Simple\UserHooks.hs:67:5 in Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks configureAction, called at .\Distribution\Simple.hs:178:19 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainHelper, called at .\Distribution\Simple.hs:148:3 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainWithHooksNoReadArgs, called at src\Hadrian\Haskell\Cabal\Parse.hs:145:14 in main:Hadrian.Haskell.Cabal.Parse hadrian.exe: Encountered missing dependencies: libiserv ==8.7.* ]0;FinishedshakeArgsWith 0.003s 0% Function shake 0.442s 2% Database read 0.851s 3% = With database 0.033s 0% Running rules 20.749s 93% ========================= Total 22.079s 100% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: test at src/Rules/Test.hs:109:5-9: * Depends on: _build/stage1/lib/bin/ghc-iserv.exe at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Program, pkgName = "iserv", pkgPath = "utils/iserv"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36: * Depends on: _build/stage1/utils/iserv/setup-config * Raised the exception: ExitFailure 1 }}} (Ignore garbage characters due to Window's broken ANSI console support) -- Comment: Perhaps `iserv` is missing a dependency on `libiserv`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 15:09:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 15:09:55 -0000 Subject: [GHC] #15949: Hadrian needs more convenient build target names In-Reply-To: <046.a0cda9df357797abce34c12980353145@haskell.org> References: <046.a0cda9df357797abce34c12980353145@haskell.org> Message-ID: <061.dfff285fd302902e1576cbf339a1a67c@haskell.org> #15949: Hadrian needs more convenient build target names -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): (Quick side-comment: the CWD-awareness has been requested by Simon Marlow some time ago, but for tests -- https://github.com/snowleopard/hadrian/issues/685) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 15:10:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 15:10:21 -0000 Subject: [GHC] #15950: Hadrian build fails on Windows In-Reply-To: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> References: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> Message-ID: <061.622d2fb2a5e4c5aab98cc4641248e823@haskell.org> #15950: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * os: Unknown/Multiple => Windows Old description: > As of > {{{ > $ hadrian/build.cabal.sh -j5 --flavour=Quick > ... > $ hadrian/build.cabal.sh -j5 --flavour=Quick > | ContextData oracle: resolving data for 'iserv' (Stage1, v)... > | Configure package 'iserv' > Configuring iserv-8.7.1... > creating > C:\msys64\home\ben\ghc\builds\0\project-0\_build\stage1\utils\iserv\build > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" > "--numeric-version" > ]0;1s > (99%)C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe > is version > 8.7.20181126 > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" > "--version" > C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe > is > version 8.7.20181126 > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" > "--supported-languages" > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "-- > info" > Reading installed packages... > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" > "dump" "--global" "-v0" "--global-package- > db=C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage1/lib/package.conf.d" > "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" > "--print-libdir" "-ghcversion- > file=C:/msys64/home/ben/ghc/builds/0/project-0/_build/generated/ghcversion.h" > CallStack (from HasCallStack): > die', called at .\Distribution\Simple\Configure.hs:969:20 in > Cabal-2.5.0.0-inplace:Distribution.Simple.Configure > configureFinalizedPackage, called at > .\Distribution\Simple\Configure.hs:467:12 in > Cabal-2.5.0.0-inplace:Distribution.Simple.Configure > configure, called at .\Distribution\Simple.hs:596:20 in > Cabal-2.5.0.0-inplace:Distribution.Simple > confHook, called at .\Distribution\Simple\UserHooks.hs:67:5 in > Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks > configureAction, called at .\Distribution\Simple.hs:178:19 in > Cabal-2.5.0.0-inplace:Distribution.Simple > defaultMainHelper, called at .\Distribution\Simple.hs:148:3 in > Cabal-2.5.0.0-inplace:Distribution.Simple > defaultMainWithHooksNoReadArgs, called at > src\Hadrian\Haskell\Cabal\Parse.hs:145:14 in > main:Hadrian.Haskell.Cabal.Parse > hadrian.exe: Encountered missing dependencies: > libiserv ==8.7.* > ]0;FinishedshakeArgsWith 0.003s 0% > Function shake 0.442s 2% > Database read 0.851s 3% = > With database 0.033s 0% > Running rules 20.749s 93% ========================= > Total 22.079s 100% > Error when running Shake build system: > at src/Main.hs:58:30-42: > * Depends on: test > at src/Rules/Test.hs:109:5-9: > * Depends on: _build/stage1/lib/bin/ghc-iserv.exe > at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: > * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = > Package {pkgType = Program, pkgName = "iserv", pkgPath = "utils/iserv"}, > way = v})) > at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36: > * Depends on: _build/stage1/utils/iserv/setup-config > * Raised the exception: > ExitFailure 1 > > }}} > (Ignore garbage characters due to Window's broken ANSI console support) New description: As of 509d5be69c7507ba5d0a5f39ffd1613a59e73eea, {{{ $ hadrian/build.cabal.sh -j5 --flavour=Quick ... $ hadrian/build.cabal.sh -j5 --flavour=Quick | ContextData oracle: resolving data for 'iserv' (Stage1, v)... | Configure package 'iserv' Configuring iserv-8.7.1... creating C:\msys64\home\ben\ghc\builds\0\project-0\_build\stage1\utils\iserv\build "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--numeric-version" ]0;1s (99%)C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe is version 8.7.20181126 "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "--version" C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe is version 8.7.20181126 "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--supported-languages" "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "-- info" Reading installed packages... "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "dump" "--global" "-v0" "--global-package- db=C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage1/lib/package.conf.d" "C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--print-libdir" "-ghcversion- file=C:/msys64/home/ben/ghc/builds/0/project-0/_build/generated/ghcversion.h" CallStack (from HasCallStack): die', called at .\Distribution\Simple\Configure.hs:969:20 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configureFinalizedPackage, called at .\Distribution\Simple\Configure.hs:467:12 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure configure, called at .\Distribution\Simple.hs:596:20 in Cabal-2.5.0.0-inplace:Distribution.Simple confHook, called at .\Distribution\Simple\UserHooks.hs:67:5 in Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks configureAction, called at .\Distribution\Simple.hs:178:19 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainHelper, called at .\Distribution\Simple.hs:148:3 in Cabal-2.5.0.0-inplace:Distribution.Simple defaultMainWithHooksNoReadArgs, called at src\Hadrian\Haskell\Cabal\Parse.hs:145:14 in main:Hadrian.Haskell.Cabal.Parse hadrian.exe: Encountered missing dependencies: libiserv ==8.7.* ]0;FinishedshakeArgsWith 0.003s 0% Function shake 0.442s 2% Database read 0.851s 3% = With database 0.033s 0% Running rules 20.749s 93% ========================= Total 22.079s 100% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: test at src/Rules/Test.hs:109:5-9: * Depends on: _build/stage1/lib/bin/ghc-iserv.exe at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Program, pkgName = "iserv", pkgPath = "utils/iserv"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36: * Depends on: _build/stage1/utils/iserv/setup-config * Raised the exception: ExitFailure 1 }}} (Ignore garbage characters due to Window's broken ANSI console support). This seems to only be reproducible on Windows. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 15:14:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 15:14:55 -0000 Subject: [GHC] #15950: Hadrian build fails on Windows In-Reply-To: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> References: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> Message-ID: <061.a7eb3a0aeda412dba90ddd3b01683764@haskell.org> #15950: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I see, `Settings.Default.stage1Packages` conditions both `iserv` and `libiserv` on the platform not being Windows. However, then `Rules.Test.needIservBins` depends upon `iserv` regardless. This all seems terribly fragile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 15:26:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 15:26:31 -0000 Subject: [GHC] #15951: Hadrian test doesn't show testsuite output by default Message-ID: <046.57d11012bb84dc1c7806406ef10199fe@haskell.org> #15951: Hadrian test doesn't show testsuite output by default -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | 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 running `hadrian test` the user sees no indication that the build system is actually doing anything beyond the furious whirring of their CPU fan. Once the testsuite finishes Hadrian kindly informs the user that the testsuite passed or failed, but provides no additional feedback on what failed or where the output can be found. We should just print all testsuite output to stdout, as the `make` build system does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 15:30:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 15:30:24 -0000 Subject: [GHC] #15951: Hadrian test doesn't show testsuite output by default In-Reply-To: <046.57d11012bb84dc1c7806406ef10199fe@haskell.org> References: <046.57d11012bb84dc1c7806406ef10199fe@haskell.org> Message-ID: <061.77a7b6ecb414e4395e88347929ce4487@haskell.org> #15951: Hadrian test doesn't show testsuite output by default -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): One can force the testsuite output to be produced by passing hadrian the `--verbose` flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 16:12:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 16:12:26 -0000 Subject: [GHC] #15950: Hadrian build fails on Windows In-Reply-To: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> References: <046.847ca845a5a441f0d10915cb21c39004@haskell.org> Message-ID: <061.1cc3e66b85454e14fe6d0964aaecebe0@haskell.org> #15950: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5381 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5381 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 16:20:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 16:20:45 -0000 Subject: [GHC] #15952: Reduce zonking-related invariants in the type checker Message-ID: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> #15952: Reduce zonking-related invariants in the type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 type checker currently maintains two invariants, documented in `Note [The well-kinded type invariant]` in TcType and `Note [The tcType invariant]` in TcHsType. These are a pain to maintain, and Simon and I cooked up a plan not to. Step 1. The tcType invariant is all about `tcInferApps`, at least according to the Note. Previously, we couldn't zonk in `tcInferApps`, because types were knot-tied. But now we can! So, `tcInferApps` could take the type only (not its kind), zonk it, then get the type's (zonked) kind. This might also mean that `tc_infer_hs_type` no longer needs to return a type/kind pair, but could just return a type. After this is done, we can likely remove all the zonks that are in service to the tcType invariant, findable by a search. Step 2. The well-kinded type invariant is also about the need to zonk sometimes. But, instead, we could just always zonk on-the-fly. That is, we introduce new functions like `tcTypeKind` and `tcSubstTy` that zonk as they go. To make sure we're calling the right function at the right time, we introduce `newtype TcType = TcType { unTcType :: Type }`. Then, we're forced to call monadic functions on `TcType`s. This will likely lead to code duplication between `Type` and `TcType`, but we might be able to banish `zonkTcType` (and its many friends) entirely. Also gone would be the `naked` functions, which are all about maintaining the well-kinded type invariant. This step would, as a side effect, fix #15799 and #15918, which is about treating `TcType`s differently from `Type`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 16:53:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 16:53:15 -0000 Subject: [GHC] #15953: GHC always dumps the output of -ddump-hpc to STDOUT Message-ID: <048.f3a0e06abcd2b5b6e46368df0dc20149@haskell.org> #15953: GHC always dumps the output of -ddump-hpc to STDOUT -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Instead, it should write the output to a file if `-ddump-to-file` is enabled. `-ddump-core-stats` also has a similar problem. But given that it always prints just one line, maybe it should continue to print to `STDOUT`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 16:55:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 16:55:10 -0000 Subject: [GHC] #15953: GHC always dumps the output of -ddump-hpc to STDOUT In-Reply-To: <048.f3a0e06abcd2b5b6e46368df0dc20149@haskell.org> References: <048.f3a0e06abcd2b5b6e46368df0dc20149@haskell.org> Message-ID: <063.f2768a188932778b292ef1305771653d@haskell.org> #15953: GHC always dumps the output of -ddump-hpc to STDOUT -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5382 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * status: new => patch * differential: => Phab:D5382 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 17:52:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 17:52:38 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.fe4a49b2d9cf16c3e46a415ff450d7fa@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: | Keywords: 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 snowleopard): * cc: snowleopard (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 17:54:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 17:54:03 -0000 Subject: [GHC] #15936: Rethink Choice of Baseline Commit for Performance Tests In-Reply-To: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> References: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> Message-ID: <060.00ef57b67036b43354435ede445ec14a@haskell.org> #15936: Rethink Choice of Baseline Commit for Performance Tests -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git 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: | -------------------------------------+------------------------------------- Description changed by davide: Old description: > = Intro = > > Currently we always use the previous commit when running performance > tests. This works well in CI where we fully test each commit in sequence > (and hence always have test results for the previous commit). Remember, > test results are stored in git notes and are not by default shared > between repositories (i.e. your local repo will only have performance > results when they were run locally on your machine). This is by design: > we want to avoid comparing results form different machines. > > Unfortunately This is not so effective when testing locally. The > programmer may have only run a subset of performance tests on the > previous commit, and often have not run the tests at all (this is notably > true after performing a rebase: the previous commit has changed). We need > to rethink how we pick a baseline commit. > > = Goals = > > * In all cases, do something sensible. > * Giving a warning if conditions are not idea. Provide clear and simple > instructions on how to get to the ideal case. > * Give control over the baseline commit to the programmer via command > line options. > * Could make it a baseline branch where we still do git merge-base. > That would be useful if you are branching from a different branch than > master. > * Give control over the baseline of local or ci to the programmer via > command line options. > * In general, performance tests should just work! No extra knowledge > needed by the programmer. > * If tests pass without warning now, then they should pass without > warning later. > > = Proposed Solution = > > * When running performance tests, results will be compared to a baseline > commit that is the merge base with master (most recent commit from > master). If HEAD is already in master, then the previous commit is used > instead. > * If any locally generated performance results exist, they are used > exclusively for the baseline. > * Else if any CI generated performance results exist (and have been > fetched), they are used exclusively for the baseline. > * Else performance tests trivially pass, and a warning is given to the > user. > > To find the baseline commit: > {{{ > mergeBase = merge-base master HEAD > baselineCommit = if mergeBase == HEAD > then HEAD^ > else mergeBase > }}} > > == Reasoning == > > * We want each commit in master not to introduce a significant change in > performance: hence we compare commits in mater to the previous commit. > * If not on master (1 or more ahead and 0 or more commits behind master). > We assume that the intention is to create a patch where all new commits > will ultimately be squashed and placed on top of master as a single > commit. On the other hand we don't want to consider changes in master > from after we branched. Instead of using master HEAD as the baseline, we > use the commit from which we branched from master (i.e. the merge base). > In other words we are concerned only with the change in performance > introduced by the newly crated commits. > > = Handling Expected changes = > > TODO this is the complicated part. What happens when the programmer is > not planning on squashing commits and has many commits with expected > changes :-( > > See > [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests#ExpectedPerformanceChanges > expected performance changes]. > > If on master or an ancestor commit, the baseline is the previous commit > and we can simply allow performance changes as specified in the current > commit's message (this is already the behaviour of the test driver). > > If we have branched from master, then we may have multiple commits from > the baseline commit to HEAD, each of which may have, possibly > contradictory, expected performance changes. If any expected changes > exist, aggregate them. We introduce an explicit "Metric Unchanged" option > and aggregate per test where newer allowed changes overwrite older > allowed changes. "Metric Unchanged" is necessary in the case that a new > commit undoes a performance change such that a metric returns to the > baseline value. The aggregate version should be output so that the > programmer knows what to put in the commit message after squashing the > commits. A warning should be given if expected changes appear in any > commit inbetween HEAD and the baseline commit. In that warning Suggest > e.g. "--baseline HEAD^ if not planning on squashing this commit" > > == Reasoning == > > creating new commits with expected changes is an interactive process. The > programmer adds a 1 or more commits, runs the tests, then adds expected > performance changes to a commit message. It would be too inconvenient to > force the programmer to change old commit messages, and too > verbose/annoying to have them enter a full list of expected changes in > each commit. Hence we must aggregate the expected changes. > > This is of a bit risky as it is a context sensitive change in the > semantics of expected changes. If we e.g. intend not to squash the > commits, then all the sudden the expected changes mean something very > different (change to the previous commit, not some distant baseline > commit). Perhaps we just show a warning in this case. > > We must figure out what commit messages will be used in GitLab on merge. > Does the programmer have to remember to sort out expected changes before > merge some how? > > = Use cases = > > * We do not distinguish between full/partial performance results being > available for the baseline commit: that would require checking out the > baseline commit and extracting the full list of tests. > * > > || BaselinelocalResults || BaselineCIResults || Infos || Warnings || > > ||||||= Case =||||||= Behaviour =|| > ||= Platform =||= Baseline local Results? =||= Baseline CI Results? =||= > Baseline local/CI =||= Infos =||= Warnings =|| > || Local || Yes/Partial || - || Local || If HEAD tests is not subset or > eq to Baseline tests: "If relevant tests exist on baseline, checkout > baseline and running those tests OR fetch notes and use --baseline-ci || > || > || Local || No || Yes || CI || "Using CI numbers, suggest running locally > for more accurate results" || || > || Local || No || No || - || || "No baseline results, tests trivially > pass" + suggest fetch notes or locally run tests on baseline || > || CI |||| Yes || CI || || || > || CI |||| No || - || || "No results. CI is not yet finished, or CI has > failed for the baseline commit or CI hasn’t fetched" || > > = When to automatically fetch CI results? = > > Fetch if: > * Testing locally (not a ci run) AND > * Baseline commit doesn't have local nor CI results (before fetch) AND > * Baseline commit is an ancestor of master. > If fetching, suggest a command line option: --no-fetch. > This is most convenient for local testing avoids fetch on ci, but may > result in unwanted/wasted fetches New description: = Intro = Currently we always use the previous commit when running performance tests. This works well in CI where we fully test each commit in sequence (and hence always have test results for the previous commit). Remember, test results are stored in git notes and are not by default shared between repositories (i.e. your local repo will only have performance results when they were run locally on your machine). This is by design: we want to avoid comparing results form different machines. Unfortunately This is not so effective when testing locally. The programmer may have only run a subset of performance tests on the previous commit, and often have not run the tests at all (this is notably true after performing a rebase: the previous commit has changed). We need to rethink how we pick a baseline commit. = Goals = * In all cases, do something sensible. * Giving a warning if conditions are not idea. Provide clear and simple instructions on how to get to the ideal case. * Give control over the baseline commit to the programmer via command line options. * Could make it a baseline branch where we still do git merge-base. That would be useful if you are branching from a different branch than master. * Give control over the baseline of local or ci to the programmer via command line options. * In general, performance tests should just work! No extra knowledge needed by the programmer. * If tests pass without warning now, then they should pass without warning later. = Proposed Solution 1 = * Per test use baseline of closest ancestor commit's metric (favour local as opposed to CI metrics). aggregate expected changes, but skip tests with both expected increase and decrease. * If anything other than local metrics from previous commit were used, show a warning suggesting running tests on previous commit. * Stop search if a CI commit is found (these are assumed to be complete) or if searched an arbitrary number of commits e.g. 100 (this is important as we'll end up searching whole history if a new test was added). = Proposed Solution 2 = * When running performance tests, results will be compared to a baseline commit that is the merge base with master (most recent commit from master). If HEAD is already in master, then the previous commit is used instead. * If any locally generated performance results exist, they are used exclusively for the baseline. * Else if any CI generated performance results exist (and have been fetched), they are used exclusively for the baseline. * Else performance tests trivially pass, and a warning is given to the user. To find the baseline commit: {{{ mergeBase = merge-base master HEAD baselineCommit = if mergeBase == HEAD then HEAD^ else mergeBase }}} == Reasoning == * We want each commit in master not to introduce a significant change in performance: hence we compare commits in mater to the previous commit. * If not on master (1 or more ahead and 0 or more commits behind master). We assume that the intention is to create a patch where all new commits will ultimately be squashed and placed on top of master as a single commit. On the other hand we don't want to consider changes in master from after we branched. Instead of using master HEAD as the baseline, we use the commit from which we branched from master (i.e. the merge base). In other words we are concerned only with the change in performance introduced by the newly crated commits. = Handling Expected changes = TODO this is the complicated part. What happens when the programmer is not planning on squashing commits and has many commits with expected changes :-( See [https://ghc.haskell.org/trac/ghc/wiki/Performance/Tests#ExpectedPerformanceChanges expected performance changes]. If on master or an ancestor commit, the baseline is the previous commit and we can simply allow performance changes as specified in the current commit's message (this is already the behaviour of the test driver). If we have branched from master, then we may have multiple commits from the baseline commit to HEAD, each of which may have, possibly contradictory, expected performance changes. If any expected changes exist, aggregate them. We introduce an explicit "Metric Unchanged" option and aggregate per test where newer allowed changes overwrite older allowed changes. "Metric Unchanged" is necessary in the case that a new commit undoes a performance change such that a metric returns to the baseline value. The aggregate version should be output so that the programmer knows what to put in the commit message after squashing the commits. A warning should be given if expected changes appear in any commit inbetween HEAD and the baseline commit. In that warning Suggest e.g. "--baseline HEAD^ if not planning on squashing this commit" == Reasoning == creating new commits with expected changes is an interactive process. The programmer adds a 1 or more commits, runs the tests, then adds expected performance changes to a commit message. It would be too inconvenient to force the programmer to change old commit messages, and too verbose/annoying to have them enter a full list of expected changes in each commit. Hence we must aggregate the expected changes. This is of a bit risky as it is a context sensitive change in the semantics of expected changes. If we e.g. intend not to squash the commits, then all the sudden the expected changes mean something very different (change to the previous commit, not some distant baseline commit). Perhaps we just show a warning in this case. We must figure out what commit messages will be used in GitLab on merge. Does the programmer have to remember to sort out expected changes before merge some how? = Use cases = * We do not distinguish between full/partial performance results being available for the baseline commit: that would require checking out the baseline commit and extracting the full list of tests. * || BaselinelocalResults || BaselineCIResults || Infos || Warnings || ||||||= Case =||||||= Behaviour =|| ||= Platform =||= Baseline local Results? =||= Baseline CI Results? =||= Baseline local/CI =||= Infos =||= Warnings =|| || Local || Yes/Partial || - || Local || If HEAD tests is not subset or eq to Baseline tests: "If relevant tests exist on baseline, checkout baseline and running those tests OR fetch notes and use --baseline-ci || || || Local || No || Yes || CI || "Using CI numbers, suggest running locally for more accurate results" || || || Local || No || No || - || || "No baseline results, tests trivially pass" + suggest fetch notes or locally run tests on baseline || || CI |||| Yes || CI || || || || CI |||| No || - || || "No results. CI is not yet finished, or CI has failed for the baseline commit or CI hasn’t fetched" || = When to automatically fetch CI results? = Fetch if: * Testing locally (not a ci run) AND * Baseline commit doesn't have local nor CI results (before fetch) AND * Baseline commit is an ancestor of master. If fetching, suggest a command line option: --no-fetch. This is most convenient for local testing avoids fetch on ci, but may result in unwanted/wasted fetches -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 18:32:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 18:32:11 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in Message-ID: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC accepts this program: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where import GHC.Exts (Any) type KindOf (a :: k) = k type A a = (Any :: a) type KA = KindOf A }}} But it really oughtn't to. After all, we have an unsaturated use of `A` in `KindOf A`, and we don't have `LiberalTypeSynonyms` enabled! What's even stranger is that there seems to be something about this exact setup that sneaks by `LiberalTypeSynonyms`' validity checks. If I add another argument to `A`: {{{#!hs type A x a = (Any :: a) }}} Then it //does// error: {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:10:1: error: • Illegal polymorphic type: forall a -> a Perhaps you intended to use LiberalTypeSynonyms • In the type synonym declaration for ‘KA’ | 10 | type KA = KindOf A | ^^^^^^^^^^^^^^^^^^ }}} Similarly, if I use something besides `KindOf`: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Bug where import GHC.Exts (Any) type A a = (Any :: a) type B a = Int type C = B A }}} Then I also get the same `Illegal polymorphic type: forall a -> a` error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 18:57:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 18:57:23 -0000 Subject: [GHC] #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) In-Reply-To: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> References: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> Message-ID: <065.ee52d9e108a66bd067cb76e19fec9b0c@haskell.org> #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 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): Phab:D5282 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"f932b1aa42f45625658c8abaf862cc570507c5ca/ghc" f932b1a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f932b1aa42f45625658c8abaf862cc570507c5ca" Print explicit foralls in type family eqns when appropriate Summary: When `-fprint-explicit-foralls` is enabled, type family equations are either printed without an explict `forall` entirely, or with a bizarre square bracket syntax (in the case of closed type families). I find neither satisfying, so in this patch, I introduce support for printing explicit `forall`s in open type-family, closed type-family, and data-family equations when appropriate. (By "when appropriate", I refer to the conditions laid out in `Note [When to print foralls]` in `IfaceType`.) One tricky point in the implementation is that I had to pick a visibility for each type variable in a `CoAxiom`/`FamInst` in order to be able to pass it to `pprUserIfaceForAll` //et al.// Because the type variables in a type family instance equation can't be instantiated by the programmer anyway, the choice only really matters for pretty-printing purposes, so I simply went with good ol' trustworthy `Specified`. (This design choice is documented in `Note [Printing foralls in type family instances]` in `IfaceType`.) Test Plan: make test TEST=T15827 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15827 Differential Revision: https://phabricator.haskell.org/D5282 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 18:57:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 18:57:23 -0000 Subject: [GHC] #15866: libiserv's version number is hard-coded In-Reply-To: <050.a6c32e24dcc226a38ba3ddc82a7fdbd6@haskell.org> References: <050.a6c32e24dcc226a38ba3ddc82a7fdbd6@haskell.org> Message-ID: <065.6817d77bb5c3f75660eba3f8381e5f8e@haskell.org> #15866: libiserv's version number is hard-coded -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5302 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"8f9f52d8e421ce544d5437a93117545d52d0eabd/ghc" 8f9f52d8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f9f52d8e421ce544d5437a93117545d52d0eabd" Use autoconf to generate version numbers for libiserv and friends Summary: Currently, the version numbers for `libiserv`, `iserv`, and `iserv-proxy` are hard-coded directly into their `.cabal` files. These are easy to forget to update, and in fact, this has already happened once (see #15866). Let's use `autoconf` to do this for us so that it is not forgotten in the future. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, erikd, carter GHC Trac Issues: #15866 Differential Revision: https://phabricator.haskell.org/D5302 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 18:57:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 18:57:23 -0000 Subject: [GHC] #15941: Pretty-printing of invisible arguments to (->) In-Reply-To: <047.398646946505bae0b9a71adeab6b5eee@haskell.org> References: <047.398646946505bae0b9a71adeab6b5eee@haskell.org> Message-ID: <062.063ca05ecfdbea8355d427507b7a3379@haskell.org> #15941: Pretty-printing of invisible arguments to (->) -------------------------------------+------------------------------------- Reporter: monoidal | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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:D5375 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"984b75de7082689ebcc6e9d17b37f2c9b3702f71/ghc" 984b75de/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="984b75de7082689ebcc6e9d17b37f2c9b3702f71" Fix #15941 by only special-casing visible infix applications Summary: The iface pretty-printer had a special case for an application of an infix type constructor to two arguments. But this didn't take the visibilities of the arguments into account, which could lead to strange output like `@{LiftedRep} -> @{LiftedRep}` when `-fprint-explicit-kinds` was enabled (#15941). The fix is relatively straightforward: simply plumb through the visibilities of each argument, and only trigger the special case for infix applications if both arguments are visible (i.e., required). Test Plan: make test TEST=T15941 Reviewers: goldfire, bgamari, monoidal Reviewed By: goldfire, monoidal Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15941 Differential Revision: https://phabricator.haskell.org/D5375 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 18:59:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 18:59:51 -0000 Subject: [GHC] #15866: libiserv's version number is hard-coded In-Reply-To: <050.a6c32e24dcc226a38ba3ddc82a7fdbd6@haskell.org> References: <050.a6c32e24dcc226a38ba3ddc82a7fdbd6@haskell.org> Message-ID: <065.55eefd63ecfcc59d18ee9dedf6aded68@haskell.org> #15866: libiserv's version number is hard-coded -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5302 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * milestone: => 8.6.3 Comment: Could me merged (if convenient). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 19:00:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 19:00:40 -0000 Subject: [GHC] #15941: Pretty-printing of invisible arguments to (->) In-Reply-To: <047.398646946505bae0b9a71adeab6b5eee@haskell.org> References: <047.398646946505bae0b9a71adeab6b5eee@haskell.org> Message-ID: <062.441a3c1b2d2a0ee4089cb22dfd19423f@haskell.org> #15941: Pretty-printing of invisible arguments to (->) -------------------------------------+------------------------------------- Reporter: monoidal | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T15941 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5375 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => ghci/scripts/T15941 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 19:01:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 19:01:52 -0000 Subject: [GHC] #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) In-Reply-To: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> References: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> Message-ID: <065.a7e0220f9bfc14155c42a42254431252@haskell.org> #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T15827 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5282 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => ghci/scripts/T15827 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 19:43:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 19:43:01 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.1dcc68092d05d42330f43b8a8a1156ff@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 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): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > In Trac #14346 we proposed the new `with#` primop > {{{#hs > with# :: a -> (State# s -> (# State# s, b #)) -> State# s -> (# State# s, > b #) > }}} > This ticket is to track progress. > > See ​Phab:D4110. New description: In Trac #14346 we proposed the new `with#` primop {{{#!hs with# :: a -> (State# s -> (# State# s, b #)) -> State# s -> (# State# s, b #) }}} This ticket is to track progress. See ​Phab:D4110. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 20:35:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 20:35:31 -0000 Subject: [GHC] #15896: GHC API: add function to allow looking up Name for Located RdrName In-Reply-To: <044.aff719817112fa9706a5e690b6a4722f@haskell.org> References: <044.aff719817112fa9706a5e690b6a4722f@haskell.org> Message-ID: <059.6849d6d7575c6d898b96e4d8537ee5be@haskell.org> #15896: GHC API: add function to allow looking up Name for Located RdrName -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 8.6.3 Component: GHC API | Version: 8.6.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:D5330 Wiki Page: ApiNameMap | -------------------------------------+------------------------------------- Changes (by alanz): * wikipage: => ApiNameMap -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 21:32:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 21:32:30 -0000 Subject: [GHC] #15955: Cannot get debugging symbols for compiled c-sources Message-ID: <042.4247b6eb19a9be164ea978944f4cfb58@haskell.org> #15955: Cannot get debugging symbols for compiled c-sources -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 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: -------------------------------------+------------------------------------- I cannot for my life figure out how to pass `-g` to some cabal-file `c-sources`'s compilation. I've tried putting various combinations into `ghc-options`, but for the cases where compilation runs through, debugging symbols are not present, and for all other cases the assembler crashes, with the message as shown in my little survey of flags and whether they end up at `as` (as determined via `strace`): {{{ Using ghc-8.2.2 -g -optc-g -opta-g -optc-Wa,-g -opta-Wa,-g passes -g to as -g -optc-g -opta-g -optc-Wa,-g does not pass -g to as -g -optc-g -opta-g -opta-Wa,-g passes -g to as -optc-g -opta-g -opta-Wa,-g does not pass -g to as -g -opta-g -opta-Wa,-g passes --gdwarf2 and -g to as -g -opta-Wa,-g passes -g to as (and no --gdwarf2) -g -opta-g passes --gdwarf2 to as, but no -g However, in all 3 cases above the build fails with /tmp/ghc6595_0/ghc_4.s:444:0: error: Error: file number 1 already allocated | 444 | .file 1 "src/Codec/Compression/LZ4/Conduit.hsc" | ^ `gcc' failed in phase `Assembler'. (Exit code: 1) }}} (copied from https://gist.github.com/nh2/b57ed4c419f7b13d7cc299caa335f3ab) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 21:33:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 21:33:50 -0000 Subject: [GHC] #15955: Cannot get debugging symbols for compiled c-sources In-Reply-To: <042.4247b6eb19a9be164ea978944f4cfb58@haskell.org> References: <042.4247b6eb19a9be164ea978944f4cfb58@haskell.org> Message-ID: <057.fa504ae19b442c8f8c949557525ac3f4@haskell.org> #15955: Cannot get debugging symbols for compiled c-sources -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.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 nh2: Old description: > I cannot for my life figure out how to pass `-g` to some cabal-file > `c-sources`'s compilation. > > I've tried putting various combinations into `ghc-options`, but for the > cases where compilation runs through, debugging symbols are not present, > and for all other cases the assembler crashes, with the message as shown > in my little survey of flags and whether they end up at `as` (as > determined via `strace`): > > {{{ > Using ghc-8.2.2 > > -g -optc-g -opta-g -optc-Wa,-g -opta-Wa,-g > passes -g to as > > -g -optc-g -opta-g -optc-Wa,-g > does not pass -g to as > > -g -optc-g -opta-g -opta-Wa,-g > passes -g to as > > -optc-g -opta-g -opta-Wa,-g > does not pass -g to as > > -g -opta-g -opta-Wa,-g > passes --gdwarf2 and -g to as > > -g -opta-Wa,-g > passes -g to as (and no --gdwarf2) > > -g -opta-g > passes --gdwarf2 to as, but no -g > > However, in all 3 cases above the build fails with > > /tmp/ghc6595_0/ghc_4.s:444:0: error: > Error: file number 1 already allocated > | > 444 | .file 1 "src/Codec/Compression/LZ4/Conduit.hsc" > | ^ > `gcc' failed in phase `Assembler'. (Exit code: 1) > }}} > > (copied from > https://gist.github.com/nh2/b57ed4c419f7b13d7cc299caa335f3ab) New description: I cannot for my life figure out how to pass `-g` to some cabal-file `c-sources`'s compilation. I've tried putting various combinations into `ghc-options`, but for the cases where compilation runs through, debugging symbols are not present, and for all other cases the assembler crashes, with the message as shown in my little survey of flags and whether they end up at `as` (as determined via `strace`): {{{ Using ghc-8.2.2 -g -optc-g -opta-g -optc-Wa,-g -opta-Wa,-g passes -g to as -g -optc-g -opta-g -optc-Wa,-g does not pass -g to as -g -optc-g -opta-g -opta-Wa,-g passes -g to as -optc-g -opta-g -opta-Wa,-g does not pass -g to as -g -opta-g -opta-Wa,-g passes --gdwarf2 and -g to as -g -opta-Wa,-g passes -g to as (and no --gdwarf2) -g -opta-g passes --gdwarf2 to as, but no -g However, in all the last 3 cases above where some form of -g is passed, the build fails with /tmp/ghc6595_0/ghc_4.s:444:0: error: Error: file number 1 already allocated | 444 | .file 1 "src/Codec/Compression/LZ4/Conduit.hsc" | ^ `gcc' failed in phase `Assembler'. (Exit code: 1) }}} (copied from https://gist.github.com/nh2/b57ed4c419f7b13d7cc299caa335f3ab) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 21:39:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 21:39:38 -0000 Subject: [GHC] #15955: Cannot get debugging symbols for compiled c-sources In-Reply-To: <042.4247b6eb19a9be164ea978944f4cfb58@haskell.org> References: <042.4247b6eb19a9be164ea978944f4cfb58@haskell.org> Message-ID: <057.516b83628c53f997d5c088261c8077a8@haskell.org> #15955: Cannot get debugging symbols for compiled c-sources -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.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 nh2): Contents of the file it complains about (`ghc_4.s` equivalent from another run): https://gist.github.com/nh2/b57ed4c419f7b13d7cc299caa335f3ab/raw/704d054726bf18eba4f1710bfb38f460f9a53dc3/ghc_9.s -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 21:42:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 21:42:10 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.0086e144ae1b72b2429374ec8138931a@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:02:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:02:53 -0000 Subject: [GHC] #15948: Hadrian build fails on Windows when invoked without --configure flag (was: Hadrian cannot build on Windows) In-Reply-To: <046.fad7028de08314594b0d21c085af049c@haskell.org> References: <046.fad7028de08314594b0d21c085af049c@haskell.org> Message-ID: <061.366d356b7209a006f80e10ed153e1967@haskell.org> #15948: Hadrian build fails on Windows when invoked without --configure flag -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:21:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:21:12 -0000 Subject: [GHC] #15951: Hadrian test doesn't show testsuite output by default In-Reply-To: <046.57d11012bb84dc1c7806406ef10199fe@haskell.org> References: <046.57d11012bb84dc1c7806406ef10199fe@haskell.org> Message-ID: <061.666f6f70cb03b3b285975667f6f840af@haskell.org> #15951: Hadrian test doesn't show testsuite output by default -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): I think the following should fix this (sorry for not doing a proper Phab patch): https://github.com/ghc/ghc/pull/231 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:27:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:27:14 -0000 Subject: [GHC] #10803: New SignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.c9f57541ee4dd358b459eedce19bc1f6@haskell.org> #10803: New SignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1185 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => Comment: It's not clear to me what the status of this is but it certainly isn't going to make 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:29:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:29:45 -0000 Subject: [GHC] #10844: CallStack should not be inlined In-Reply-To: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> References: <046.c5d6c4205be9804afd3acc1b71ee4c7b@haskell.org> Message-ID: <061.282830dc67a2bb32f2d58f256160be83@haskell.org> #10844: CallStack should not be inlined -------------------------------------+------------------------------------- Reporter: nomeata | Owner: gridaphobe Type: task | Status: patch Priority: normal | Milestone: 8.10.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.8.1 => 8.10.1 Comment: This will not be happening for 8.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:30:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:30: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.a1fef88143dbc971f1e651c485b12a96@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: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: numa cache gc | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4679 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => Comment: This will certainly need more measurement before we do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:31:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:31:30 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.192f5dbf098e3e0529d69c3acd70cf30@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.10.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: #10365, #15566 | Differential Rev(s): Phab:D4812 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.10.1 Comment: This won't happen for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:32:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:32:11 -0000 Subject: [GHC] #14190: Typeable imposes seemingly redundant constraints on polykinded instances In-Reply-To: <045.10ac00c982131e42012d99b318054ca4@haskell.org> References: <045.10ac00c982131e42012d99b318054ca4@haskell.org> Message-ID: <060.ddb6c9aca91a20e13256c81ed5c6b5e0@haskell.org> #14190: Typeable imposes seemingly redundant constraints on polykinded instances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4000 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.10.1 Comment: This won't happen for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:33:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:33:49 -0000 Subject: [GHC] #15953: GHC always dumps the output of -ddump-hpc to STDOUT In-Reply-To: <048.f3a0e06abcd2b5b6e46368df0dc20149@haskell.org> References: <048.f3a0e06abcd2b5b6e46368df0dc20149@haskell.org> Message-ID: <063.2c000b2bc01391baca98554fc123a4a4@haskell.org> #15953: GHC always dumps the output of -ddump-hpc to STDOUT -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.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:D5382 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:34:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:34:45 -0000 Subject: [GHC] #14534: Split T12971 into its own Makefile In-Reply-To: <045.dc9d469c7c661699270f66b7951e0a7a@haskell.org> References: <045.dc9d469c7c661699270f66b7951e0a7a@haskell.org> Message-ID: <060.b4c5fc440ae59417851c8d1398210030@haskell.org> #14534: Split T12971 into its own Makefile -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: closed Priority: low | Milestone: 8.8.1 Component: Test Suite | Version: 8.2.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4252 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:35:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:35:27 -0000 Subject: [GHC] #15706: Refactor NewHsTypeX to DerivedCoreTy In-Reply-To: <048.615ef91cfcf1df961a2a5b13d5c701f2@haskell.org> References: <048.615ef91cfcf1df961a2a5b13d5c701f2@haskell.org> Message-ID: <063.c15e4eeb818793190eac36eb06d18b18@haskell.org> #15706: Refactor NewHsTypeX to DerivedCoreTy -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: patch Priority: low | Milestone: 8.10.1 Component: Compiler | Version: 8.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): Phab:D5205 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.10.1 Comment: This won't happen for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:36:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:36:01 -0000 Subject: [GHC] #15484: MultiLayerModules and T13701 timeout on i386 Linux In-Reply-To: <046.f49e8907dc2fd082faa408fb71333802@haskell.org> References: <046.f49e8907dc2fd082faa408fb71333802@haskell.org> Message-ID: <061.4738431dcb5a6f0e5d21086a6ec4eed4@haskell.org> #15484: MultiLayerModules and T13701 timeout on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5103 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.8.1 => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:36:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:36:32 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.3cd2cc8ad153f58519680de947024b34@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.8.1 => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:37:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:37:02 -0000 Subject: [GHC] #15185: Enum instance for IntX / WordX are inefficient In-Reply-To: <045.8d849a48d67b73f64eaab8f541972e7c@haskell.org> References: <045.8d849a48d67b73f64eaab8f541972e7c@haskell.org> Message-ID: <060.154f7e5352a9cfeeac1f39eac835071b@haskell.org> #15185: Enum instance for IntX / WordX are inefficient -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Core Libraries | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4820 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.10.1 Comment: This won't happen for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:37:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:37:24 -0000 Subject: [GHC] #15117: Add linting checks for DWARF unwind information In-Reply-To: <046.99e1d9bddf61dd7d8326fcca5a52c63d@haskell.org> References: <046.99e1d9bddf61dd7d8326fcca5a52c63d@haskell.org> Message-ID: <061.cb3e81f8c272df124606317aa4a22edb@haskell.org> #15117: Add linting checks for DWARF unwind information -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.10.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): Phab:D4559 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.10.1 Comment: niteria, how is this coming along? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:37:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:37:43 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings In-Reply-To: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> References: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> Message-ID: <061.079dbdc1f6b83dd902fd3c16cfb3ce1b@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4717 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.10.1 Comment: Bumping to 8.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:38:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:38:40 -0000 Subject: [GHC] #14534: Split T12971 into its own Makefile In-Reply-To: <045.dc9d469c7c661699270f66b7951e0a7a@haskell.org> References: <045.dc9d469c7c661699270f66b7951e0a7a@haskell.org> Message-ID: <060.09db0be56618f335b490bf95c52bc0cc@haskell.org> #14534: Split T12971 into its own Makefile -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: closed Priority: low | Milestone: 8.8.1 Component: Test Suite | Version: 8.2.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4252 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Why WONTFIX? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:38:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:38:53 -0000 Subject: [GHC] #15732: getArgsWithResponseFiles does not filter out RTS options In-Reply-To: <048.b4d2648ba00dd69525e93686e30914e8@haskell.org> References: <048.b4d2648ba00dd69525e93686e30914e8@haskell.org> Message-ID: <063.246835cc1f15db0bd8772e13458f73a4@haskell.org> #15732: getArgsWithResponseFiles does not filter out RTS options -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: libraries/base | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 15072 Related Tickets: #13896 | Differential Rev(s): Phab:D5280 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.10.1 Comment: This won't be wrapped up for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:40:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:40:26 -0000 Subject: [GHC] #15812: add System.Mem.Address to base In-Reply-To: <045.b345df82d6f6da10bcf57adbf4aa903f@haskell.org> References: <045.b345df82d6f6da10bcf57adbf4aa903f@haskell.org> Message-ID: <060.52fc273477ddb7370dad91652936c33b@haskell.org> #15812: add System.Mem.Address to base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: libraries/base | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5268 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.10.1 Comment: carter, where is the discussion for this? Regardless, this won't happen for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:40:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:40:50 -0000 Subject: [GHC] #15366: GHC.Conc.Windows has a surprising queue In-Reply-To: <045.4d027c14d6779c15e2428ddd193b98f5@haskell.org> References: <045.4d027c14d6779c15e2428ddd193b98f5@haskell.org> Message-ID: <060.754489b98f5bcccf7b3be4c6de11be87@haskell.org> #15366: GHC.Conc.Windows has a surprising queue -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4967 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.10.1 Comment: This won't happen for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:42:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:42:12 -0000 Subject: [GHC] #15019: Fix performance regressions from #14737 In-Reply-To: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> References: <047.36d31dd41a03f5d1b4531d3b52b0f31a@haskell.org> Message-ID: <062.bea57c23bad63ca3eb5ee55424037eb1@haskell.org> #15019: Fix performance regressions from #14737 -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.10.1 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: #14737 | Differential Rev(s): phab:D4635 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * cc: davide (added) * milestone: 8.8.1 => 8.10.1 Comment: We'll need to sort out what the status of this is. DavidE, can you investigate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:42:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:42:39 -0000 Subject: [GHC] #14482: GHC -M mode fails to ensure that boot files are built before source files In-Reply-To: <046.f887b8665019281d6519a59f53c32782@haskell.org> References: <046.f887b8665019281d6519a59f53c32782@haskell.org> Message-ID: <061.6177bd832ed0045cdbf32c92c19d2862@haskell.org> #14482: GHC -M mode fails to ensure that boot files are built before source files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: 8.10.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: #14481 | Differential Rev(s): Phab:D4208 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.10.1 Comment: This won't happen for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:43:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:43:32 -0000 Subject: [GHC] #12965: String merging broken on Windows In-Reply-To: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> References: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> Message-ID: <061.413ed504ac3ba0c21dd590420bebbb4e@haskell.org> #12965: String merging broken on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3384 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => upstream Comment: Phyx, what is the status of the upstream gcc patches? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:57:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:57:00 -0000 Subject: [GHC] #12965: String merging broken on Windows In-Reply-To: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> References: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> Message-ID: <061.f6c261e80c41471d73de28b3fb4ee830@haskell.org> #12965: String merging broken on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3384 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): The specific implementation in GCC/binutils won't work for non-ELF targets it turns out. However I have an implementation that should do this using a similar method as the D compiler uses by leveraging ld's `.gnu.linkonce` support for PE targets. This method however needs a guarantee from the compiler that it doesn't output duplicate string constants, or GAS will end up merging them and breaking the approach. (This is what was going wrong in the Diff as WIP on Phab). It seems that GHC doesn't do this at the moment, it only happens to have this effect some of the them due to CSEing. So I have written a new string constant pooling pass that does this. In order to make it lightweight I changed the syntax to allow multiple labels at definition site. Such that I don't have to actually change the usage sites. I've changed all the back-ends but have a bug to fix and still need to figure out how to test the llvm, macos and unregister changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 22:57:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 22:57:21 -0000 Subject: [GHC] #15934: Building ghc with profiling libraries fails on windows. In-Reply-To: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> References: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> Message-ID: <062.672500199c586d4feb63488919016c0f@haskell.org> #15934: Building ghc with profiling libraries fails on windows. ---------------------------------+---------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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: | ---------------------------------+---------------------------------------- Changes (by bgamari): * priority: high => highest Comment: Apparently full builds of `master` currently break on Windows due to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 23:07:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 23:07:42 -0000 Subject: [GHC] #15955: Cannot get debugging symbols for compiled c-sources In-Reply-To: <042.4247b6eb19a9be164ea978944f4cfb58@haskell.org> References: <042.4247b6eb19a9be164ea978944f4cfb58@haskell.org> Message-ID: <057.5b9e7f56f2ee3e9f8840f6f19b8c4b51@haskell.org> #15955: Cannot get debugging symbols for compiled c-sources -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.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 nh2): Thanks to bgamari and slyfox on IRC, I found that all that matters is that the symbols are in the generated `.s` assembly file. When that is the case, it isn't necessary to pass `-g` to `as`. And it turned out the issue is somewhere completely different. https://github.com/haskell/cabal/commit/81017f44 Looks like Cabal strips the executable at install time; if I had run the executable in `dist/`, it wouldn't have, and indeed that one has my symbols. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 23:07:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 23:07:57 -0000 Subject: [GHC] #15955: Cannot get debugging symbols for compiled c-sources In-Reply-To: <042.4247b6eb19a9be164ea978944f4cfb58@haskell.org> References: <042.4247b6eb19a9be164ea978944f4cfb58@haskell.org> Message-ID: <057.3bbb41dece8ebacfba80f0304df873e5@haskell.org> #15955: Cannot get debugging symbols for compiled c-sources -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 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 nh2): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 23:14:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 23:14:56 -0000 Subject: [GHC] #15934: Building ghc with profiling libraries fails on windows. In-Reply-To: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> References: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> Message-ID: <062.b93c3f48d311f5b343e08e13fa83433c@haskell.org> #15934: Building ghc with profiling libraries fails on windows. ---------------------------------+---------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Andreas reports that, as suggested on StackOverflow, passing `-mbig-obj` to the assembler helps. However, things then fail at linking. I believe this will be fixed by passing `--oformat pe-bigobj-x86-64` to the linker, although this hasn't been confirmed yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 23:21:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 23:21:09 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in In-Reply-To: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> References: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> Message-ID: <065.451fddc138bf275658289fa3b3f6306a@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here is another example which doesn't require `ImpredicativeTypes`, `PolyKinds`, or visible dependent quantification: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE RankNTypes #-} module Bug where import Data.Kind type A a = Int type B (a :: Type -> Type) = forall x. x -> x type C = B A }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 23:27:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 23:27:58 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in In-Reply-To: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> References: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> Message-ID: <065.a9390083071c47286483e0df2dbeedf7@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The culprit appears to be the [http://git.haskell.org/ghc.git/blob/984b75de7082689ebcc6e9d17b37f2c9b3702f71:/compiler/typecheck/TcValidity.hs#l467 first case] of `check_type`: {{{#!hs check_type env ctxt rank ty | not (null tvbs && null theta) = do { traceTc "check_type" (ppr ty $$ ppr (forAllAllowed rank)) ; checkTcM (forAllAllowed rank) (forAllTyErr env rank ty) -- Reject e.g. (Maybe (?x::Int => Int)), -- with a decent error message ; check_valid_theta env' SigmaCtxt theta -- Allow type T = ?x::Int => Int -> Int -- but not type T = ?x::Int ; check_type env' ctxt rank tau -- Allow foralls to right of arrow ; checkTcM (not (any (`elemVarSet` tyCoVarsOfType phi_kind) tvs)) (forAllEscapeErr env' ty tau_kind) } where (tvbs, phi) = tcSplitForAllVarBndrs ty (theta, tau) = tcSplitPhiTy phi tvs = binderVars tvbs (env', _) = tidyVarBndrs env tvs tau_kind = typeKind tau phi_kind | null theta = tau_kind | otherwise = liftedTypeKind -- If there are any constraints, the kind is *. (#11405) }}} In particular, this function uses `tcSplitForAllVarBndrs` and `tcSplitPhiTy` to decompose the right-hand side of a type synonym. What happens when that right-hand side is `B A` (from comment:1)? Well, as it happens, both `tcSplitForAllVarBndrs` and `tcSplitPhiTy` //expand type synonyms//, so `check_type` actually checks `forall x. x -> x` for validity, not `B A`! In other words, GHC is completely oblivious to the fact that `A` is unsaturated, since it's not checking the type `B A` in the first place. I suppose the prudent thing to do here would be to conjure up variations of `tcSplitForAllVarBndrs` and `tcSplitPhiTy` that don't expand type synonyms? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 23:31:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 23:31:57 -0000 Subject: [GHC] #15934: Building ghc with profiling libraries fails on windows. In-Reply-To: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> References: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> Message-ID: <062.e81bd60c7ef1097b2bada390d69c191d@haskell.org> #15934: Building ghc with profiling libraries fails on windows. ---------------------------------+---------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): It sounds like the linker change worked as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 23:55:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 23:55:30 -0000 Subject: [GHC] #15812: add System.Mem.Address to base In-Reply-To: <045.b345df82d6f6da10bcf57adbf4aa903f@haskell.org> References: <045.b345df82d6f6da10bcf57adbf4aa903f@haskell.org> Message-ID: <060.53471b87127e7f1b23a16641af110a4e@haskell.org> #15812: add System.Mem.Address to base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.10.1 Component: libraries/base | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5268 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): the discussion started in https://mail.haskell.org/pipermail/libraries/2018-October/028997.html (https://mail.haskell.org/pipermail/libraries/2018-October/thread.html) and continued through november https://mail.haskell.org/pipermail/libraries/2018-November/thread.html i'll write up more notes later, but ultimately the conclusion seems to be : 1. theres not really any examples where the code becomes simpler/safer/more performant with Address in base and usage thereof 2. there are valid/ real issues with some Ptr based interfaces and they could be improved. (and some confusion about why/best/practicies, and in one case the mistaken belief that all `Ptr a` values will conform to the Storable type class representation) there were ~ 3 people arguing for inclusion in base, but in my own opinion there wasn't a case substantiating their utility. (and some of the exemplar changes they suggested would needless break existing code without fixing any underlying issue, as best i could tell) Punchline: theres definitely a genuine need for better tooling around pointers to make its way into the ecosystem and perhaps eventually base, but this Adddress work doesn't accomplish that -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Nov 26 23:55:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Nov 2018 23:55:50 -0000 Subject: [GHC] #15812: add System.Mem.Address to base In-Reply-To: <045.b345df82d6f6da10bcf57adbf4aa903f@haskell.org> References: <045.b345df82d6f6da10bcf57adbf4aa903f@haskell.org> Message-ID: <060.da22a0995ae61818997d17e8acdc3715@haskell.org> #15812: add System.Mem.Address to base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.10.1 Component: libraries/base | Version: 8.7 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): Phab:D5268 Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * status: patch => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 00:04:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 00:04:50 -0000 Subject: [GHC] #15934: Building ghc with profiling libraries fails on windows. In-Reply-To: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> References: <047.7c41fc74b68cdc55afd41f0a9c9337c9@haskell.org> Message-ID: <062.1449432a3a47e70b49d34717a7003575@haskell.org> #15934: Building ghc with profiling libraries fails on windows. ---------------------------------+---------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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:D5383 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5383 Comment: So it seems that the bigobj format isn't support on 32-bit Windows, so there isn't much we can do there. However, Phab:D5383 should fix the issue on amd64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 00:47:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 00:47:23 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.6c8f07216f7bc582e6a8b7ea9440dc69@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 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 Fuuzetsu): Data-point from 8.6.2 using original code (first comment): {{{ [nix-shell:/tmp]$ ghc -O2 Blah.hs && ./Blah benchmarking single call/A time 21.83 ns (21.55 ns .. 22.09 ns) 0.999 R² (0.999 R² .. 1.000 R²) mean 21.77 ns (21.62 ns .. 22.07 ns) std dev 705.5 ps (434.8 ps .. 1.223 ns) variance introduced by outliers: 53% (severely inflated) benchmarking single call/B time 9.741 ns (9.581 ns .. 9.937 ns) 0.998 R² (0.996 R² .. 0.999 R²) mean 9.762 ns (9.641 ns .. 9.942 ns) std dev 490.4 ps (347.4 ps .. 649.6 ps) variance introduced by outliers: 74% (severely inflated) }}} I'm attaching -ddump-simpl output (Blah.dump-simpl). It seems the ticket is still a problem and not 3-5% but 100% -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 00:47:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 00:47:49 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.27012cc17c06aa11951ef895749386a8@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 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 Fuuzetsu): * Attachment "Blah.dump-simpl" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 01:06:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 01:06:30 -0000 Subject: [GHC] #15956: Linker error buidling `runghc` Message-ID: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> #15956: Linker error buidling `runghc` -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | 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 on MacOS trying to build `master`. Hadrian fails where `make` succeeds. I'm not doing anything fancy either.. {{{ ghc$ git rev-parse HEAD df570d920fa66db631f936fa377e598fe92bd2a1 ghc$ ./boot && ./configure ghc$ make -j V=0 # succeeds ghc$ ./hadrian/build.sh -c --build-root="_build2" > out.log 2> err.log # fails }}} Hadrian fails when trying to link `runghc`: {{{ Error when running Shake build system: at src/Rules.hs:(34,19)-(47,17): at src/Rules.hs:47:5-17: * Depends on: _build2/stage1/bin/runghc * Raised the exception: user error (Development.Shake.cmd, system command failed Command: _build2/stage0/bin/ghc -Wall -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db _build2/stage1/lib/package.conf.d' '-package-id base-4.12.0.0' '-package- id directory-1.3.3.1' '-package-id filepath-1.4.2.1' '-package-id process-1.6.3.0' '-package-id unix-2.7.2.2' -i -i_build2/stage1/utils/runghc/build -i_build2/stage1/utils/runghc/build/runghc/autogen -iutils/runghc/. -Iincludes -I_build2/generated -I_build2/stage1/utils/runghc/build -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/process-1.6.3.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/unix-2.7.2.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/time-1.9.2/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/bytestring-0.10.9.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/base-4.12.0.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/integer-gmp-1.0.2.0/include -I/Users/atheriault/Code/ghc/_build2/stage1/lib/x86_64-osx- ghc-8.7.20181126/rts-1.0/include -I_build2/generated -optc- I_build2/generated -optP-include -optP_build2/stage1/utils/runghc/build/runghc/autogen/cabal_macros.h -optc-fno-stack-protector -odir _build2/stage1/utils/runghc/build -hidir _build2/stage1/utils/runghc/build -stubdir _build2/stage1/utils/runghc/build -no-auto-link-packages -rtsopts -optl- lgmp -Wnoncanonical-monad-instances -optc-Wno-unknown-pragmas _build2/stage1/utils/runghc/build/Main.o -o _build2/stage1/bin/runghc -O2 -H32m -XHaskell2010 -ghcversion- file=/Users/atheriault/Code/ghc/_build2/generated/ghcversion.h Exit code: 1 Stderr: Undefined symbols for architecture x86_64: "_findPtr", referenced from: -u command line option ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) ) }}} This must be a recent regression, since I was successfully building with Hadrian as recently as last week. I'll try to bisect, although the failure occurs so late in the compilation pipeline that I expect progress to be quite slow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 01:06:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 01:06:45 -0000 Subject: [GHC] #15956: Linker error building `runghc` (was: Linker error buidling `runghc`) In-Reply-To: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> References: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> Message-ID: <065.640ec93cfe3225ae415cbc483555b4ae@haskell.org> #15956: Linker error building `runghc` -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 02:06:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 02:06:52 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.65c12e44d3caeba3cd65dbe9addbf3ba@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 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 Fuuzetsu): I ran with multiple GHC versions. I'm attaching a tarball with the results above and Core from each version. It appears the problem went way briefly in 8.0.2 but came back worse than ever afterwards. For exact package sets, I used these: {{{ resolver: lts-6.35 # 7.10.3 resolver: lts-9.21 # 8.0.2 resolver: lts-11.22 # 8.2.2 resolver: lts-12.20 # 8.4.4 resolver: nightly-2018-11-24 # 8.6.2 }}} GHC version 7.10.3 {{{ benchmarking single call/A time 9.800 ns (9.730 ns .. 9.890 ns) 1.000 R² (0.999 R² .. 1.000 R²) mean 9.907 ns (9.844 ns .. 9.996 ns) std dev 250.2 ps (167.4 ps .. 344.7 ps) variance introduced by outliers: 42% (moderately inflated) benchmarking single call/B time 10.09 ns (10.00 ns .. 10.20 ns) 0.999 R² (0.999 R² .. 0.999 R²) mean 10.37 ns (10.25 ns .. 10.49 ns) std dev 403.4 ps (353.8 ps .. 475.9 ps) variance introduced by outliers: 63% (severely inflated) }}} GHC version 8.0.2 {{{ benchmarking single call/A time 9.794 ns (9.695 ns .. 9.914 ns) 0.999 R² (0.999 R² .. 1.000 R²) mean 9.884 ns (9.805 ns .. 10.01 ns) std dev 308.2 ps (211.6 ps .. 449.5 ps) variance introduced by outliers: 52% (severely inflated) benchmarking single call/B time 9.861 ns (9.784 ns .. 9.946 ns) 1.000 R² (0.999 R² .. 1.000 R²) mean 9.834 ns (9.799 ns .. 9.879 ns) std dev 133.3 ps (92.41 ps .. 201.6 ps) variance introduced by outliers: 17% (moderately inflated) }}} GHC version 8.2.2 {{{ benchmarking single call/A time 22.82 ns (22.59 ns .. 23.16 ns) 0.999 R² (0.997 R² .. 1.000 R²) mean 22.83 ns (22.60 ns .. 23.15 ns) std dev 890.2 ps (655.8 ps .. 1.268 ns) variance introduced by outliers: 62% (severely inflated) benchmarking single call/B time 10.10 ns (10.06 ns .. 10.15 ns) 1.000 R² (1.000 R² .. 1.000 R²) mean 10.11 ns (10.08 ns .. 10.15 ns) std dev 120.7 ps (72.17 ps .. 184.5 ps) variance introduced by outliers: 14% (moderately inflated) }}} GHC version 8.4.4 {{{ benchmarking single call/A time 21.51 ns (21.33 ns .. 21.72 ns) 0.999 R² (0.999 R² .. 1.000 R²) mean 21.55 ns (21.35 ns .. 22.21 ns) std dev 1.128 ns (374.2 ps .. 2.297 ns) variance introduced by outliers: 75% (severely inflated) benchmarking single call/B time 9.505 ns (9.449 ns .. 9.568 ns) 1.000 R² (0.999 R² .. 1.000 R²) mean 9.509 ns (9.454 ns .. 9.570 ns) std dev 197.7 ps (159.3 ps .. 243.1 ps) variance introduced by outliers: 33% (moderately inflated) }}} GHC version 8.6.2 {{{ benchmarking single call/A time 21.71 ns (21.44 ns .. 22.06 ns) 0.998 R² (0.998 R² .. 0.999 R²) mean 21.93 ns (21.70 ns .. 22.24 ns) std dev 884.3 ps (721.8 ps .. 1.228 ns) variance introduced by outliers: 64% (severely inflated) benchmarking single call/B time 10.28 ns (10.20 ns .. 10.40 ns) 0.999 R² (0.999 R² .. 1.000 R²) mean 10.31 ns (10.24 ns .. 10.41 ns) std dev 286.9 ps (224.3 ps .. 372.6 ps) variance introduced by outliers: 46% (moderately inflated) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 02:07:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 02:07:26 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.9bb79eb54e015f9c0c355a93c8fbe686@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 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 Fuuzetsu): * Attachment "results.tar.gz" added. Results from runs of multiple GHC versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 02:12:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 02:12:49 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.73b4ea5c61ed15693734cba44fe939c7@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 pacak): * version: 7.10.1-rc2 => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 07:24:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 07:24:54 -0000 Subject: [GHC] #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. Message-ID: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 simple code like {{{#!haskell {-# LANGUAGE RecordWildCards #-} module M (foo) where data D = D { d1 :: Int, d2 :: Int } foo :: D -> Int -> Int foo D{..} x = x + 5 }}} There is no way that I know of to get GHC to warn us that the {{{ D{..} }}} in {{{foo}}} is not binding anything at all. This is very common after refactoring (perhaps {{{foo}}} looked like {{{foo D{..} x = x + d1 + 5}}} before) and would be great to be able to get a warning about. Of course it's not _dead_ code as it still forces {{{D}}} to WHNF but if we're using {{{RecordWildCards}}} syntax then it's probably not what we were going for. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 08:37:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 08:37:17 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in In-Reply-To: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> References: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> Message-ID: <065.dde5cbcfb185638703ea7f877608732f@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I suppose the prudent thing to do here would be to conjure up variations of tcSplitForAllVarBndrs and tcSplitPhiTy that don't expand type synonyms? Actually I think it would suffice simply to put this `check_type` equation (the one you cite in comment:2) last, after the one for `TyConApp`. The latter does the right thing for synonyms, and expands them. Oh, the `FunTy` case should still follow the moved equation; consider `t1 => t2`. Would you like to try that? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 10:47:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 10:47:04 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.d81c517e8dcf952bcb130142aa9003b8@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * differential: => Phab:D5385 Comment: The Cabal PR got merged, and I just pushed [https://phabricator.haskell.org/D5385 D5385] which updates the Cabal submodule to point to my commit, makes use of `extra-dynamic-library- flavours` in `rts.cabal.in` when the `dynamic` flag is passed, and arranges for that flag to be passed by Hadrian whenever appropriate. Once this lands, we will be done with 1., 2. and 3. from the original comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 11:20:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 11:20:08 -0000 Subject: [GHC] #15814: Orphan Instance Overlap Error Message In-Reply-To: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> References: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> Message-ID: <065.4d40805f28fc281e6c5046a992036612@haskell.org> #15814: Orphan Instance Overlap Error Message -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.4.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:D5377 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for working on this. Indeed, a careful `Note` to explain how it works, and some more type signatures on local definitions, would be helpful. I could not understand the code. I think your idea is something like this, supposing we are compiling module M, and are reporting an instance whose dictionary function is `$df`. * Given a `$df` we know the module D in which it is defined, via `nameModule`. * If that module D is * M itself, or * one of the module that M directly imports * an orphan module we can report how `$df` came to be in scope. * Those three cases are easy because we have that info to hand in the `TcGblEnv`. You code looks a bit complicated if I'm right, but maybe I'm missing something. I also wonder about doing the full job, when `$df` is in scope indirectly. After all, that's the situation in which the user is going to be most puzzled! What we want is to ask * For each `import B`, does `B` transitively import `D`? And that info is also conveniently available, in the `mi_deps` field of each `ModIface`. So it should be easy to do to full job, no exceptions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 11:50:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 11:50:19 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in In-Reply-To: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> References: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> Message-ID: <065.7d69ffd32620c176893d335f393e2970@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks, I've implemented your suggestion. There are three error message regressions as a result, so I'd like your feedback on them. 1. In `T15859`: {{{#!diff diff -uw "dependent/should_fail/T15859.run/T15859.stderr.normalised" "dependent/should_fail/T15859.run/T15859.comp.stderr.normalised" --- dependent/should_fail/T15859.run/T15859.stderr.normalised 2018-11-27 06:38:24.627899584 -0500 +++ dependent/should_fail/T15859.run/T15859.comp.stderr.normalised 2018-11-27 06:38:24.635899818 -0500 @@ -1,6 +1,7 @@ -T15859.hs:13:5: - Cannot apply expression of type ‘forall k -> k -> *’ - to a visible type argument ‘Int’ +T15859.hs:13:19: + Illegal polymorphic type: forall k -> k -> * + Perhaps you intended to use LiberalTypeSynonyms + In an expression type signature: KindOf A + In the expression: undefined :: KindOf A In the expression: (undefined :: KindOf A) @Int - In an equation for ‘a’: a = (undefined :: KindOf A) @Int }}} This one doesn't bother me much, since that code really ought to have been enabling `LiberalTypeSynonyms` in the first place (indeed, investigating that code is what led me to discovering this bug). I think I'll fix this by just enabling `LiberalTypeSynonyms` in the test case. 2. In `T7809`: {{{#!diff diff -uw "typecheck/should_fail/T7809.run/T7809.stderr.normalised" "typecheck/should_fail/T7809.run/T7809.comp.stderr.normalised" --- typecheck/should_fail/T7809.run/T7809.stderr.normalised 2018-11-27 06:42:45.604510107 -0500 +++ typecheck/should_fail/T7809.run/T7809.comp.stderr.normalised 2018-11-27 06:42:45.615510428 -0500 @@ -1,6 +1,5 @@ T7809.hs:8:8: - Illegal polymorphic type: PolyId + Illegal polymorphic type: forall a. a -> a GHC doesn't yet support impredicative polymorphism - In the type signature: - foo :: F PolyId + In the type signature: foo :: F PolyId }}} This one is a bit concerning, since we've regressed from a nice error message about `PolyId` (which is what the user wrote) to instead mentioning `forall a. a -> a` (which requires the user to perform some detective work to figure out where it comes from). I haven't figured out yet why this happens (indeed, I'm surprised to see a type synonym being expanded //more// after this change). 3. In `tc149`: {{{ Compile failed (exit code 1) errors were: tc149.hs:8:8: error: • The type synonym ‘Id’ should have 1 argument, but has been given none • In the type signature: foo :: Generic Id Id }}} This is the most concerning one, since `tc149` is actually expected to //typecheck//! For the sake of reference, here is the source code for this test case: {{{#!hs {-# LANGUAGE RankNTypes #-} module ShouldCompile where type Generic i o = forall x. i x -> o x type Id x = x foo :: Generic Id Id foo = error "urk" -- The point here is that we instantiate "i" and "o" -- with a partially applied type synonym. This is -- OK in GHC because we check type validity only *after* -- expanding type synonyms. -- -- However, a bug in GHC 5.03-Feb02 made this break a -- type invariant (see Type.mkAppTy) }}} Mysteriously, that comment claims that this code ought to typecheck as- is. But shouldn't that only be the case if `LiberalTypeSynonyms` is enabled? This test case was added all the way back in 2002 (in commit ddb3ea2220621d9393ebb08ce3548ac2118a57c2) without much exposition, so it's difficult for me to tell whether this test case is legitimate or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 12:19:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 12:19:15 -0000 Subject: [GHC] #15925: Production quality bindists for hadrian In-Reply-To: <048.0f796c5db706ecf53494ae820b60c312@haskell.org> References: <048.0f796c5db706ecf53494ae820b60c312@haskell.org> Message-ID: <063.805b68475dfe1dd03a61824c460f56a7@haskell.org> #15925: Production quality bindists for hadrian -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | 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:D5371 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alp Mestanogullari ): In [changeset:"8f52ab9223544b756010a7a92ea52fffdf1d1c71/ghc" 8f52ab92/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f52ab9223544b756010a7a92ea52fffdf1d1c71" Hadrian: improve bindist rule As outlined in #15925, hadrian bindists had not made a clear choice with respect to relocatable GHCs and wrapper scripts. This commit implements the policy described in the ticket. That is: - the bindists ship {bin, lib} as they are, modulo the addition of haddock from stage2/bin - we now _always_ generate wrapper scripts for all the programs that are in the bindist's bin/ directory The idea being that anyone on Linux/Windows/OS X can just unpack the binary distribution anywhere and start using bin/ghc, while the installation process systematicaly generates wrapper scripts. Test Plan: hadrian/build.sh binary-dist ; cd _build/bindist/ghc-X.Y.Z-arch/; configure --prefix=/tmp/foo && make install Reviewers: snowleopard, bgamari, angerman Reviewed By: snowleopard, bgamari, angerman Subscribers: rwbarton, carter GHC Trac Issues: #15925 Differential Revision: https://phabricator.haskell.org/D5371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 12:23:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 12:23:31 -0000 Subject: [GHC] #15925: Production quality bindists for hadrian In-Reply-To: <048.0f796c5db706ecf53494ae820b60c312@haskell.org> References: <048.0f796c5db706ecf53494ae820b60c312@haskell.org> Message-ID: <063.9f6c908df733323650e6f9b308950608@haskell.org> #15925: Production quality bindists for hadrian -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | 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:D5371 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 Comment: The aforementionned diff has been approved and merged. I'm closing this ticket as I believe the issues have been addressed. The bindist rules may not be perfect but if specific problems come up they deserve their own ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 12:46:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 12:46:08 -0000 Subject: [GHC] #15958: Missing documentation for '-fno-ghci-sandbox' Message-ID: <050.0ae93feab32cb96de3a9f8fc5fef3f93@haskell.org> #15958: Missing documentation for '-fno-ghci-sandbox' -------------------------------------+------------------------------------- Reporter: andregrigon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Documentation | Version: 8.6.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 option '-fno-ghci-sandbox' is mentioned in https://downloads.haskell.org/~ghc/7.0.2/docs/html/users_guide/release-7-0-1.html with the following explanation: There is a new -fno-ghci-sandbox flag, which stops GHCi running computations in a separate thread. In particular, this is useful for GLUT on OS X, which only works if being run on the main thread. However, it doesn't seem to be documented on the GHC user's guide (search box didn't find anything). Sorry if I just couldn't find it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 13:35:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 13:35:54 -0000 Subject: [GHC] #15959: If a type signature is too long to read left-to-right then let it read top-to-bottom. Message-ID: <051.66215bd2f9936eb3dd6dad78fe13251f@haskell.org> #15959: If a type signature is too long to read left-to-right then let it read top- to-bottom. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- When pretty printing a type signature that is too long to show in one line, can we please break the lines on the top-level punctuation of the type signature, on {{{::}}}, {{{=>}}} and {{{->}}} as shown in the second listing below? {{{ FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: showMax :: (Reflex t, Functor f) => (a -> b) -> (f b -> b -> c) -> Dynamic t (f a) -> Dynamic t a -> Dynamic t c | 186 | showMax getField f pt points = | ^^^^^^^ }}} {{{ FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: showMax :: (Reflex t, Functor f) => (a -> b) -> (f b -> b -> c) -> Dynamic t (f a) -> Dynamic t a -> Dynamic t c | 186 | showMax getField f pt points = | ^^^^^^^ }}} If a type signature is too long to display in one line and read left-to- right then please let it read top-to-bottom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 13:37:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 13:37:17 -0000 Subject: [GHC] #15959: If a type signature is too long to read left-to-right then let it read top-to-bottom. In-Reply-To: <051.66215bd2f9936eb3dd6dad78fe13251f@haskell.org> References: <051.66215bd2f9936eb3dd6dad78fe13251f@haskell.org> Message-ID: <066.14f776c9d3e5ac2bd69da1ade71a7364@haskell.org> #15959: If a type signature is too long to read left-to-right then let it read top- to-bottom. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 philderbeast: Old description: > When pretty printing a type signature that is too long to show in one > line, can we please break the lines on the top-level punctuation of the > type signature, on {{{::}}}, {{{=>}}} and {{{->}}} as shown in the second > listing below? > > {{{ > FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] > Top-level binding with no type signature: > showMax :: (Reflex t, Functor f) => > (a -> b) > -> (f b -> b -> c) -> Dynamic t (f a) -> Dynamic t a -> > Dynamic t c > | > 186 | showMax getField f pt points = > | ^^^^^^^ > }}} > > {{{ > FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] > Top-level binding with no type signature: > showMax > :: (Reflex t, Functor f) > => (a -> b) > -> (f b -> b -> c) > -> Dynamic t (f a) > -> Dynamic t a > -> Dynamic t c > > | > 186 | showMax getField f pt points = > | ^^^^^^^ > }}} > > If a type signature is too long to display in one line and read left-to- > right then please let it read top-to-bottom. New description: When pretty printing a type signature that is too long to show in one line, can we please break the lines on the top-level punctuation of the type signature, on {{{::}}}, {{{=>}}} and {{{->}}} as shown in the second listing below? {{{ FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: showMax :: (Reflex t, Functor f) => (a -> b) -> (f b -> b -> c) -> Dynamic t (f a) -> Dynamic t a -> Dynamic t c | 186 | showMax getField f pt points = | ^^^^^^^ }}} {{{ FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: showMax :: (Reflex t, Functor f) => (a -> b) -> (f b -> b -> c) -> Dynamic t (f a) -> Dynamic t a -> Dynamic t c | 186 | showMax getField f pt points = | ^^^^^^^ }}} If a type signature is too long to display in one line and read left-to- right then please let it read top-to-bottom. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 13:51:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 13:51:03 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.afd60f7332a9c71d7a738ed246fdb8e2@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 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): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Comment (by tdammers): Updated Phab:D4110 with the original patch rebased onto master. Also added two tests. The first one, `T14375`, is a slightly modified version of the small test case from comment:14:ticket:14346; the original reproduction case is unsuitable for testsuite use due to the crucially important use of `forever`, but by throwing an exception, we can stop execution while still tricking the optimizer into considering the code after `forever` unreachable. I have verified that this test fails on GHC 8.2 and passes after this patch. However, due to other changes in the meantime, it also passes on GHC versions just before the patch, even when we disable the obvious suspect (`NOINLINE` pragmas on the `alloca...` functions, the previous workaround), so there must be yet something else going on. The second test case, `T14375-2`, was suggested by bgamari in a private chat. The idea is to verify the correct operation of the new `with#` primop by using it on a binding that is also the key of a weak pointer, using its finalizer to attach observable behavior to its deallocation. This way, we can tell from the test output whether the finalizer runs before or after the end of the block wrapped in `with#`. Unfortunately, finalizers are somewhat unpredictable creatures, and so the test case is somewhat brittle - in order to actually see the finalizer running, the test has to be compiled unoptimized, and the `threadDelay` calls in strategic locations are needed to trigger GC. Obviously, since we're using the new `with#` primop directly in this second test, it is impossible to verify that it fixes anything; it just tells us that `with#` behaves as expected in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 15:18:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 15:18:47 -0000 Subject: [GHC] #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. In-Reply-To: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> References: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> Message-ID: <062.a2391042ddc551981ef20ccf0e64d1f2@haskell.org> #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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): If you compile will wall you don’t get an unused variable warning? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 15:40:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 15:40:46 -0000 Subject: [GHC] #15959: If a type signature is too long to read left-to-right then let it read top-to-bottom. In-Reply-To: <051.66215bd2f9936eb3dd6dad78fe13251f@haskell.org> References: <051.66215bd2f9936eb3dd6dad78fe13251f@haskell.org> Message-ID: <066.3348b05ea87f092fc1a0fa69bf659b4f@haskell.org> #15959: If a type signature is too long to read left-to-right then let it read top- to-bottom. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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): Yes, good idea! Should not be too difficult. See `IfaceType` which is where the main pretty-printer is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 16:05:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 16:05:38 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.247934c2b3078cf483464f17c0f0c29a@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 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): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Comment (by tdammers): As briefly touched upon in the HQ meeting: the `T14375-2` test contains a function `with :: a -> IO () -> IO ()` that's just a lightweight wrapper for `with#`; do we want to have this `with` function somewhere in the base libraries, similar to how other primops (e.g. `mkWeak#`) are exposed through more palatable wrappers (like `mkWeak`)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 16:15:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 16:15:51 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.25f4bf1b3bee6c8f82c7047899c6fffe@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) Comment: JulianLeviston, any news? I'll try to build your branch and see what's going wrong tomorrow. (CCing myself to add this to my ticket list) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 16:36:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 16:36:47 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.a30c15a5280e599ae160b042467e0042@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): I'm currently writing the evaluation chapter of the paper and hit quite a bummer. If I add an option to ''ignore'' closure growth completely, instructions improve by another 0.3% in the mean, with no regressions (!) wrt. the baseline where we try to avoid closure growth. Although total allocations possibly increase, executed instructions ''go down'' in some cases. The most prominent case is `paraffins`: +18.6% more allocations, but -11.7% less executed instructions! Example run: {{{ $ ./default 19 +RTS -s > /dev/null 359,457,968 bytes allocated in the heap 536,016,504 bytes copied during GC 163,983,272 bytes maximum residency (8 sample(s)) 1,699,968 bytes maximum slop 156 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 339 colls, 0 par 0.137s 0.137s 0.0004s 0.0025s Gen 1 8 colls, 0 par 0.386s 0.386s 0.0482s 0.1934s INIT time 0.000s ( 0.000s elapsed) MUT time 0.058s ( 0.058s elapsed) GC time 0.523s ( 0.523s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.581s ( 0.581s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 6,243,240,498 bytes per MUT second Productivity 9.9% of total user, 9.9% of total elapsed $ ./allow-cg 19 +RTS -s > /dev/null 426,433,296 bytes allocated in the heap 488,364,024 bytes copied during GC 139,063,776 bytes maximum residency (8 sample(s)) 2,223,648 bytes maximum slop 132 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 403 colls, 0 par 0.136s 0.136s 0.0003s 0.0010s Gen 1 8 colls, 0 par 0.317s 0.317s 0.0397s 0.1517s INIT time 0.000s ( 0.000s elapsed) MUT time 0.080s ( 0.080s elapsed) GC time 0.453s ( 0.453s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.533s ( 0.533s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 5,359,023,067 bytes per MUT second Productivity 14.9% of total user, 14.9% of total elapsed }}} Note how allocations and number of collections (these are correlated) went up, but bytes copied and GC time (also correlated) went down. The only possible conclusion here is that viewing bytes allocated as a metric for predicting runtime is flawed: What matters most for runtime is bytes copied during GC. Of course there's an overhead for heap checks etc., but it seems that GC pressure far outweighs that. Interestingly, if I 'disable' the GC by allocating 600MB of nursery, the inverse effect manifests: {{{ $ ./default 19 +RTS -s -A600M > /dev/null 359,104,696 bytes allocated in the heap 3,384 bytes copied during GC 44,480 bytes maximum residency (1 sample(s)) 25,152 bytes maximum slop 0 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.000s 0.000s 0.0002s 0.0002s INIT time 0.009s ( 0.009s elapsed) MUT time 0.127s ( 0.127s elapsed) GC time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.136s ( 0.136s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 2,821,937,180 bytes per MUT second Productivity 93.4% of total user, 93.5% of total elapsed $ ./allow-cg 19 +RTS -s -A600M > /dev/null 426,014,360 bytes allocated in the heap 3,384 bytes copied during GC 44,480 bytes maximum residency (1 sample(s)) 25,152 bytes maximum slop 0 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 0 colls, 0 par 0.000s 0.000s 0.0000s 0.0000s Gen 1 1 colls, 0 par 0.000s 0.000s 0.0002s 0.0002s INIT time 0.011s ( 0.011s elapsed) MUT time 0.142s ( 0.142s elapsed) GC time 0.000s ( 0.000s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.153s ( 0.153s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 2,994,250,656 bytes per MUT second Productivity 92.9% of total user, 92.9% of total elapsed }}} This is probably because of cache effects, although apparently there seem to be strictly less instructions executed in the `allow-cg` case, weird. Also I don't think that enlarging the nursery to fit all allocations is a realistic benchmark scenario. The takeaway here is that lambda lifting stuff somehow has beneficial effects on GC, even if overall allocations go up and more collections happen as a consequence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 16:40:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 16:40:12 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.dc1c215662a04a6768cff3ccefb1cd73@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): So, why does lambda lifting more bindings lead to better code here? Honestly, I'm at a loss. I identified that lifting `go` below is what seems to lead to a smaller working set, or at least lifting just this function leads to above speedups: {{{ foo = go z where go [] = z2 go (y:ys) = let sat2 = go ys2 sat1 = C x y z in sat1:sat2 x = ... y = ... z2 = ... }}} `go` has three free vars: `x`, `y` and `z2`. Lifting `go` implies an increase in allocations, because the closure for `sat2` grows under a multi-shot lambda: {{{ go x y z2 [] = z2 go x y z2 (y:ys) = let sat2 = go x y z2 ys2 sat1 = C x y z in sat1:sat2 foo = go x y z2 z where x = ... y = ... z2 = ... }}} Yet, the working set for the GC gets smaller, so it seems like the second version produces more, but shorter-lived garbage. Or at least the GC is smarter about the last version than about the first. I'm not sure what makes `go` so special! If I wouldn't have numbers, I'd totally say that it's not a worthwhile lift. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 17:19:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 17:19:41 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.1b4cb81fea705ae4a84942b805dbdb5b@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): > So, why does lambda lifting more bindings lead to better code here? Where is "here"? I'm a bit lost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 20:44:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 20:44:22 -0000 Subject: [GHC] #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. In-Reply-To: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> References: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> Message-ID: <062.fc182c13d07376e26acc24ae7db77b03@haskell.org> #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 pacak): > If you compile with -wall you don’t get an unused variable warning? No. {{{ % ghc -Weverything foo.hs ~ [1 of 1] Compiling M ( foo.hs, foo.o ) foo.hs:1:1: warning: [-Wimplicit-prelude] Module `Prelude' implicitly imported | 1 | {-# LANGUAGE RecordWildCards #-} | ^ : warning: [-Wsafe] ‘M’ has been inferred as safe! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 20:54:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 20:54:54 -0000 Subject: [GHC] #15960: Using -g causes differences in generated core. Message-ID: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> #15960: Using -g causes differences in generated core. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- For nofib/shootout/fannkuch-redux: Normal results {{{ > /e/ghc-8.6.1/bin/ghc.exe Main.hs -O2 -XBangPatterns -fforce-recomp -ddump-simpl -dsuppress-all -dsuppress-uniques | less ... Result size of Tidy Core = {terms: 2,747, types: 2,736, coercions: 100, joins: 50/73} ... }}} {{{ > /e/ghc-8.6.1/bin/ghc.exe Main.hs -O2 -XBangPatterns -fforce-recomp -ddump-simpl -dsuppress-all -dsuppress-uniques -g | less ... Result size of Tidy Core = {terms: 2,654, types: 2,557, coercions: 100, joins: 38/71} ... }}} There are also structural differences in the generated code. I've hit the issue with a tree based on head as well so likely happening there as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Nov 27 21:03:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Nov 2018 21:03:01 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.26161e76875e3ff9ce3a1a3a4c655069@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): ```validate --slow``` doesn't build at this point {{{ for i in rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build/libHSrts-ghc8.7.20181127.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug- ghc8.7.20181127.so rts/dist/build/libHSrts_thr-ghc8.7.20181127.so rts/dist/build/libHSrts_thr_debug-ghc8.7.20181127.so rts/dist/build /libHSrts_l-ghc8.7.20181127.so rts/dist/build/libHSrts_thr_l- ghc8.7.20181127.so rts/dist/build/libHSrts_thr_debug_p.a rts/dist/build/libHSrts_debug_p.a rts/dist/build/libffi.so.7.1.0 rts/dist/build/libffi.so.7 rts/dist/build/libffi.so rts/dist/build/libCffi.a rts/dist/build/libCffi_p.a rts/dist/build/libCffi_l.a rts/dist/build/libCffi_debug.a rts/dist/build/libCffi_thr.a rts/dist/build/libCffi_thr_debug.a rts/dist/build/libCffi_thr_l.a rts/dist/build/libCffi_thr_p.a rts/dist/build/libCffi_thr_debug_p.a rts/dist/build/libCffi_debug_p.a; do case $i in *.a) /usr/bin/install -c -m 644 $i "/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181127/rts"; true "/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181127/rts"/`basename $i` ;; *.dll) /usr/bin/install -c -m 755 $i "/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181127/rts" ; strip "/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181127/rts"/`basename $i` ;; *.so) /usr/bin/install -c -m 755 $i "/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181127/rts" ;; *.dylib) /usr/bin/install -c -m 755 $i "/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181127/rts";; *) /usr/bin/install -c -m 644 $i "/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181127/rts"; esac; done "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /ghc-prim dist-install "strip" '' '/home/jrp/Projects/ghc/bindisttest/install dir' '/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181127' '/home/jrp/Projects/ghc/bindisttest/install dir/share/doc/ghc-8.7.20181127/html/libraries' 'v p dyn' Installing library in /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181127/ghc-prim-0.5.3 dist-install/build/HSghc-prim-0.5.3.p_o: copyFile: does not exist (No such file or directory) make[3]: *** [ghc.mk:991: install_packages] Error 1 make[2]: *** [Makefile:51: install] Error 2 make[1]: *** [bindisttest/ghc.mk:33: test_bindist] Error 2 make: *** [Makefile:128: test_bindist] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 01:27:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 01:27:03 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.08d32cb442007dc2f74b9ba32271a3a8@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Sorry I've been distracting myself with thinking about 15617 and 3372. I'll switch back to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 05:24:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 05:24:36 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.d1a6d9c881e6ba57da0fce1eac513bca@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * priority: normal => highest Comment: Indeed I can also reproduce the issue. But really the root cause is that we don't have a working CI for months now, and I don't know what's the plan on that front. (maybe we'll be focusing on it after Gitlab migration?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 10:51:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 10:51:44 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.7f930b943368aec57226720540eb1b5c@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): I was referring to the `paraffins` measurements in comment:55. Deactivating the closure growth checks (thus allowing more bindings to lift at the potential cost of more allocations) leads to an overall improvement, most significantly visible in `paraffins` with an increase of 18% in allocations but 11% less executed instructions. The measurements I posted are for runtime. There's a reproducible speedup (0.533s vs 0.581s), too, which is mostly due to trading time in the GC for time in the mutator. That's also apparent by resizing the nursery so that no GC needs to happen (the second pair of measurements with `-A600M`). I regard this as 'better code', because it's faster in the default case, where we don't tune the nursery to fit all allocations, i.e. more mutator time is OK as long as total time goes down. In comment:56 I go on to wonder why that is the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 11:11:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 11:11:21 -0000 Subject: [GHC] #15961: TH 'Lift' instance for 'NonEmpty' Message-ID: <051.90d75a5175e6db422bbc9467bb1f108a@haskell.org> #15961: TH 'Lift' instance for 'NonEmpty' -------------------------------------+------------------------------------- Reporter: fr33domlover | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Template | Version: 8.6.2 Haskell | Keywords: lift, | Operating System: Unknown/Multiple instance, nonempty | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was using `deriving Lift` on a data type and the `DeriveLift` extension: {{{#!hs import Data.List.NonEmpty import Language.Haskell.TH data T = T (NonEmpty String) Int }}} and I noticed I couldn't get an automatic instance because `NonEmpty` doesn't have a `Lift` instance. I'm wondering if an instance can be added to the `template-haskell` package (or elsewhere if that isn't the right place? I'm assuming it is because `NonEmpty` is in `base` now) Since `NonEmpty` has a `Data` instance, I suppose the following would be enough? {{{#!hs instance Data a => Lift (NonEmpty a) }}} And without using `Data` it could be: {{{#!hs nonemptyConName :: Name nonemptyConName = mkNameG DataName "base" "Data.List.NonEmpty" ":|" instance Lift a => Lift (NonEmpty a) where lift (x :| xs) = do x' <- lift x xs' <- traverse lift xs return $ ConE nonemptyConName `AppE` x' `AppE` xs' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 11:51:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 11:51:30 -0000 Subject: [GHC] #15962: Type family & typeclass interaction suppresses errors Message-ID: <045.fbecc62354ae71f4480f06a8c4ca26eb@haskell.org> #15962: Type family & typeclass interaction suppresses errors -------------------------------------+------------------------------------- Reporter: madgen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: type family, | Operating System: Unknown/Multiple typeclass, error message | 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 following program despite having a hole and an undefined variable `iDontExist` *quietly* fails to compile on 8.4.3 and 8.4.4. It produces errors as expected on 8.6.1 and 8.6.2. By quietly failing, I mean it fails on CLI but without producing any error messages and in GHCI. It just says "Failed, no modules loaded." {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} module Bug where import Data.Kind (Type) type Exp a = a -> Type type family Eval (e :: Exp a) :: a data OpKind = Conjunction data Dual (k :: OpKind) :: Exp OpKind data Map :: (a -> Exp b) -> [ a ] -> Exp [ b ] type instance Eval (Map f (a ': as)) = Eval (f a) ': Eval (Map f as) data Big :: [ OpKind ] -> Type where Big :: [ Big ks ] -> Big ('Conjunction ': ks) dualBig :: Big ks -> Big (Eval (Map Dual ks)) dualBig = _ instance Semigroup (Big a) where Big xs <> Big ys = Big (xs <> ys) instance Monoid (Big ('Conjunction ': ks)) where mempty = iDontExist flatten :: Monoid (Big ks) => Big (k ': k ': ks) -> Big ks flatten = undefined }}} Sorry, the example is a bit big but almost any change causes the errors to appear again including the `Monoid` constraint on `flatten`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 11:53:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 11:53:31 -0000 Subject: [GHC] #15961: TH 'Lift' instance for 'NonEmpty' In-Reply-To: <051.90d75a5175e6db422bbc9467bb1f108a@haskell.org> References: <051.90d75a5175e6db422bbc9467bb1f108a@haskell.org> Message-ID: <066.81652cbd161503e58bdfddd3566a5e5b@haskell.org> #15961: TH 'Lift' instance for 'NonEmpty' -------------------------------------+------------------------------------- Reporter: fr33domlover | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Template Haskell | Version: 8.6.2 Resolution: | Keywords: lift, | instance, nonempty Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by fr33domlover: Old description: > I was using `deriving Lift` on a data type and the `DeriveLift` > extension: > > {{{#!hs > import Data.List.NonEmpty > import Language.Haskell.TH > > data T = T (NonEmpty String) Int > }}} > > and I noticed I couldn't get an automatic instance because `NonEmpty` > doesn't have a `Lift` instance. I'm wondering if an instance can be added > to the `template-haskell` package (or elsewhere if that isn't the right > place? I'm assuming it is because `NonEmpty` is in `base` now) > > Since `NonEmpty` has a `Data` instance, I suppose the following would be > enough? > > {{{#!hs > instance Data a => Lift (NonEmpty a) > }}} > > And without using `Data` it could be: > > {{{#!hs > nonemptyConName :: Name > nonemptyConName = mkNameG DataName "base" "Data.List.NonEmpty" ":|" > > instance Lift a => Lift (NonEmpty a) where > lift (x :| xs) = do > x' <- lift x > xs' <- traverse lift xs > return $ ConE nonemptyConName `AppE` x' `AppE` xs' > }}} New description: I was using `deriving Lift` on a data type and the `DeriveLift` extension: {{{#!hs import Data.List.NonEmpty import Language.Haskell.TH data T = T (NonEmpty String) Int deriving Lift }}} and I noticed I couldn't get an automatic instance because `NonEmpty` doesn't have a `Lift` instance. I'm wondering if an instance can be added to the `template-haskell` package (or elsewhere if that isn't the right place? I'm assuming it is because `NonEmpty` is in `base` now) Since `NonEmpty` has a `Data` instance, I suppose the following would be enough? {{{#!hs instance Data a => Lift (NonEmpty a) }}} And without using `Data` it could be: {{{#!hs nonemptyConName :: Name nonemptyConName = mkNameG DataName "base" "Data.List.NonEmpty" ":|" instance Lift a => Lift (NonEmpty a) where lift (x :| xs) = do x' <- lift x xs' <- traverse lift xs return $ ConE nonemptyConName `AppE` x' `AppE` xs' }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 12:13:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 12:13:41 -0000 Subject: [GHC] #15963: Test suite should report timeouts as timeouts Message-ID: <043.78110bd545349b802cb1ea7ba4bbc6f8@haskell.org> #15963: Test suite should report timeouts as timeouts -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the test suite reports timeouts as "bad exit code". I think it should instead report timeouts as timeouts. Motivation: Often when working on a change that may make things slower (at least during development) I'm interested in seeing what tests are timing out vs. failing. Currently I have to save the whole test suite log to a file and then grep in the file to manually make a list of such tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 12:34:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 12:34:40 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.fd115049be4371ac5aa8f1bd6820fabe@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): So I tried to print out the values you suggested. I can't print out `litE` and `litI` because they don't have a show instance for Core, but I tried to print out the `Integer` values `fl_signi` and `fl_exp` that I use to build those Core expressions with: {{{ import IOEnv (liftIO) ... HsRat _ fl _ -> case fl of FL { fl_signi = fl_signi, fl_exp = fl_exp } -> do mkRational <- dsLookupGlobalId mkRationalName litI <- mkIntegerExpr fl_signi litE <- mkIntegerExpr fl_exp -- temporary logging liftIO $ putStrLn $ "fl_signi: " ++ show fl_signi liftIO $ putStrLn $ "fl_exp: " ++ show fl_exp return ((Var mkRational) `App` litI `App` litE) }}} That compiles, but unfortunately when I try to run it, it blows up with the same interface file stuff. I guess this is because I renumbered `RubbishLit` here: https://github.com/JulianLeviston/ghc/pull/1/files #diff-78b3c572cf078eb00f09974b18f3eedfR214 — I'm really interested in suggestions about a better way to do that. It didn't seem good to put it after (it's out of order then). But I'm not sure what changes I need to make if I'm going to adjust the interface file(s) as I seem to have done by doing that? (bit lost there). So... yeah, this is what happens when I run it: {{{ itsy:ghc julianleviston$ ./inplace/bin/ghc-stage2 -e ":t 1e302" 1e302 :: Fractional p => p itsy:ghc julianleviston$ ./inplace/bin/ghc-stage2 -e "1e302" GHC error in desugarer lookup in Ghci1: Can't find interface-file declaration for type constructor or class mkRational 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 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 13:04:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 13:04:26 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.574ddc46923ca6898df62aa3b21d0a78@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > But really the root cause is that we don't have a working CI for months now, and I don't know what's the plan on that front. (maybe we'll be focusing on it after Gitlab migration?) To be clear, we do have working CI. CircleCI works and has been green (modulo a few long-standing but known issues in some specific cases) for more than half a year. I check on it roughly daily and try to fix issues as they pop up. Appveyor does admittedly have some issues. What we really lack is testing of differentials. This is indeed something that we are fixing with the move to GitLab. See, for instance, https://gitlab.staging.haskell.org/ghc/ghc/-/jobs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 13:26:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 13:26:37 -0000 Subject: [GHC] #15964: PartialTypeSignatures warnings should be turned off with -Wno-partial-type-signatures Message-ID: <049.cf4ba3d0b337e52717aa63727891f885@haskell.org> #15964: PartialTypeSignatures warnings should be turned off with -Wno-partial-type- signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{ Foo.hs:638:18: warning: [-Wpartial-type-signatures] }}} The warning when using `PartialTypeSignatures` suggests that the warning is enabled by `-Wpartial-type-signatures`. However, if you try and disable this warning using `-Wno-partial-type-signatures` then GHC complains that it is not a recognised flag. The correct way to turn it off is to use `-fno-warn-partial-signatures`. It seems that for consistency the first way that I tried should also work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 14:20:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 14:20:18 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in In-Reply-To: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> References: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> Message-ID: <065.f36b7b735155362242af52434a35848a@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "T15954.patch" added. Giving up on this for now until simonpj responds. Until then, I'll stash my WIP patch here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 14:26:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 14:26:24 -0000 Subject: [GHC] #15964: PartialTypeSignatures warnings should be turned off with -Wno-partial-type-signatures In-Reply-To: <049.cf4ba3d0b337e52717aa63727891f885@haskell.org> References: <049.cf4ba3d0b337e52717aa63727891f885@haskell.org> Message-ID: <064.250dbec5be297184a181208560cdd284@haskell.org> #15964: PartialTypeSignatures warnings should be turned off with -Wno-partial-type- signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 RyanGlScott): Replying to [ticket:15964 mpickering]: > However, if you try and disable this warning using `-Wno-partial-type- signatures` then GHC complains that it is not a recognised flag. Huh? I must be missing something obvious here, because I have no difficulties using the `-Wno-partial-type-signatures` flag: {{{ $ ghci GHCi, version 8.6.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci λ> :set -Wno-partial-type-signatures -XPartialTypeSignatures λ> f :: _ -> _; f x = x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 14:43:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 14:43:05 -0000 Subject: [GHC] #15962: Type family & typeclass interaction suppresses errors In-Reply-To: <045.fbecc62354ae71f4480f06a8c4ca26eb@haskell.org> References: <045.fbecc62354ae71f4480f06a8c4ca26eb@haskell.org> Message-ID: <060.1fc050b317ce64bb4d610a075eb1f7c3@haskell.org> #15962: Type family & typeclass interaction suppresses errors -------------------------------------+------------------------------------- Reporter: madgen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypedHoles, Resolution: | newcomer 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: type family, typeclass, error message => TypedHoles, newcomer Comment: Interesting program. It's conceivable that this was fixed by Tritlo's recent work on typed holes (possibly commit 39de4e3d33dd9879398062620ad00b1e3b8481ce, although I haven't confirmed this). It //is// fixed now though, thankfully. In any case, I can't recall having a test case quite like this one (the test case from #15321, which the aforementioned commit fixed, requires Template Haskell), so it might be nice to add this as a test case as well. Any volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 15:03:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 15:03:59 -0000 Subject: [GHC] #15965: readv and pread support Message-ID: <046.9c196c40c47c0be8b6bc6cb2dc47ddf3@haskell.org> #15965: readv and pread support -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.10.1 Component: | Version: 8.6.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: -------------------------------------+------------------------------------- dcoutts mentioned that `readv` and `pread` are supported by Windows and all modern BSDs, and even POSIX. Perhaps we should expose this in `base`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 15:07:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 15:07:19 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.d5a12d5e3869419781bbd5d7bf4d2d76@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > I can't print out litE and litI because they don't have a show instance for Core In GHC you should be using `Outputable` instances (with `pprTrace` and frieds). Most GHC types don't have a `Show` instance, but most have `Outputable`. In this case `pprTrace "..." (text "litI:" <+> ppr litI <+> "litE:" <+> ppr litE)` should work. > So... yeah, this is what happens when I run it: Right, so the problem is in your `mkRational` name definition: {{{ mkRationalName = tcQual gHC_REAL (fsLit "mkRational") mkRationalIdKey }}} You're saying that `mkRational` lives in `GHC.Real`, but that's not the case. It actually lives in the GHC module `BasicTypes`. We need to put `mkRational` to somehwere in `base`. `GHC.Real` is a good place I think. Secondly, I see some uses of `mkRational` in `BasicTypes`. Those also need to be moved, because when booting GHC, when building stage 1, we'll be using a GHC that won't have `mkRational` in `GHC.Real`. So all those definitions that use `mkRational` need to be moved to `GHC.Real` too. Does this make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 15:09:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 15:09:32 -0000 Subject: [GHC] #15964: PartialTypeSignatures warnings should be turned off with -Wno-partial-type-signatures In-Reply-To: <049.cf4ba3d0b337e52717aa63727891f885@haskell.org> References: <049.cf4ba3d0b337e52717aa63727891f885@haskell.org> Message-ID: <064.057b746d072f9067e500c373e9ef3b95@haskell.org> #15964: PartialTypeSignatures warnings should be turned off with -Wno-partial-type- signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 mpickering): * status: new => closed * resolution: => invalid Comment: Seems that I was misspelling the flag then. I can't reproduce it either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 15:09:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 15:09:41 -0000 Subject: [GHC] #15965: readv and pread support In-Reply-To: <046.9c196c40c47c0be8b6bc6cb2dc47ddf3@haskell.org> References: <046.9c196c40c47c0be8b6bc6cb2dc47ddf3@haskell.org> Message-ID: <061.2aacd4d7235d8b2a2ff343509391fbb5@haskell.org> #15965: readv and pread support -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: libraries/base | Version: 8.6.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: Phyx (added) Comment: This will likely become possible on Windows only once Tamar's IOCP-based event manager is merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 16:30:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 16:30:15 -0000 Subject: [GHC] #15966: panic when using RebindableSyntax Message-ID: <049.7247f1a0db5afba1d19246a56c477ca0@haskell.org> #15966: panic when using RebindableSyntax -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- https://gist.github.com/mpickering/216ecdd9d8766dce2ff1080a17f77a0e {{{ {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE RebindableSyntax #-} {-# OPTIONS_GHC -Wall -Wno-missing-signatures -Wno-unticked-promoted- constructors -Wno-name-shadowing -fwarn-partial-type-signatures -Wno- partial-type-signatures #-} module Repro(main) where import Prelude hiding (Monad(..)) import Control.Applicative data E (a :: * -> *) (n :: *) where VarE :: a n -> E a n instance IMonad E where return :: a n -> E a n return = VarE (>>=) :: E a n -> (forall n . a n -> E b n) -> E b n VarE x >>= f = f x class IMonad (m :: (* -> *) -> (* -> *)) where return :: forall a n . a n -> m a n (>>=) :: m a n -> (forall n . a n -> m b n) -> m b n one :: Const Int n one = (Const 1) example_4 :: E (Const Int) n example_4 = do x <- (return one) return x main = example_4 `seq` () }}} Compiling this file with GHC leads to a StgCmmEnv panic. {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.6.2 for x86_64-unknown-linux): StgCmmEnv: variable not found $dIMonad_a1lY local binds for: return >>= $tc'VarE $tcE $tcIMonad $trModule $tc'VarE1_r1oI $tc'VarE2_r1ps $krep_r1pt $krep1_r1pu $krep2_r1pv $krep3_r1pw $krep4_r1px $tcE1_r1py $tcE2_r1pz $tcIMonad1_r1pA $tcIMonad2_r1pB $krep5_r1pC $krep6_r1pD $krep7_r1pE $trModule1_r1pF $trModule2_r1pG $trModule3_r1pH $trModule4_r1pI $krep8_r1pJ $krep9_r1pK sat_s1rG Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Loading the file into GHCi succeeds but then when the `main` function is invoked, a `nameModule` panic occurs. {{{ *Repro> main ghc: panic! (the 'impossible' happened) (GHC version 8.6.2 for x86_64-unknown-linux): nameModule system $dIMonad_a1LV Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:240:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Reproduced on 8.6.{2,1} 8.4.4 8.2.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 16:46:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 16:46:03 -0000 Subject: [GHC] #14950: GHC 8.2.2: GHCi duplicates breakpoint range prompt In-Reply-To: <048.640f97ab7b833fac48d6aee56fed1321@haskell.org> References: <048.640f97ab7b833fac48d6aee56fed1321@haskell.org> Message-ID: <063.a455f43e72b158a6b360a155558b8dd4@haskell.org> #14950: GHC 8.2.2: GHCi duplicates breakpoint range prompt -------------------------------------+------------------------------------- Reporter: lierdakil | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: fixed | Keywords: debugger 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 RolandSenn): * status: new => closed * resolution: => fixed Comment: With GHC 8.2.2 and GHC 8.4.4 I get the same result as @lierdakil above: {{{ roland at goms:~/Projekte/ghctest/T14950$ ghci GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Prelude> :l T14950.hs [1 of 1] Compiling Test ( T14950.hs, interpreted ) Ok, one module loaded. *Test> :break test Breakpoint 0 activated at T14950.hs:3:8-16 *Test> :trace test Stopped in Test.test, T14950.hs:3:8-16 _result :: IO () = _ [T14950.hs:3:8-16] [T14950.hs:3:8-16] *Test> }}} However with GHC 8.6.1 and higher (8.6.2 and GHCHEAD-8.7.20181124) there is no more a double prompt: {{{ GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Prelude> :l T14950.hs [1 of 1] Compiling Test ( T14950.hs, interpreted ) Ok, one module loaded. *Test> :break test Breakpoint 0 activated at T14950.hs:3:8-16 *Test> :trace test Stopped in Test.test, T14950.hs:3:8-16 _result :: IO () = _ [T14950.hs:3:8-16] *Test> }}} Hence, this has been fixed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 17:38:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 17:38:53 -0000 Subject: [GHC] #15293: Set up staging branch In-Reply-To: <046.acfc865b41ac65a2d16c8050d16d16b4@haskell.org> References: <046.acfc865b41ac65a2d16c8050d16d16b4@haskell.org> Message-ID: <061.5c59128c012e4fcb1279bb5e7a03ad91@haskell.org> #15293: Set up staging branch -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: highest | Milestone: 8.8.1 Component: Continuous | Version: 8.4.3 Integration | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This will happen (finally!) with GitLab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 17:40:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 17:40:41 -0000 Subject: [GHC] #14506: Configure Harbormaster to trigger CircleCI builds In-Reply-To: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> References: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> Message-ID: <061.c1a582b7a013547420ba810201d3612c@haskell.org> #14506: Configure Harbormaster to trigger CircleCI builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 17:40:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 17:40:51 -0000 Subject: [GHC] #14506: Configure Harbormaster to trigger CircleCI builds In-Reply-To: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> References: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> Message-ID: <061.086c8311d9b6522dacde59d9ddecaf13@haskell.org> #14506: Configure Harbormaster to trigger CircleCI builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): We are moving away from Harbormaster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 17:50:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 17:50:51 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.c08664ac77bbc9d3581b4ce179b53e50@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Changes (by davide): * differential: Phab:D5385 => Phab:D5385 Phab:D5327 Old description: > The ghc binary is dynamically linked via make in various flavors (e.g. > quick). Hadrian builds a static linked binary in these cases (this is a > bug). Various change are needed to fix this: > > 1. Add new .cabal file field extra-dynamic-library-flavours (see > [https://github.com/haskell/cabal/pull/5606 this PR]). > 2. Use .cabal extra-dynamic-library-flavours for the RTS (see > [https://github.com/snowleopard/hadrian/issues/695#issue-367436377 this > comment], depends on 1.) > 3. Hadrian: fix management of nontrivial dynamic flavours of libHSrts > (see [https://github.com/snowleopard/hadrian/pull/698 this PR]). > 4. Hadrian should build ghc with the `-fPIC -dynamic` options (see > [https://github.com/DavidEichmann/ghc/commit/752021f69f577b678630302b567fd712c565624b > #diff-408bbe46d4afae11991cbadb2c531b78 this comment], depends on 3.). > 5. Use the correct relative path to the dynamically linked libraries (see > [https://phabricator.haskell.org/D5281 patch D5281], depends on 3. and > 4.). > 6. Build ghc-iserv-dyn, as it is will be required required by many tests > (see/depends on [https://phabricator.haskell.org/D5255 D5255 patch for > ghc-iserv-prof]) New description: The ghc binary is dynamically linked via make in various flavors (e.g. quick). Hadrian builds a static linked binary in these cases (this is a bug). Various change are needed to fix this: 1. Add new .cabal file field extra-dynamic-library-flavours (see [https://github.com/haskell/cabal/pull/5606 this PR]). 2. Use .cabal extra-dynamic-library-flavours for the RTS (see [https://github.com/snowleopard/hadrian/issues/695#issue-367436377 this comment], depends on 1.) 3. Hadrian: fix management of nontrivial dynamic flavours of libHSrts (see [https://github.com/snowleopard/hadrian/pull/698 this PR]). 4. Hadrian should build ghc with the `-fPIC -dynamic` options (see [https://github.com/DavidEichmann/ghc/commit/752021f69f577b678630302b567fd712c565624b #diff-408bbe46d4afae11991cbadb2c531b78 this comment], depends on 3.). 5. Use the correct relative path to the dynamically linked libraries (see Phab:D5281, depends on 3. and 4.). 6. Build ghc-iserv-dyn, as it is will be required required by many tests (Phab:D5327) 7. Hadrian should only use "-shared -dynload deploy" when linking shared libraries (definitely not when linking executables). This problem causes ghc-iserv-dyn to segfault because it is built as a shared library instead of as an executable. -- Comment: Update: With changes 1 to 7 I'm able to build a dynamically linked ghc and this fixes a significant number of tests! The end is in sight! The current status is: * (1, 2, 3) Are done and merged (Thank you Alp!). * (6) Phab:D5327 done and merged! * (4, 7) Should be fixed in a small patch that I am currently preparing. * (5) Phab:D52816 after 4 and 7 are fixed, this needs some updating, but is on the right track. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 18:40:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 18:40:40 -0000 Subject: [GHC] #15967: can't build ghc on Mac with any level of dwarf for base library Message-ID: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> #15967: can't build ghc on Mac with any level of dwarf for base library -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 (CodeGen) | 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 tried building base in 8.6.2 with -g1 and i get the following error pretty consitently from the system linker ``` ld: in /Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/libraries/base/dist-install/build/libHSbase-4.12.0.0_p.a(Base.p_o), sectionForAddress(0x8066) address not in any section for architecture x86_64 ``` if i do ``` GhcLibHcOpts += -g1 ``` or higher in the build.mk file, i get this linker error at some point in building ghc or resulting executables . I'm not sure if its *just* for profiled libs or every lib, but it looks like theres actually no way to handle the number of dwarf sections for large archives on OSX?! or equivalently, we may need support for more parsimonious dwarf annotations if at all? point being: if we can't support debug symbols for base on a tier 1 platform, either debug symbols working isn't part of our support SLA for tier 1 platforms, OR its a release blocker we've not had in our validate configuration matrix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 18:41:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 18:41:20 -0000 Subject: [GHC] #15967: can't build ghc on Mac with any level of dwarf for base library In-Reply-To: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> References: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> Message-ID: <060.bdba578fffd75a79e2c1f25019cb698c@haskell.org> #15967: can't build ghc on Mac with any level of dwarf for base library -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: | -------------------------------------+------------------------------------- Description changed by carter: Old description: > i tried building base in 8.6.2 with -g1 > and i get the following error pretty consitently from the system linker > > ``` > ld: in /Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- > build/libraries/base/dist-install/build/libHSbase-4.12.0.0_p.a(Base.p_o), > sectionForAddress(0x8066) address not in any section for architecture > x86_64 > ``` > > if i do > > ``` > GhcLibHcOpts += -g1 > ``` > or higher in the build.mk file, i get this linker error at some point in > building ghc or resulting executables . > > I'm not sure if its *just* for profiled libs or every lib, but it looks > like theres actually no way to handle the number of dwarf sections for > large archives on OSX?! > > or equivalently, we may need support for more parsimonious dwarf > annotations if at all? > > point being: if we can't support debug symbols for base on a tier 1 > platform, either debug symbols working isn't part of our support SLA for > tier 1 platforms, OR its a release blocker we've not had in our validate > configuration matrix. New description: i tried building base in 8.6.2 with -g1 and i get the following error pretty consitently from the system linker {{{ ld: in /Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/libraries/base/dist-install/build/libHSbase-4.12.0.0_p.a(Base.p_o), sectionForAddress(0x8066) address not in any section for architecture x86_64 }}} if i do {{{ GhcLibHcOpts += -g1 }}} or higher in the build.mk file, i get this linker error at some point in building ghc or resulting executables . I'm not sure if its *just* for profiled libs or every lib, but it looks like theres actually no way to handle the number of dwarf sections for large archives on OSX?! or equivalently, we may need support for more parsimonious dwarf annotations if at all? point being: if we can't support debug symbols for base on a tier 1 platform, either debug symbols working isn't part of our support SLA for tier 1 platforms, OR its a release blocker we've not had in our validate configuration matrix. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 18:42:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 18:42:34 -0000 Subject: [GHC] #15967: can't build ghc on Mac with any level of dwarf for base library In-Reply-To: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> References: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> Message-ID: <060.18d5d15f0ae56afc7ab86e8c85d17395@haskell.org> #15967: can't build ghc on Mac with any level of dwarf for base library -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: | -------------------------------------+------------------------------------- Comment (by carter): to clarify: it looks like the dwarf entries section in mach o might only support {{{maxBound:: Int16}} slots, based upon the nature of the error, but at this point i'm just speculating -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 18:42:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 18:42:56 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.8d204ed69241ed410ffaa84db4812204@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): Well it worked last week and it does build a dist. It's just that now it can't find a particular file in the bindist. I don't know whether some of the submodules changed. I'd be happy to provide further diagnostics, but it's hard to know where to start looking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 18:48:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 18:48:48 -0000 Subject: [GHC] #15967: can't build ghc on Mac with any level of dwarf for base library In-Reply-To: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> References: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> Message-ID: <060.e34aa943523d6287d58e20f8871467ad@haskell.org> #15967: can't build ghc on Mac with any level of dwarf for base library -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: | -------------------------------------+------------------------------------- Comment (by bgamari): > debug symbols working isn't part of our support SLA for tier 1 platforms Quite right. I make a best-effort to keep them working on Linux because I make use of them. However, we have no support for debugging information on Windows (which doesn't use DWARF) and I, for one, have never attempted to build a debug-enabled GHC on anything but Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 18:51:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 18:51:13 -0000 Subject: [GHC] #15967: can't build ghc on Mac with any level of dwarf for base library In-Reply-To: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> References: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> Message-ID: <060.3cd4ce413faa4578479e74afcb4bc849@haskell.org> #15967: can't build ghc on Mac with any level of dwarf for base library -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: | -------------------------------------+------------------------------------- Comment (by carter): ok, i guess i'm mostly frustrated because the extra complications for supporting gcc going forward on mac have been ostensibly for dwarf support, but we currently can't even support dwarf generation on mac for base ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 19:29:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 19:29:46 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.d2b025ddee57936b65dc5cf7d4cc8f0b@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): the patch works, we just cant build GHC boot/base libs with any dwarf setting higher than -g0 on darwin because of some linker / object code format limitation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 21:20:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 21:20:06 -0000 Subject: [GHC] #15414: Why both gen and gen_no in bdescr? In-Reply-To: <046.3e22919acbe44581425bc44a28f802be@haskell.org> References: <046.3e22919acbe44581425bc44a28f802be@haskell.org> Message-ID: <061.4abde5b6d3106b0d1adce8ad907b0929@haskell.org> #15414: Why both gen and gen_no in bdescr? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): In principle you could also drop `start` since it is somewhat easily computed from the bdescr address. This would all serve to trade-off some amount of false-sharing for improved cache utilization. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 22:29:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 22:29:15 -0000 Subject: [GHC] #15961: TH 'Lift' instance for 'NonEmpty' In-Reply-To: <051.90d75a5175e6db422bbc9467bb1f108a@haskell.org> References: <051.90d75a5175e6db422bbc9467bb1f108a@haskell.org> Message-ID: <066.061f01ee5ecbc591360f66012cd32e98@haskell.org> #15961: TH 'Lift' instance for 'NonEmpty' -------------------------------------+------------------------------------- Reporter: fr33domlover | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.3 Component: Template Haskell | Version: 8.6.2 Resolution: | Keywords: lift, | instance, nonempty 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 harpocrates): Please avoid using the default `Data` implementations of `Lift` (or at least explicitly define `lift = liftData`). For existing code, I would use `-XStandaloneDeriving` and `-XDeriveLift`. {{{ deriving instance Lift a => Lift (NonEmpty a) }}} I agree we should put instances in `template-haskell` now that `NonEmpty` is in `base`. I'll put up a patch and we can see what others think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 23:32:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 23:32:53 -0000 Subject: [GHC] #15935: TYPE is not generated by genprimops In-Reply-To: <045.2606d1b64e6a3965cd0d01fee77ae7f3@haskell.org> References: <045.2606d1b64e6a3965cd0d01fee77ae7f3@haskell.org> Message-ID: <060.7b827f4e1309b8b743dcd6220220f224@haskell.org> #15935: TYPE is not generated by genprimops -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.6.2 Resolution: | Keywords: GHC.Magic | TYPE haddock GHC.Prim genprimops Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): I may be missing something, but I think that all `TYPE` needs is a `primtype` declaration somewhere in `primops.txt`: {{{ primtype TYPE r {Some Haddock documentation about TYPE} }}} The `realWorld#` issue is tougher though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 23:43:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 23:43:08 -0000 Subject: [GHC] #15967: can't build ghc on Mac with any level of dwarf for base library In-Reply-To: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> References: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> Message-ID: <060.79693d602c62c122f5d3137c5f927b39@haskell.org> #15967: can't build ghc on Mac with any level of dwarf for base library -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: | -------------------------------------+------------------------------------- Comment (by AndreasK): > we have no support for debugging information on Windows (which doesn't use DWARF) I've got a lot of use out of DWARF/-g on windows. While windows centric tools don't support dwarf in general gdb does as does VTune. So having dwarf support on windows is far from useless. There are also tools to convert dwarf info into windows compatible formats but I haven't had a need to use these yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Nov 28 23:55:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Nov 2018 23:55:56 -0000 Subject: [GHC] #15961: TH 'Lift' instance for 'NonEmpty' In-Reply-To: <051.90d75a5175e6db422bbc9467bb1f108a@haskell.org> References: <051.90d75a5175e6db422bbc9467bb1f108a@haskell.org> Message-ID: <066.73e99a9bba03b26cb8bc27f91c00bc4e@haskell.org> #15961: TH 'Lift' instance for 'NonEmpty' -------------------------------------+------------------------------------- Reporter: fr33domlover | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.3 Component: Template Haskell | Version: 8.6.2 Resolution: | Keywords: lift, | instance, nonempty Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5391 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => Phab:D5391 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 00:51:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 00:51:12 -0000 Subject: [GHC] #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 In-Reply-To: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> References: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> Message-ID: <060.8d3f95d96531c7876735a47db439aa72@haskell.org> #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 ---------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by carter): @george: it looks like the errors are all "check-api" and "check-ppr" are missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 02:15:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 02:15:37 -0000 Subject: [GHC] #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found Message-ID: <042.925a06cf3801c7d8163448594b84be93@haskell.org> #15968: configure doesn't error out when --enable-dwarf-unwind is given but libdw cannot be found -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (make) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Against expectations, the GHC bindist supposedly having DWARF support provided at https://downloads.haskell.org/~ghc/8.4.4/ghc-8.4.4-x86_64-deb9-linux- dwarf.tar.xz doesn't actually have DWARF support. According to bgamari, this is because `./configure --enable-dwarf-unwind` doesn't actually complain when the required dependency `libdw` isn't found; instead, it continues silently. Most programs I know will barf out when something isn't found but also *explicitly* requested via the command line; for the cases where this wasn't, the project maintainers did consider this a bug. GHC's `./configure` suite should fail hard when `--enable-dwarf-unwind` is given but `libdw` cannot be found. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 05:30:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 05:30:52 -0000 Subject: [GHC] #15969: Generic1 deriving should use more coercions Message-ID: <045.f30261247fc730be43137d0cd1cda7d6@haskell.org> #15969: Generic1 deriving should use more coercions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Keywords: Generics | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{#!hs newtype Foo a = Foo (Maybe [a]) deriving (Generic1) }}} This produces some rather unsatisfactory Core: {{{ -- to1 worker Travv.$fGeneric1Foo1 :: forall a. Rep1 Foo a -> Maybe [a] Travv.$fGeneric1Foo1 = \ (@ a_a7RL) (ds_d9dZ :: Rep1 Foo a_a7RL) -> case ds_d9dZ `cast` of { Nothing -> GHC.Maybe.Nothing @ [a_a7RL]; Just a1_a9fD -> GHC.Maybe.Just @ [a_a7RL] (a1_a9fD `cast` ) } -- from1 worker Travv.$fGeneric1Foo2 :: forall a. Foo a -> Maybe (Rec1 [] a) Travv.$fGeneric1Foo2 = \ (@ a_a7R6) (x_a7GJ :: Foo a_a7R6) -> case x_a7GJ `cast` of { Nothing -> GHC.Maybe.Nothing @ (Rec1 [] a_a7R6); Just a1_a9fD -> GHC.Maybe.Just @ (Rec1 [] a_a7R6) (a1_a9fD `cast` ) } }}} Both of these functions could be implemented as safe coercions, but neither of them is! Similarly, if I define {{{#!hs data Bar a = Bar (Maybe [a]) deriving Generic1 }}} I get a `to1` worker that looks like {{{ Travv.$fGeneric1Bar_$cto1 :: forall a. Rep1 Bar a -> Bar a Travv.$fGeneric1Bar_$cto1 = \ (@ a_a7UA) (ds_d9ho :: Rep1 Bar a_a7UA) -> Travv.Bar @ a_a7UA (case ds_d9ho `cast` of { Nothing -> GHC.Maybe.Nothing @ [a_a7UA]; Just a1_a9iK -> GHC.Maybe.Just @ [a_a7UA] (a1_a9iK `cast` ) }) }}} That `case` expression should really just be a cast. I think the basic trick is probably to inspect the role of the type argument of each type in a composition, using that to work out whether to coerce that step. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 05:51:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 05:51:51 -0000 Subject: [GHC] #15969: Generic1 deriving should use more coercions In-Reply-To: <045.f30261247fc730be43137d0cd1cda7d6@haskell.org> References: <045.f30261247fc730be43137d0cd1cda7d6@haskell.org> Message-ID: <060.531d2d4d631bc462597039f010b75127@haskell.org> #15969: Generic1 deriving should use more coercions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Generics 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): I think this problem suggests that `Generic1` got composition the wrong way around. Let's take a slightly bigger example: {{{#!hs data Baz a = Baz (Maybe [Either Int a]) }}} We currently derive {{{#!hs Rep1 Baz = ... (Maybe :.: ([] :.: Rec1 (Either Int))) }}} Suppose we did it the other way: {{{#!hs Rep1 Baz = .... ((Rec1 Maybe :.: []) :.: Either Int) }}} then we'd have the `Rec1` "exposed" properly: {{{#!hs from1 (Baz q) = M1 (M1 (M1 (Comp1 (Comp1 (Rec1 q))))) }}} No fanciness required at all! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 05:54:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 05:54:38 -0000 Subject: [GHC] #15969: Generic1 deriving should use more coercions In-Reply-To: <045.f30261247fc730be43137d0cd1cda7d6@haskell.org> References: <045.f30261247fc730be43137d0cd1cda7d6@haskell.org> Message-ID: <060.cca6b3b9a1905bee3db879cb574733ed@haskell.org> #15969: Generic1 deriving should use more coercions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Generics 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 dfeuer): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 09:22:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 09:22:06 -0000 Subject: [GHC] #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal In-Reply-To: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> References: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> Message-ID: <065.c4bebee3c47d6e670dd48f6544f1fb86@haskell.org> #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.3 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 10:13:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 10:13:31 -0000 Subject: [GHC] #10739: Resuscitate the humble ticky-ticky profiler In-Reply-To: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> References: <046.7fb5f2d03b6936365a37558b137e1612@haskell.org> Message-ID: <061.20ea68409ce6672a8dc27404996ad23a@haskell.org> #10739: Resuscitate the humble ticky-ticky profiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8308, #9405 | Differential Rev(s): Phab:D5392 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * differential: => Phab:D5392 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 10:34:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 10:34:27 -0000 Subject: [GHC] #15969: Generic1 deriving should use more coercions In-Reply-To: <045.f30261247fc730be43137d0cd1cda7d6@haskell.org> References: <045.f30261247fc730be43137d0cd1cda7d6@haskell.org> Message-ID: <060.e7199107aae9dcec243f67e633b14e17@haskell.org> #15969: Generic1 deriving should use more coercions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Generics, | Deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: Generics => Generics, Deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 11:29:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 11:29:54 -0000 Subject: [GHC] #15846: Re-examine mkResidualConstraints In-Reply-To: <047.e9dede8c7bf14016468890fbab6fe64d@haskell.org> References: <047.e9dede8c7bf14016468890fbab6fe64d@haskell.org> Message-ID: <062.f17ce5e5d2af04b2cdef6939dbbe674b@haskell.org> #15846: Re-examine mkResidualConstraints -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Simon and I spent some time debating `TcSimplify.mkResidualConstraints`. > Here is what we learned: > > * The current code handles covars at the top level only. At one point, we > were worried about covars in nested implications. But I conjecture this > can't happen, because these would necessarily be instances of skolem- > escape, prevented elsewhere. (Why skolem-escape? Because the covar would > mention local skolems, and yet appears in the type of the variable(s) > we're trying to infer.) > > * We think that any covars that come through `mkResidualConstraints` will > ''never'' be solved. That's because there can't be given equality from an > outer context -- if there were, we'd be in the "let should not be > generalized" case and wouldn't be in `simplifyInfer`. > > * The `promoteTyVarSet` call in `mkResidualConstraints` appears to be > entirely redundant, because anything that gets caught there should also > have been caught in `decideMonoTyVars`. > > * So the only time that we should do work in `mkResidualConstraints` is > when we have deferred type errors. Perhaps with that insight, it can be > simplified. > > This ticket is to track our understanding of this function, settle on a > way to improve it, and then execute that change. At the minimum, we > should figure out whether that `promoteTyVarSet` is necessary. New description: Simon and I spent some time debating `TcSimplify.mkResidualConstraints` and the accompanying `Note [Emitting the residual implication in simplifyInfer]`. Here is what we learned: * The current code handles covars at the top level only. At one point, we were worried about covars in nested implications. But I conjecture this can't happen, because these would necessarily be instances of skolem- escape, prevented elsewhere. (Why skolem-escape? Because the covar would mention local skolems, and yet appears in the type of the variable(s) we're trying to infer.) * We think that any covars that come through `mkResidualConstraints` will ''never'' be solved. That's because there can't be given equality from an outer context -- if there were, we'd be in the "let should not be generalized" case and wouldn't be in `simplifyInfer`. * The `promoteTyVarSet` call in `mkResidualConstraints` appears to be entirely redundant, because anything that gets caught there should also have been caught in `decideMonoTyVars`. * So the only time that we should do work in `mkResidualConstraints` is when we have deferred type errors. Perhaps with that insight, it can be simplified. This ticket is to track our understanding of this function, settle on a way to improve it, and then execute that change. At the minimum, we should figure out whether that `promoteTyVarSet` is necessary. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 11:43:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 11:43:36 -0000 Subject: [GHC] #15943: "ASSERT failed" with quantified constraints In-Reply-To: <051.f4e585065410b8c1f622561bba68547c@haskell.org> References: <051.f4e585065410b8c1f622561bba68547c@haskell.org> Message-ID: <066.c9bd6f40830891463aa3708839ccd111@haskell.org> #15943: "ASSERT failed" with quantified constraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1235ca956c80d7035e1a6c50501a97de66d32b92/ghc" 1235ca95/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1235ca956c80d7035e1a6c50501a97de66d32b92" Test Trac #15943 This test seems to work in HEAD }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 11:51:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 11:51:49 -0000 Subject: [GHC] #15969: Generic1 deriving should use more coercions In-Reply-To: <045.f30261247fc730be43137d0cd1cda7d6@haskell.org> References: <045.f30261247fc730be43137d0cd1cda7d6@haskell.org> Message-ID: <060.6e7885a839fe78868696a164a29f0246@haskell.org> #15969: Generic1 deriving should use more coercions -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Generics, | Deriving 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): This is a very interesting observation. I, too, have been rather annoyed by the fact that `Generic1` requires using `fmap` to implement instances involving `(:.:)`. In fact, I've pondered using `Coercible`-plus-`QuantifiedConstraints` to get replace these `fmap`s in [https://gist.github.com/RyanGlScott/cca1a0605a3b460c4af073cfce3c15fb this gist]. (It comes with its [https://ghc.haskell.org/trac/ghc/ticket/8516#comment:7 own set of problems], which is why I haven't pursued the idea further.) Remarkably, however, this technique bypasses the need to use `fmap` entirely! I'm not sure why `Generic1` didn't pick this convention to start with—perhaps they wanted `(:.:)` to be right-associative as a sort of parallel the function composition operator `(.)`, which is also associative? I can't say. Unfortunately, `(:.:)` being right-associative //is// a well established convention at this point, and switching it to be left-associative would break lots of code in the wild. Most instances of `(:.:)` tend to look like this: {{{#!hs instance (Cls f, GCls g) => GCls (f :.: g) where gmeth = ... class Cls f where meth :: ... default meth :: (Generic1, GCls (Rep1 f)) => ... meth = ... gmeth ... class GCls f where gmeth :: ... }}} That is, you give the outer type `f` an instance of the "base" class (`Cls`) and the inner type `g` an instance of the "generified" class (`GCls`). If we made `(:.:)` left-associative, then we'd have to turn this convention around and instead define: {{{#!hs instance (GCls f, Cls g) => GCls (f :.: g) where gmeth = ... }}} Is the breakage worth it? I'm inclined to say "no", since if we're going to make a backwards-incompatible change to `GHC.Generics`, then our effort might be better spent incorporating a more modern generic programming library into GHC (call it `GHC.Generics2`, perhaps) and slowly deprecating `GHC.Generics` in favor of that one. And thankfully, most modern generic programming frameworks no longer use `(:.:)`, so it's simply a non-issue there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 11:54:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 11:54:42 -0000 Subject: [GHC] #8177: Roles for type families In-Reply-To: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> References: <046.bd13b30db1cfd3d4628960446a01267b@haskell.org> Message-ID: <061.9944907390911b58db29ec0c6061262e@haskell.org> #8177: Roles for type families -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.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 RyanGlScott): * differential: Phab:D3662 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 12:08:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 12:08:48 -0000 Subject: [GHC] #15970: Recompilation bug with default class methods Message-ID: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> #15970: Recompilation bug with default class methods -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Repro as follows. A.hs: {{{ {-# OPTIONS_GHC -fno-full-laziness #-} module A (toTypedData, toTypedDataNoDef) where toTypedData :: String -> IO Int toTypedData s = wrapPrint "yoyo" $ toTypedDataNoDef s wrapPrint :: String -> IO Int -> IO Int wrapPrint s act = do putStrLn s act toTypedDataNoDef :: String -> IO Int toTypedDataNoDef s = return $ length s }}} B.hs: {{{ module B ( TypeClass(..) ) where import A class Show a => TypeClass a where getSize :: a -> IO Int getSize a = toTypedData (show a) printA :: a -> IO () }}} C.hs: {{{ module Main where import B data MyDataType = MyDataType String Int deriving Show instance TypeClass MyDataType where printA = putStrLn . show main :: IO () main = do let myValue = MyDataType "haha" 99 sz <- getSize myValue putStrLn $ show sz printA myValue }}} 1. Comment out the `-fno-full-laziness` option in A.hs 2. `rm *.o *.hi; ghc -O2 C.hs` 3. Re-enable the `-fno-full-laziness` option in A.hs 4. `ghc -O2 C.hs` Produces a linker error: {{{ C.o:Main_main1_info: error: undefined reference to 'A_toTypedData2_closure' C.o(.data.rel.ro+0x48): error: undefined reference to 'A_toTypedData2_closure' collect2: error: ld returned 1 exit status }}} Reproduced in 8.0, 8.4 and master. Probably happens in all released versions of GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 12:09:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 12:09:04 -0000 Subject: [GHC] #15970: Recompilation bug with default class methods In-Reply-To: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> References: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> Message-ID: <062.aa4e16b71a53fe16ff460f4b769649a4@haskell.org> #15970: Recompilation bug with default class methods -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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 simonmar): * owner: (none) => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 13:08:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 13:08:20 -0000 Subject: [GHC] #15970: Recompilation bug with default class methods In-Reply-To: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> References: <047.72a19a0b07493ad296ddb06a7207798f@haskell.org> Message-ID: <062.baf2957a6e1eb91fd962a8c803c8861e@haskell.org> #15970: Recompilation bug with default class methods -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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:D5394 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => patch * differential: => Phab:D5394 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 13:58:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 13:58:32 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows Message-ID: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to bring up a Hadrian builder on Windows I found the [[https://gitlab.staging.haskell.org/ghc/ghc/-/jobs/440/raw|following]]; excerpting: {{{ shakeArgsWith 0.001s 0% Function shake 0.407s 0% Database read 0.001s 0% With database 0.000s 0% Running rules 3065.940s 99% ========================= Pool finished (2932 threads, 4 max) 0.002s 0% Lint checking 1.810s 0% Total 3068.160s 100% Lint checking error - 520 values have changed since being depended upon: Key: _build/stage1/gmp/objs/zero_p.o Old: (Just File {mod=0x6D312A39,size=0x2EA,digest=0xACFF03E6} recomputed,"") New: File {mod=0x7475B8F5,size=0x2EA,digest=0xACFF03E6} Key: _build/stage1/gmp/objs/zero.o Old: (Just File {mod=0x6DA1AAD9,size=0x2F8,digest=0x586B32DC} recomputed,"") New: File {mod=0x74B61957,size=0x2F8,digest=0x586B32DC} Key: _build/stage1/gmp/objs/xor_n.o Old: (Just File {mod=0x6D9D3378,size=0x1DF,digest=0xFBB5353} recomputed,"") New: File {mod=0x74B2AAEC,size=0x1DF,digest=0xFBB5353} }}} It looks like all of the gmp objects were somehow touched during the build, but their contents are unchanged. Strangely, none of these filenames appear elsewhere in the log, so it's unclear when they could have been touched. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 13:58:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 13:58:42 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.1eb671f86b3048025bed3befd1f85661@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: alpmestan, snowleopard (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 14:01:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 14:01:21 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.d9a2fed85760306b729674bca90df236@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Changes (by bgamari): * priority: high => highest * milestone: 8.6.1 => 8.8.1 Comment: We should really try getting to the bottom of this; this causes spurious testsuite failures at least once a week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 14:15:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 14:15:46 -0000 Subject: [GHC] #15971: Hadrian fails Shake's linter on Windows In-Reply-To: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> References: <046.8d778edbcc1c34371c72194e318bcb4f@haskell.org> Message-ID: <061.80889dc090393f6514282a8db49af857@haskell.org> #15971: Hadrian fails Shake's linter on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: 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 snowleopard): * component: Compiler => Build System (Hadrian) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 14:23:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 14:23:54 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.a614d37cc6d981fb91042b4897dd4e8b@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 14:35:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 14:35:03 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.9f9763fe149edb1c1455bd7b339e56f9@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Comment (by davide): I've changed the plan. Now all remaining work (points 4, 5, and 7) are all in Phab:D52816. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 15:15:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 15:15:23 -0000 Subject: [GHC] #15972: Test nofib tests for correctness in CI Message-ID: <046.8fe3d40c0f27a0626ca7e97da6b5107e@haskell.org> #15972: Test nofib tests for correctness in CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.9 Component: Continuous | Version: 8.6.2 Integration | 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: -------------------------------------+------------------------------------- Apparently the result of the `spectral/fft2` nofib test changed at some point in the last few months. The difference is likely acceptable given the nature of the test but it's nevertheless worrying that we are only finding this out now. We really should test nofib tests for correctness as part of CI. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 15:16:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 15:16:40 -0000 Subject: [GHC] #13897: Ship check-ppr in bindist and compile during testsuite run In-Reply-To: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> References: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> Message-ID: <061.465f9dfb8dd950cd0f05ccc542393d7f@haskell.org> #13897: Ship check-ppr in bindist and compile during testsuite run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alanz Type: task | Status: upstream Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: continuous | integration, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4039 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: continuous integration => continuous integration, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 15:17:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 15:17:03 -0000 Subject: [GHC] #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 In-Reply-To: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> References: <045.e2918a18eed7c6a24e193650daae658a@haskell.org> Message-ID: <060.32b475e154f96b04eee650aff6e05783@haskell.org> #15947: 80 unexpected failiures for make test on mac on ghc 8.6.2 ---------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13897 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * related: => #13897 Comment: This sounds like #13897. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 15:21:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 15:21:13 -0000 Subject: [GHC] #15935: TYPE is not generated by genprimops In-Reply-To: <045.2606d1b64e6a3965cd0d01fee77ae7f3@haskell.org> References: <045.2606d1b64e6a3965cd0d01fee77ae7f3@haskell.org> Message-ID: <060.ff7897b783f0a9a2328a47735a6391ed@haskell.org> #15935: TYPE is not generated by genprimops -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.6.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 bgamari): * keywords: GHC.Magic TYPE haddock GHC.Prim genprimops => newcomer Comment: It's not quite that simple; `utils/genprimop` knows nothing of the `r` tyvar. You will need to introduce such a variable, along with a `primtype` for `RuntimeRep` itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 15:51:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 15:51:17 -0000 Subject: [GHC] #15414: Why both gen and gen_no in bdescr? In-Reply-To: <046.3e22919acbe44581425bc44a28f802be@haskell.org> References: <046.3e22919acbe44581425bc44a28f802be@haskell.org> Message-ID: <061.28249e1ebfb4e35cf8514a8bb60fdf29@haskell.org> #15414: Why both gen and gen_no in bdescr? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Yes that's right. I had planned to do the experiment of removing `start` at some point and measuring the difference, but never got around to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 16:16:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 16:16:14 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.b985bf171aed3f1a6ee859a309580e62@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Comment (by Alp Mestanogullari ): In [changeset:"fb9971607c5a41ade71338188c683ee9cb8ca6fc/ghc" fb99716/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fb9971607c5a41ade71338188c683ee9cb8ca6fc" Hadrian: bump Cabal submodule, install extra dynamic flavours of RTS Previously, Hadrian was building all the appropriate dynamic ways for libHSrts but they were not picked up and installed in the package database when we register the rts library. Since we use Cabal for registering packages and the .cabal files of packages as sources of truth for configuring and installing, we ended up patching Cabal to add a new field, 'extra-dynamic-library-flavours', to specify those extra flavours to install in .cabal files: https://github.com/haskell/cabal/pull/5606 We now make use of this in rts.cabal.in to expose dynamic flavours behind a Cabal flag, which Hadrian will use whenever we are building a GHC flavour that requires dynamic libraries. This is all part of a larger plan to build a dynamic stage 2 GHC by default, like with make, which in turn will fix a lot of test failures. See Test Plan: hadrian/build.sh _build/stage1/lib/package.conf.d/rts-1.0.conf _build/stage1/lib/x86_64-.../ should contain many libHSrts-*.so Reviewers: snowleopard, DavidEichmann, bgamari, erikd, simonmar Reviewed By: snowleopard, DavidEichmann Subscribers: rwbarton, carter GHC Trac Issues: #15837 Differential Revision: https://phabricator.haskell.org/D5385 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 16:38:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 16:38:33 -0000 Subject: [GHC] #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal In-Reply-To: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> References: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> Message-ID: <065.87b6b9aafb72f8c23f3ebe263ddf258d@haskell.org> #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.3 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): At one point in time (a release of GHC or two ago), I attempted to implement this, but ran into interface file-related issues. Unfortunately, I no longer have the exact errors in front of me, but I recall that there was some difficulty due to the fact that: 1. We were deriving `Lift` instances in `Language.Haskell.TH.Syntax` 2. The derived `Lift` code references functions from `Language.Haskell.TH.Lib.Internal` 3. Because `Language.Haskell.TH.Lib.Internal` imports `Language.Haskell.TH.Syntax`, there were (seemingly) some issues with import cycles That being said, I just tried implementing this afresh with GHC 8.6.2 as my bootstrapping compiler, and I did not hit any issues at all! This is quite strange, and I'm somewhat paranoid that there //is// an issue lurking underneath the surface that I just haven't exposed yet. While typing this out, I realized one thing. I think the last time I tried this, I might have been using GHC 8.2.2 as my bootstrapping compiler. There is a notable difference between 8.2.2 and future major releases: 8.2.2 does //not// have `Language.Haskell.TH.Lib.Internal` (it wouldn't be until 8.4 that that would come into existence). I think GHC might have been confused because the `DeriveLift`-generated code that the bootstrapping compiler (8.2.2) generated mentioned things from `Language.Haskell.TH.Lib`, but the stage-1 compiler generated `DeriveLift` code that mentioned `Language.Haskell.TH.Lib.Internal`. If that's the case, then that would explain why I can't reproduce the issue now (with 8.6.2). Still, this has me a bit worried that what we're doing here is a bit fragile, and that perhaps moving functions from `Language.Haskell.TH.Lib.Internal` to some other, hypothetical module in the future might cause this issue to surface once more... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 16:40:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 16:40:14 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.e2e9817beebc6c0d2c6f2d2584661722@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Unfortunately this severely limits the usability of DWARF on the whole. In general one can only reliably unwind the stack if unwinding tables are available for all code in the running image. If you find a single frame for which there is no unwind information (or a frame pointer) available you must stop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:22:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:22:59 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.ab9f02474aa1b318bf559ec054425e11@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Comment (by Alp Mestanogullari ): In [changeset:"79d5427e1f9de02c0b171bf5db46b6b49c6f85e3/ghc" 79d5427e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="79d5427e1f9de02c0b171bf5db46b6b49c6f85e3" Hadrian: support dynamically linking ghc * (#15837 point 5) Use the -rpath gcc option and using the $ORIGIN variable which the dynamic linker sets to the location of the ghc binary. * (#15837 point 4) "-fPIC -dynamic" options are used when building ghc when either ghc or the rts have a dynamic way. * (#15837 point 7) "-shared -dynload deploy" options are only used when linking a library (no longer when linking a program). Reviewers: bgamari, alpmestan Reviewed By: alpmestan Subscribers: adamse, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5281 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:04 -0000 Subject: [GHC] #15809: Use level numbers for generalisation In-Reply-To: <046.a6e0ab66a770cc4806a0fa3da3482ff2@haskell.org> References: <046.a6e0ab66a770cc4806a0fa3da3482ff2@haskell.org> Message-ID: <061.94278a46f45d25d07b5960948f1d7274@haskell.org> #15809: Use level numbers for generalisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Simon Peyton Jones ): In [changeset:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:04 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.c388d12e9604d06e99b46aa6f91c88da@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | dependent/should_fail/T14880{,-2} Blocked By: | Blocking: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:04 -0000 Subject: [GHC] #15874: Data families with higher-rank kinds In-Reply-To: <051.72eddd9af5815eb989f802af554eb1bb@haskell.org> References: <051.72eddd9af5815eb989f802af554eb1bb@haskell.org> Message-ID: <066.26fe7ae4e04d249a76480276f62908eb@haskell.org> #15874: Data families with higher-rank kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:04 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.fbc31f77bdecab6dc55297d118d27c33@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15592{,b} Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:04 -0000 Subject: [GHC] #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind-check In-Reply-To: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> References: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> Message-ID: <065.b2c2bf062cd89393ad0a6df4d98f4113@haskell.org> #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind- check -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 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 Simon Peyton Jones ): In [changeset:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:04 -0000 Subject: [GHC] #15764: GHC panic from PolyKinds + DataKinds In-Reply-To: <051.fa1a75fe8be67f6456bdec06d1e8c54f@haskell.org> References: <051.fa1a75fe8be67f6456bdec06d1e8c54f@haskell.org> Message-ID: <066.f643d1c3a5c5d7edd9a60519a0595023@haskell.org> #15764: GHC panic from PolyKinds + DataKinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Simon Peyton Jones ): In [changeset:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:04 -0000 Subject: [GHC] #15804: GHC panic: data T :: (a :: k) -> * In-Reply-To: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> References: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> Message-ID: <066.e1f0e2f58b251940870aa46cd0be6616@haskell.org> #15804: GHC panic: data T :: (a :: k) -> * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15881 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:04 -0000 Subject: [GHC] #15789: GHC panic using visible kind applications and a higher-rank kind In-Reply-To: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> References: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> Message-ID: <066.cd7b4b4dbf6eaab83c1f7c9bf8aad371@haskell.org> #15789: GHC panic using visible kind applications and a higher-rank kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:05 -0000 Subject: [GHC] #15870: No skolem info panic In-Reply-To: <044.4ebde572f532e7733582e43832fd0055@haskell.org> References: <044.4ebde572f532e7733582e43832fd0055@haskell.org> Message-ID: <059.70d1c81a456bad147225194c1d7ae971@haskell.org> #15870: No skolem info panic -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:05 -0000 Subject: [GHC] #15740: Type family with higher-rank result is too accepting In-Reply-To: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> References: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> Message-ID: <062.fb55849a48bedc11f8823940f9591932@haskell.org> #15740: Type family with higher-rank result is too accepting -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15793 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:05 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315817=3A_Data_family_quantification?= =?utf-8?b?ID0gR0hDIHBhbmljLCDigJhpbXBvc3NpYmxl4oCZIGhhcHBlbmVk?= In-Reply-To: <051.141a919b387f59325ecc3d36f5a6a348@haskell.org> References: <051.141a919b387f59325ecc3d36f5a6a348@haskell.org> Message-ID: <066.6ed63a5fcef87666a019437674e30c0d@haskell.org> #15817: Data family quantification = GHC panic, ‘impossible’ happened -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:28:04 -0000 Subject: [GHC] #15881: GHC Panic: data A n (a :: n) :: a -> Type In-Reply-To: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> References: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> Message-ID: <066.6d5ef6adad6f63ffa9929359c4fe09bb@haskell.org> #15881: GHC Panic: data A n (a :: n) :: a -> Type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15804 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2257a86daa72db382eb927df12a718669d5491f8/ghc" 2257a86d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2257a86daa72db382eb927df12a718669d5491f8" Taming the Kind Inference Monster My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:33:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:33:54 -0000 Subject: [GHC] #15874: Data families with higher-rank kinds In-Reply-To: <051.72eddd9af5815eb989f802af554eb1bb@haskell.org> References: <051.72eddd9af5815eb989f802af554eb1bb@haskell.org> Message-ID: <066.9d195e3ceed1a431ae316a8bfc668d07@haskell.org> #15874: Data families with higher-rank kinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15874 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T15874 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:36:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:36:21 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.4083d1e2c227f72384e4a7c8418cbcf5@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15592, T15592b Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: polykinds/T15592{,b} => polykinds/T15592, T15592b * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:36:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:36:53 -0000 Subject: [GHC] #15804: GHC panic: data T :: (a :: k) -> * In-Reply-To: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> References: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> Message-ID: <066.ca20c73638068dd22718e1979dc86351@haskell.org> #15804: GHC panic: data T :: (a :: k) -> * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15804 Blocked By: | Blocking: Related Tickets: #15881 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T15804 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:37:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:37:51 -0000 Subject: [GHC] #15764: GHC panic from PolyKinds + DataKinds In-Reply-To: <051.fa1a75fe8be67f6456bdec06d1e8c54f@haskell.org> References: <051.fa1a75fe8be67f6456bdec06d1e8c54f@haskell.org> Message-ID: <066.235cd1e94ad58c7cf869fac3930f8bb9@haskell.org> #15764: GHC panic from PolyKinds + DataKinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T15764, | should_compile/T15764a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_fail/T15764, should_compile/T15764a * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:38:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:38:23 -0000 Subject: [GHC] #15789: GHC panic using visible kind applications and a higher-rank kind In-Reply-To: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> References: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> Message-ID: <066.67d82f03b24e62d462806c5dfc39731d@haskell.org> #15789: GHC panic using visible kind applications and a higher-rank kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15789 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T15789 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:38:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:38:49 -0000 Subject: [GHC] #15870: No skolem info panic In-Reply-To: <044.4ebde572f532e7733582e43832fd0055@haskell.org> References: <044.4ebde572f532e7733582e43832fd0055@haskell.org> Message-ID: <059.5553b64823646646124b8a19268d4059@haskell.org> #15870: No skolem info panic -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: indexed- crash or panic | types/should_fail/T15870 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_fail/T15870 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:39:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:39:23 -0000 Subject: [GHC] #15740: Type family with higher-rank result is too accepting In-Reply-To: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> References: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> Message-ID: <062.84a573ac69c886df2d0a41f3a05322f3@haskell.org> #15740: Type family with higher-rank result is too accepting -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_fail/T15740, | should_compile/T15740a Blocked By: | Blocking: Related Tickets: #15793 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_fail/T15740, should_compile/T15740a * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:40:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:40:08 -0000 Subject: [GHC] #15881: GHC Panic: data A n (a :: n) :: a -> Type In-Reply-To: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> References: <051.9ca499283d00d01329d4030c09c60dec@haskell.org> Message-ID: <066.750ea9f416f347f6d7cca9022c58c201@haskell.org> #15881: GHC Panic: data A n (a :: n) :: a -> Type -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15881, T15881a Blocked By: | Blocking: Related Tickets: #15804 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T15881, T15881a * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:42:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:42:14 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315817=3A_Data_family_quantification?= =?utf-8?b?ID0gR0hDIHBhbmljLCDigJhpbXBvc3NpYmxl4oCZIGhhcHBlbmVk?= In-Reply-To: <051.141a919b387f59325ecc3d36f5a6a348@haskell.org> References: <051.141a919b387f59325ecc3d36f5a6a348@haskell.org> Message-ID: <066.6e4663e00f029b787326409714bef2cd@haskell.org> #15817: Data family quantification = GHC panic, ‘impossible’ happened -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15817 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T15817 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:49:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:49:19 -0000 Subject: [GHC] #15973: Int used to represent target integer literals Message-ID: <046.8d7be0ce7920b1b1ea4653aefb2fa9b9@haskell.org> #15973: Int used to represent target integer literals -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are numerous places within GHC where we use `Int` to represent a constant literal for the target. For instance, `CmmUtils` has the following: {{{#!hs -- XXX: should really be Integer, since Int doesn't necessarily cover -- the full range of target Ints. mkIntCLit :: DynFlags -> Int -> CmmLit mkIntCLit dflags i = CmmInt (toInteger i) (wordWidth dflags) }}} This could go very wrong when cross-compiling from a 32-bit machine to a 64-bit target. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 17:49:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 17:49:47 -0000 Subject: [GHC] #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind-check In-Reply-To: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> References: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> Message-ID: <065.f11f4494b4d5643ff587a8158079175e@haskell.org> #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind- check -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_fail/T14887, | polykinds/T14887a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_fail/T14887, polykinds/T14887a * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 18:12:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 18:12:47 -0000 Subject: [GHC] #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal In-Reply-To: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> References: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> Message-ID: <065.59f55a267378e50fc7128315203f9cf1@haskell.org> #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.3 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, I decided that I wanted to remember exactly what the error message was, so I compiled GHC 8.4.4 using 8.2.2 as the bootstrapping compiler. Here is the error that I got: {{{ $ PATH=/opt/ghc/8.2.2/bin:$PATH make -j1 ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds "/opt/ghc/8.2.2/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -this-unit-id template- haskell-2.13.0.0 -hide-all-packages -i -ilibraries/template-haskell/. -ilibraries/template-haskell/dist-boot/build -Ilibraries/template-haskell /dist-boot/build -ilibraries/template-haskell/dist-boot/build/./autogen -Ilibraries/template-haskell/dist-boot/build/./autogen -Ilibraries /template-haskell/. -optP-include -optPlibraries/template-haskell/dist- boot/build/./autogen/cabal_macros.h -package-id base-4.10.1.0 -package-id ghc-boot-th-8.4.4 -package-id pretty-1.1.3.3 -Wall -this-unit-id template- haskell -XHaskell2010 -no-user-package-db -rtsopts -fno-warn- deprecated-flags -odir libraries/template-haskell/dist-boot/build -hidir libraries/template-haskell/dist-boot/build -stubdir libraries /template-haskell/dist-boot/build -c libraries/template- haskell/./Language/Haskell/TH/Syntax.hs -o libraries/template-haskell /dist-boot/build/Language/Haskell/TH/Syntax.o libraries/template-haskell/Language/Haskell/TH/Syntax.hs:2002:43: error: • Failed to load interface for ‘Language.Haskell.TH.Lib’ Use -v to see a list of the files searched for. • In the expression: Language.Haskell.TH.Lib.conE (mkNameG_d "template-haskell" "Language.Haskell.TH.Syntax" "NominalR") In an equation for ‘lift’: lift NominalR = Language.Haskell.TH.Lib.conE (mkNameG_d "template-haskell" "Language.Haskell.TH.Syntax" "NominalR") When typechecking the code for ‘lift’ in a derived instance for ‘Lift Role’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Lift Role’ | 2002 | deriving( Show, Eq, Ord, Data, Generic, Lift ) | ^^^^ libraries/template-haskell/ghc.mk:3: recipe for target 'libraries /template-haskell/dist-boot/build/Language/Haskell/TH/Syntax.o' failed make[1]: *** [libraries/template-haskell/dist- boot/build/Language/Haskell/TH/Syntax.o] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 }}} If you pass `-v`, you'll see what the culprit is: {{{ $ "/opt/ghc/8.2.2/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -package-db libraries/bootstrapping.conf -this-unit-id template- haskell-2.13.0.0 -hide-all-packages -i -ilibraries/template-haskell/. -ilibraries/template-haskell/dist-boot/build -Ilibraries/template-haskell /dist-boot/build -ilibraries/template-haskell/dist-boot/build/./autogen -Ilibraries/template-haskell/dist-boot/build/./autogen -Ilibraries /template-haskell/. -optP-include -optPlibraries/template-haskell/dist- boot/build/./autogen/cabal_macros.h -package-id base-4.10.1.0 -package-id ghc-boot-th-8.4.4 -package-id pretty-1.1.3.3 -Wall -this-unit-id template- haskell -XHaskell2010 -no-user-package-db -rtsopts -fno-warn- deprecated-flags -odir libraries/template-haskell/dist-boot/build -hidir libraries/template-haskell/dist-boot/build -stubdir libraries /template-haskell/dist-boot/build -c libraries/template- haskell/./Language/Haskell/TH/Syntax.hs -o libraries/template-haskell /dist-boot/build/Language/Haskell/TH/Syntax.o -v Glasgow Haskell Compiler, Version 8.2.2, stage 2 booted by GHC version 8.0.2 Using binary package database: /opt/ghc/8.2.2/lib/ghc-8.2.2/package.conf.d/package.cache Using binary package database: libraries/bootstrapping.conf/package.cache package flags [-package-id base-4.10.1.0{unit base-4.10.1.0 True ([])}, -package-id ghc-boot-th-8.4.4{unit ghc-boot-th-8.4.4 True ([])}, -package-id pretty-1.1.3.3{unit pretty-1.1.3.3 True ([])}] loading package database /opt/ghc/8.2.2/lib/ghc-8.2.2/package.conf.d loading package database libraries/bootstrapping.conf package binary-0.8.5.1 overrides a previously defined package package hpc-0.6.0.3 overrides a previously defined package package Cabal-2.0.1.0 is unusable due to shadowed dependencies: binary-0.8.5.1 package ghc-8.2.2 is unusable due to shadowed dependencies: binary-0.8.5.1 hpc-0.6.0.3 ghc-boot-8.2.2 ghci-8.2.2 package ghc-boot-8.2.2 is unusable due to shadowed dependencies: binary-0.8.5.1 package ghci-8.2.2 is unusable due to shadowed dependencies: binary-0.8.5.1 ghc-boot-8.2.2 wired-in package ghc-prim mapped to ghc-prim-0.5.1.1 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.1.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.13.0.0 wired-in package ghc mapped to ghc-8.4.4 wired-in package dph-seq not found. wired-in package dph-par not found. *** Checking old interface for Language.Haskell.TH.Syntax (use -ddump-hi- diffs for more details): *** Parser [Language.Haskell.TH.Syntax]: !!! Parser [Language.Haskell.TH.Syntax]: finished in 25.95 milliseconds, allocated 36.318 megabytes *** Renamer/typechecker [Language.Haskell.TH.Syntax]: !!! Renamer/typechecker [Language.Haskell.TH.Syntax]: finished in 775.89 milliseconds, allocated 669.498 megabytes libraries/template-haskell/Language/Haskell/TH/Syntax.hs:2002:43: error: • Failed to load interface for ‘Language.Haskell.TH.Lib’ Locations searched: libraries/template-haskell/./Language/Haskell/TH/Lib.hi libraries/template-haskell/./Language/Haskell/TH/Lib.hi-boot libraries/template-haskell/dist- boot/build/Language/Haskell/TH/Lib.hi libraries/template-haskell/dist-boot/build/Language/Haskell/TH/Lib .hi-boot libraries/template-haskell/dist- boot/build/./autogen/Language/Haskell/TH/Lib.hi libraries/template-haskell/dist- boot/build/./autogen/Language/Haskell/TH/Lib.hi-boot • In the expression: Language.Haskell.TH.Lib.conE (mkNameG_d "template-haskell" "Language.Haskell.TH.Syntax" "NominalR") In an equation for ‘lift’: lift NominalR = Language.Haskell.TH.Lib.conE (mkNameG_d "template-haskell" "Language.Haskell.TH.Syntax" "NominalR") When typechecking the code for ‘lift’ in a derived instance for ‘Lift Role’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Lift Role’ | 2002 | deriving( Show, Eq, Ord, Data, Generic, Lift ) | ^^^^ *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: }}} It appears as though GHC is searching in through the interface files of the stage-1 GHC (8.4.4), but using the bootstrapping compiler's (8.2.2's) `DeriveLift` name information to determine where to search! This adds more evidence to my belief that this is quite fragile. I'm not sure how to do better, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 18:21:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 18:21:38 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.35c15f1910daf321fbd1bb40e2d25c72@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | 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:D5385 Wiki Page: | Phab:D5327 -------------------------------------+------------------------------------- Changes (by alpmestan): * status: new => closed * resolution: => fixed Comment: Both of our patches landed on master. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 18:30:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 18:30:30 -0000 Subject: [GHC] #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal In-Reply-To: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> References: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> Message-ID: <065.04a24bf956a64fbbd2a07cef6b69d5cd@haskell.org> #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.3 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Thanks for figuring out what the issue was in 8.2.2! Isn't this actually great news? Once https://phabricator.haskell.org/D5220 makes it through, the code that `Lift` will generate won't involve `conE`, `mkNameG_d`, etc. - it'll just be generating syntax for a bracket! I'm gonna try this out just to make sure I'm not missing anything. Another sanity check will be to see where we still use `THNames`. What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 18:55:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 18:55:26 -0000 Subject: [GHC] #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal In-Reply-To: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> References: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> Message-ID: <065.a375f2ef0d4297484bac05c9add1762d@haskell.org> #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.3 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:8 harpocrates]: > the code that `Lift` will generate won't involve `conE`, `mkNameG_d`, etc. - it'll just be generating syntax for a bracket! I'm not so sure. Nominally, yes, the generated code will only use the bracket syntax. But one must ask: what does the bracket syntax desugar down to? The answer may surprise you: {{{ λ> :set -ddump-simpl λ> data MyBool = F | T λ> deriving instance Lift MyBool ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 38, types: 12, coercions: 3, joins: 0/0} -- RHS size: {terms: 21, types: 2, coercions: 0, joins: 0/0} $clift_r4ul :: MyBool -> Q Exp [GblId, Arity=1, Unf=OtherCon []] $clift_r4ul = \ (ds_d4um :: MyBool) -> case ds_d4um of { F -> Language.Haskell.TH.Lib.Internal.conE (mkNameG_d (GHC.CString.unpackCString# "interactive"#) (GHC.CString.unpackCString# "Ghci4"#) (GHC.CString.unpackCString# "F"#)); T -> Language.Haskell.TH.Lib.Internal.conE (mkNameG_d (GHC.CString.unpackCString# "interactive"#) (GHC.CString.unpackCString# "Ghci4"#) (GHC.CString.unpackCString# "T"#)) } -- RHS size: {terms: 1, types: 0, coercions: 3, joins: 0/0} interactive:Ghci5.$fLiftMyBool [InlPrag=INLINE (sat-args=0)] :: Lift MyBool [GblId[DFunId(nt)], Arity=1, Unf=OtherCon []] interactive:Ghci5.$fLiftMyBool = $clift_r4ul `cast` (Sym (Language.Haskell.TH.Syntax.N:Lift[0] _N) :: (MyBool -> Q Exp) ~R# Lift MyBool) }}} It turns out that bracket syntax desugars down to code that, in fact, uses `conE` and `mkNameG_d`! It's a bit more indirect, but I worry that there's the same potential for fragility. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 19:05:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 19:05:36 -0000 Subject: [GHC] #15974: QuantifiedConstraints: Spurious error involving superclass constraints Message-ID: <050.d307c514290d9a7994760dbae0871226@haskell.org> #15974: QuantifiedConstraints: Spurious error involving superclass constraints -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE KindSignatures, QuantifiedConstraints, UndecidableInstances #-} }}} Consider the following datatype and two classes: {{{#!hs data X (f :: * -> *) class A a class A a => B a }}} If I create an instance `A (X f)` involving a quantified constraint {{{#!hs instance (forall a. A a => A (f a)) => A (X f) }}} then curiously, the following instance declaration for `B (X f)` is rejected with the accompanying error message: {{{#!hs instance (forall a. B a => B (f a)) => B (X f) }}} {{{ /tmp/qc.hs:11:10: error: • Could not deduce (B a) arising from the superclasses of an instance declaration from the context: forall a. B a => B (f a) bound by the instance declaration at /tmp/qc.hs:11:10-46 or from: A a bound by a quantified context at /tmp/qc.hs:1:1 Possible fix: add (B a) to the context of a quantified context • In the instance declaration for ‘B (X f)’ | 11 | instance (forall a. B a => B (f a)) => B (X f) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Notably, if the instance declaration for `A (X f)` is altered to not use a quantified constraint, as in {{{#!hs instance A (f (X f)) => A (X f) }}} or even just {{{#!hs instance A (X f) }}} then the above instance declaration for `B (X f)` is accepted. I see no reason that the `B (X f)` declaration should be rejected, even with the quantified constraint in the instance context for `A (X f)`. The error message complains that the typechecker cannot deduce `B a`, and it even suggests adding `B a` to the context of the quantified constraint, but `B a` is //already// in that context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 19:38:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 19:38:55 -0000 Subject: [GHC] #14230: Gruesome kind mismatch errors for associated data family instances In-Reply-To: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> References: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> Message-ID: <065.01a093794aaf4004b2ff912548d30eb6@haskell.org> #14230: Gruesome kind mismatch errors for associated data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14175 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): By gum, this might just be fixed. On GHC HEAD (commit 2257a86daa72db382eb927df12a718669d5491f8), we get the following error message for the first program: {{{ $ inplace/bin/ghc-stage2 --interactive ../Bug.hs GHCi, version 8.7.20181129: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( ../Bug.hs, interpreted ) ../Bug.hs:11:3: error: • Type indexes must match class instance head Expected: CD @(Maybe a) Actual: CD @(k -> *) -- Defined at ../Bug.hs:11:8 • In the data instance declaration for ‘CD’ In the instance declaration for ‘C (Maybe a)’ | 11 | data CD :: (k -> *) -> (k -> *) -> * | ^^^^^^^ }}} And the following error message for the second program: {{{ GHCi, version 8.7.20181129: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( ../Bug.hs, interpreted ) ../Bug.hs:13:14: error: • Expected kind ‘k -> *’, but ‘a’ has kind ‘*’ • In the second argument of ‘CD’, namely ‘(a :: k -> *)’ In the data instance declaration for ‘CD’ In the instance declaration for ‘C (Maybe a)’ | 13 | data CD k (a :: k -> *) :: (k -> *) -> * | ^ }}} Both of those look like pretty cromulent error messages to me. Should we check in test cases and declare victory? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 19:40:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 19:40:20 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family In-Reply-To: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> References: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> Message-ID: <065.e0db27c7bfa4734803ae209e2ea00c00@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeFamilies => TypeFamilies, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 19:43:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 19:43:51 -0000 Subject: [GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] In-Reply-To: <050.973ad933fee1878607a6ab042ec05467@haskell.org> References: <050.973ad933fee1878607a6ab042ec05467@haskell.org> Message-ID: <065.5a58362c995ebbed278de6114445a80f@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: partial- crash or panic | sigs/should_fail/T14040a Blocked By: | Blocking: Related Tickets: #13877, #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The error message has changed once again in GHC HEAD (as of commit 2257a86daa72db382eb927df12a718669d5491f8): {{{ $ inplace/bin/ghc-stage2 --interactive ../Bug.hs GHCi, version 8.7.20181129: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( ../Bug.hs, interpreted ) ../Bug.hs:34:8: error: • Cannot apply expression of type ‘Sing wl0 -> (forall y. p0 w0 'WeirdNil) -> (forall z1 (x :: z1) (xs :: WeirdList (WeirdList z1)). Sing x -> Sing xs -> p0 w1 xs -> p0 w2 ('WeirdCons x xs)) -> p0 w3 wl0’ to a visible type argument ‘(WeirdList z)’ • In the sixth argument of ‘pWeirdCons’, namely ‘(elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons)’ In the expression: pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) In an equation for ‘elimWeirdList’: elimWeirdList (SWeirdCons (x :: Sing (x :: z)) (xs :: Sing (xs :: WeirdList (WeirdList z)))) pWeirdNil pWeirdCons = pWeirdCons @z @x @xs x xs (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) | 34 | (elimWeirdList @(WeirdList z) @xs @p xs pWeirdNil pWeirdCons) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 19:43:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 19:43:54 -0000 Subject: [GHC] #15974: QuantifiedConstraints: Spurious error involving superclass constraints In-Reply-To: <050.d307c514290d9a7994760dbae0871226@haskell.org> References: <050.d307c514290d9a7994760dbae0871226@haskell.org> Message-ID: <065.19ce7f8d9bfd8e2c10a390e0ccbe2d4a@haskell.org> #15974: QuantifiedConstraints: Spurious error involving superclass constraints -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: invalid | Keywords: | 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 lexi.lambda): * status: new => closed * resolution: => invalid Comment: I discovered #14831, which is superficially related to this ticket, but I think the issues are actually distinct. The issue in that ticket is that GHC has //two different// options for solving a constraint, and it picks the wrong one. After reading some of the discussion there, however, I think I understand what’s going on in this ticket, and I don’t think it’s an issue with GHC making the wrong choice, but rather GHC having only one choice to make. In the program in the ticket, GHC is performing the following steps: 1. GHC attempts to solve the superclass constraint `A (X f)` when declaring the `B (X f)` instance. 2. Since the only way to get there is through the instance declaration for `A (X f)`, it then tries to solve the (quantified) instance context, `forall a. A a => A (f a)`. 3. GHC then attempts to solve `A (f a)`, assuming it has `A a`, and it only has one path to get there, which is through `B (f a)` (via the superclass relationship). 4. It then tries to solve `B a`, since that is the quantified context of `B (f a)`, and it gets stuck. This suggests a fix: add `forall a. A a => A (f a)` to the instance context for `B (X f)`. And indeed, the following declaration is accepted! {{{#!hs instance (forall a. A a => A (f a), forall a. B a => B (f a)) => B (X f) }}} This is unintuitive to me, since when I write, say, `Eq` and `Ord` instance on a datatype, I merely write them like {{{#!hs instance Eq a => Eq (List a) instance Ord a => Ord (List a) }}} not like {{{#!hs instance Eq a => Eq (List a) instance (Eq a, Ord a) => Ord (List a) }}} …but this works out only because `Ord a` entails `Eq a`. In this case, `forall a. B a => B (f a)` does **not** actually entail `forall a. A a => A (f a)`, so I guess this is not actually a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 19:49:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 19:49:15 -0000 Subject: [GHC] #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) In-Reply-To: <051.a307612084bbe4f5b88300af043b1425@haskell.org> References: <051.a307612084bbe4f5b88300af043b1425@haskell.org> Message-ID: <066.b50c5fb17c7de5bf4460b205d5ee9329@haskell.org> #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #13933 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): In GHC HEAD (as of commit 2257a86daa72db382eb927df12a718669d5491f8), you get the following error when compiling the original program: {{{ GHCi, version 8.7.20181129: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( ../Bug.hs, interpreted ) ../Bug.hs:10:1: error: • Illegal constraint in a kind: forall (a :: WHICH). (a ~ 'OP) => * -> * -> * • In the data type declaration for ‘Fun’ | 10 | data Fun :: forall (a :: WHICH). a ~ OP => Type -> Type -> Type where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} Which would suggest that this issue is now moot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 19:49:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 19:49:45 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.b921179b60cde0e3a1d8c277a597184e@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): Well ```./validate``` works: {{{ Beginning test run at Thu Nov 29 19:41:53 2018 GMT ====> Scanning ./all.T =====> T2632(normal) 2 of 2 [0, 0, 0] =====> T13609(normal) 2 of 2 [0, 0, 0] cd "/tmp/ghctest-z_w0fd8p/test spaces/T2632.run" && "/home/jrp/Projects/ghc/inplace/bin/ghc-stage1" -c T2632.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -Werror=compat -dno-debug-output -XTemplateHaskellQuotes -package template-haskell cd "/tmp/ghctest-z_w0fd8p/test spaces/T13609.run" && "/home/jrp/Projects/ghc/inplace/bin/ghc-stage1" -c T13609.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -Werror=compat -dno-debug-output Appending 0 stats to git notes. make: Leaving directory '/home/jrp/Projects/ghc/testsuite/tests/stage1' ==== STAGE 1 TESTS ==== SUMMARY for test run started at Thu Nov 29 19:41:53 2018 GMT 0:00:01 spent to go through 2 total tests, which gave rise to 6 test cases, of which 4 were skipped 0 had missing libraries 2 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures ==== STAGE 2 TESTS ==== Unexpected results from: TEST="T3816 user001" SUMMARY for test run started at Thu Nov 29 19:29:54 2018 GMT 0:11:59 spent to go through 6700 total tests, which gave rise to 20805 test cases, of which 13678 were skipped 42 had missing libraries 6926 expected passes 157 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 2 unexpected failures 0 unexpected stat failures Unexpected failures: /tmp/ghctest-5ion3t_r/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (normal) /tmp/ghctest-5ion3t_r/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (normal) == Start post-testsuite package check GHC package manager version 8.7.20181129 Timestamp 2018-11-29 19:29:50.847641295 UTC for /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181129/package.conf.d/package.cache using cache: /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181129/package.conf.d/package.cache db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181129/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181129/package.conf.d"] flag db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181129/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181129/package.conf.d"] == End post-testsuite package check }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 19:51:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 19:51:49 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.9fd7dc37755a976c10fdf745a854d996@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: Blocked By: | Blocking: Related Tickets: #13780 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): In GHC HEAD (as of commit 2257a86daa72db382eb927df12a718669d5491f8), you get the following error when compiling the original program: {{{ $ inplace/bin/ghc-stage2 --interactive ../Bug.hs GHCi, version 8.7.20181129: 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:1: error: • Illegal constraint in a kind: forall a. (IsTypeLit a ~ 'True) => a -> * • In the data type declaration for ‘T’ | 15 | data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} Which would suggest that this issue is now moot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 19:55:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 19:55:38 -0000 Subject: [GHC] #15801: "ASSERT failed!" with visible kind applications In-Reply-To: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> References: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> Message-ID: <066.e877c754f3c52e15f55f509ecdbf1038@haskell.org> #15801: "ASSERT failed!" with visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think a test case still needs to be added here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 20:00:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 20:00:01 -0000 Subject: [GHC] #15801: "ASSERT failed!" with visible kind applications In-Reply-To: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> References: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> Message-ID: <066.41a8ab0937705662d83f7b0bb805e552@haskell.org> #15801: "ASSERT failed!" with visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed it does. Richard says comment:2 > Hence, the test case will come with the main patch for #12045. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 20:01:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 20:01:50 -0000 Subject: [GHC] #15801: "ASSERT failed!" with visible kind applications In-Reply-To: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> References: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> Message-ID: <066.9af38ea2da3c1439ef49522be60c3540@haskell.org> #15801: "ASSERT failed!" with visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Urk, reading is hard for me today, apparently. Apologies for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 20:24:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 20:24:11 -0000 Subject: [GHC] #15975: semantics of concurrent program depends on -O level, -f[no-]omit-yields Message-ID: <049.ef147035f0171391ea67daee4859324e@haskell.org> #15975: semantics of concurrent program depends on -O level, -f[no-]omit-yields -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Runtime | Version: 8.6.2 System | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am surprised by the behaviour of the program below (the interesting property is whether it will output "foo"). Behaviours (plural) actually: it seems to depend on optimisation level, on omit-yields, and on very small changes in the source code: It does print (mostly), when compiled with -O0. It does not, when compiled with -O2. With -O2 -fno-omit-yields, it will print. With -O0 -fno-omit-yields, and when I remove the two newTVar in the beginning, it will mostly not print. How come? These differences already occur with the last two lines replaced by "forever $ return ()", so the STM stuff may be inessential here. But that's the context where I came across the problem. See also discussion at https://mail.haskell.org/pipermail/haskell- cafe/2018-November/130274.html {{{ import Control.Concurrent.STM import Control.Concurrent ( forkIO ) import Control.Monad ( forever ) import System.IO main = do atomically $ newTVar "bar" atomically $ newTVar False forkIO $ putStrLn "foo" x <- atomically $ newTVar False forever $ atomically $ writeTVar x True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 21:04:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 21:04:19 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.d0ad94184e3e30e0a61d71be6ba22af3@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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'm trying to reproduce this, but can't seem to - I tried starting a fresh build, aborting it, and then restarting, but I'm not observing any unusual pauses. Do you have more specific reproduction steps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 21:47:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 21:47:12 -0000 Subject: [GHC] #15975: semantics of concurrent program depends on -O level, -f[no-]omit-yields In-Reply-To: <049.ef147035f0171391ea67daee4859324e@haskell.org> References: <049.ef147035f0171391ea67daee4859324e@haskell.org> Message-ID: <064.ba9021172c3b2fe4b8e32573976a8758@haskell.org> #15975: semantics of concurrent program depends on -O level, -f[no-]omit-yields -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Runtime System | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): (based on https://mail.haskell.org/pipermail/haskell- cafe/2018-November/130280.html ) So my implicit assumption was that a run of the transaction manager (because "atomically") is also a yield - but this example shows that it isn't. If this is indeed the case, then this deserves to be mentioned in the documentation of Control.Concurrent.STM ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 22:29:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 22:29:22 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.a8a5e0b2364d662f9dcfe51cc2977c17@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): tdammers, how long did you let the build run for before aborting it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 22:38:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 22:38:20 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.0220d87d05348c75634c25b041f6b1b6@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I quickly rebuilt Hadrian with profiling and reproduced this. I used `hadrian/build.cabal.sh +RTS -p` to start Hadrian in a half-built tree and Ctrl-C'd it as soon as it started producing output (which took roughly 30 seconds of wall clock time): {{{ $ hadrian/build.cabal.sh +RTS -p Up to date Up to date | Run Ghc FindHsDependencies Stage0: libraries/ghc-heap/GHC/Exts/Heap.hs (and 7 more) => _build/stage0/libraries/ghc-heap/.dependencies.mk | Remove file _build/stage0/libraries/ghc-heap/.dependencies.mk.bak | Run Ghc CompileHs Stage0: _build/stage0/libraries/ghc- heap/build/GHC/Exts/Heap/Constants.hs => _build/stage0/libraries/ghc- heap/build/GHC/Exts/Heap/Constants.o | Run Ghc CompileHs Stage0: libraries/ghc- heap/GHC/Exts/Heap/ClosureTypes.hs => _build/stage0/libraries/ghc- heap/build/GHC/Exts/Heap/ClosureTypes.o ^CshakeArgsWith 0.000s 0% Function shake 0.465s 1% Database read 0.072s 0% With database 0.001s 0% Running rules 31.903s 98% ========================= Total 32.442s 100% user interrupt }}} I will attach the profile in a moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 22:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 22:39:27 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.3aa8b71e099e356bcd3ecbccf1a9b4b9@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: 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): * Attachment "hadrian.prof.xz" added. Profile from the initialization phase of a Hadrian run on a half-built tree. Wall clock runtime was approximately 30 seconds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 22:43:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 22:43:27 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.9ccdd998b25d8e8f9bacee5e70826b77@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): Given how the cost center profile accounts for only around a third of the wall clock runtime, I reran with `+RTS -s`. This suggests that we are doing an absurd amount of GC: {{{ shakeArgsWith 0.000s 0% Function shake 0.460s 1% Database read 0.074s 0% With database 0.002s 0% Running rules 34.779s 98% ========================= Total 35.315s 100% user interrupt 51,232,883,504 bytes allocated in the heap 36,169,578,656 bytes copied during GC 141,089,464 bytes maximum residency (222 sample(s)) 800,072 bytes maximum slop 401 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 36298 colls, 0 par 9.398s 9.311s 0.0003s 0.0021s Gen 1 222 colls, 0 par 11.252s 11.215s 0.0505s 0.1005s TASKS: 5 (1 bound, 4 peak workers (4 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.001s ( 0.001s elapsed) MUT time 13.275s ( 14.804s elapsed) GC time 20.650s ( 20.526s elapsed) RP time 0.000s ( 0.000s elapsed) PROF time 0.000s ( 0.000s elapsed) EXIT time 0.001s ( 0.001s elapsed) Total time 33.926s ( 35.331s elapsed) Alloc rate 3,859,448,027 bytes per MUT second Productivity 39.1% of total user, 41.9% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 22:55:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 22:55:29 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.57c8b78439a666b9ec72fa400c3f6356@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): Looking at the eventlog under threadscope suggests that we are hitting some very peculiar GC behavior. Hadrian is linked against the threaded, profiled, eventlog-enabled RTS but with `+RTS -N1`. From t=1 until around t=22 seconds we have very frequent GCs, with time roughly roughly evenly between major and minor collections. The productivity during this period is roughly 20%. Intriguingly, increasing the allocation area size to 30MB reduces the start-up GC time to around 1.5 seconds, with mutator time remaining around 12 seconds (a productivity of roughly 90%). By the way, I am bootstrapping and building Hadrian with GHC 8.4.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 23:03:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 23:03:35 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.4515f8eeede0047e471b05d0fc96fa49@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): Putting aside the GC strangeness for a bit, it still seems like Hadrian is rather slow to start. The 12 second mutator time during start-up is still rather sluggish. The profile shows the following: {{{ Thu Nov 29 17:59 2018 Time and Allocation Profiling Report (Final) hadrian +RTS -I0 -qg -l -s -p -A32M -RTS --lint --directory /home/ben/ghc/ghc total time = 16.60 secs (16598 ticks @ 1000 us, 1 processor) total alloc = 26,405,461,216 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc unionWith General.TypeMap src/General/TypeMap.hs:34:1-97 37.1 53.2 ?== Development.Shake.Internal.FilePattern src/Development/Shake/Internal/FilePattern.hs:(226,1)-(230,34) 32.3 10.4 split Data.List.Extra src/Data/List/Extra.hs:(569,1)-(571,48) 15.5 20.6 getUserRuleInternal Development.Shake.Internal.Core.Rules src/Development/Shake/Internal/Core/Rules.hs:(62,1)-(75,48) 3.1 2.2 foldr Data.ByteString.UTF8 Data/ByteString/UTF8.hs:(171,1)-(173,40) 2.6 4.1 defaultRuleFile Development.Shake.Internal.Rules.File src/Development/Shake/Internal/Rules/File.hs:(191,1)-(194,96) 1.6 0.0 decode Data.ByteString.UTF8 Data/ByteString/UTF8.hs:(68,1)-(124,32) 1.4 5.4 &%> Development.Shake.Internal.Rules.Files src/Development/Shake/Internal/Rules/Files.hs:(163,1)-(180,42) 1.1 0.7 }}} Is this what you would expect during start-up, ndmitchell? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 23:04:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 23:04:54 -0000 Subject: [GHC] #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them In-Reply-To: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> References: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> Message-ID: <059.e8057b78451f95004948c9272c85e6cb@haskell.org> #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14822, #15635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 23:09:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 23:09:19 -0000 Subject: [GHC] #15635: Implication introduction for quantified constraints In-Reply-To: <045.9730a55ea2e47eeaadddd9e4a6dedf50@haskell.org> References: <045.9730a55ea2e47eeaadddd9e4a6dedf50@haskell.org> Message-ID: <060.6b255d9420848b71c83bba68603f2d96@haskell.org> #15635: Implication introduction for quantified constraints -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: duplicate | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14937 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 23:20:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 23:20:06 -0000 Subject: [GHC] #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them In-Reply-To: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> References: <044.d2a38f2a080b1fef4440349e47b3df3b@haskell.org> Message-ID: <059.70744eb2e3d44f0203f4fcd65582fc2a@haskell.org> #14937: QuantifiedConstraints: Reify implication constraints from terms lacking them -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14822, #15635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): The magical built-in function doesn't seem like strong enough medicine. Today, you asked for {{{#!hs reifyImplication :: forall a b. (forall r. a => (b => r) -> r) -> (forall r. ((a => b) => r) -> r) }}} But tomorrow, you might need {{{#!hs reifyImplication1 :: forall a b. (forall r x. a x => (b x => r) -> r) -> (forall r. ((forall x. a x => b x) => r) -> r) reifyImplication2 :: forall a b. (forall r x y. a x y => (b x y => r) -> r) -> (forall r. ((forall x y. a x y => b x y) => r) -> r) }}} and the day after that, you may want {{{#!hs reifyImplicationQ :: forall a b y. (forall r x. a x y => (b x y => r) -> r) -> (forall r. ((forall x. a x y => b x y) => r) -> r) }}} and so on. It would be possible to offer a whole set of these primitives, but it would be a bit of a mess and never complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 23:22:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 23:22:58 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.597c6801f19758fd05ff387e500b382a@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Thanks for investigating, Ben! `Data.List.Extra.split` is used in a few places for `FilePattern` matching in `Development.Shake.Internal.FilePattern`, so I'd say this is consistent with the rest of the profiling report. We do seem to spend a large part of the startup time on various string manipulation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 23:42:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 23:42:16 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.b51680118ae7106521e47f19e89722dc@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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, if I'm not mistake the problem gets worse the farther into the build you get. For instance, I let the build continue and interrupted it at what I would guess is the 50% mark (while building `libraries/pretty`). Restarting it takes now around 40 seconds before any output is produced. The profile looks somewhat similar to the previous profiles, {{{ Thu Nov 29 18:32 2018 Time and Allocation Profiling Report (Final) hadrian +RTS -I0 -qg -l -s -p -A32M -RTS --lint --directory /home/ben/ghc/ghc total time = 39.23 secs (39231 ticks @ 1000 us, 1 processor) total alloc = 51,375,453,360 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc ?== Development.Shake.Internal.FilePattern src/Development/Shake/Internal/FilePattern.hs:(226,1)-(230,34) 34.4 15.8 split Data.List.Extra src/Data/List/Extra.hs:(569,1)-(571,48) 18.0 24.2 unionWith General.TypeMap src/General/TypeMap.hs:34:1-97 17.6 27.4 foldr Data.ByteString.UTF8 Data/ByteString/UTF8.hs:(171,1)-(173,40) 4.7 7.5 getUserRuleInternal Development.Shake.Internal.Core.Rules src/Development/Shake/Internal/Core/Rules.hs:(62,1)-(75,48) 3.4 2.3 decode Data.ByteString.UTF8 Data/ByteString/UTF8.hs:(68,1)-(124,32) 2.4 10.1 catch_ Control.Exception.Extra src/Control/Exception/Extra.hs:106:1-32 2.0 1.7 &%> Development.Shake.Internal.Rules.Files src/Development/Shake/Internal/Rules/Files.hs:(163,1)-(180,42) 1.8 1.3 firstJustM Control.Monad.Extra src/Control/Monad/Extra.hs:(243,1)-(244,69) 1.7 1.3 defaultRuleFile Development.Shake.Internal.Rules.File src/Development/Shake/Internal/Rules/File.hs:(191,1)-(194,96) 1.2 0.0 hashPtrWithSalt Data.Hashable.Class Data/Hashable/Class.hs:(723,1)-(725,23) 1.1 0.0 }}} For what it's worth, a very significant fraction of the profile weight comes from: {{{ packageRules Rules src/Rules.hs:(88,1)-(123,46) 4045 0 0.0 0.0 62.5 58.3 compilePackage Rules.Compile src/Rules/Compile.hs:(13,1)-(36,77) 4046 0 0.0 0.0 61.4 57.4 %> Development.Shake.Internal.Rules.File src/Development/Shake/Internal/Rules/File.hs:566:1-143 4047 0 0.3 0.0 13.4 8.3 ?== Development.Shake.Internal.FilePattern src/Development/Shake/Internal/FilePattern.hs:(226,1)-(230,34) 4053 0 8.0 1.2 13.1 8.3 split Data.List.Extra src/Data/List/Extra.hs:(569,1)-(571,48) 4054 78480846 5.1 7.1 5.1 7.1 shakeOpenDatabase Development.Shake.Database src/Development/Shake/Database.hs:(58,1)-(69,24) 4051 0 0.0 0.0 0.0 0.0 open Development.Shake.Internal.Core.Run src/Development/Shake/Internal/Core/Run.hs:(73,1)-(81,23) 4052 0 0.0 0.0 0.0 0.0 &%> Development.Shake.Internal.Rules.Files src/Development/Shake/Internal/Rules/Files.hs:(163,1)-(180,42) 4055 0 1.8 1.3 48.1 49.1 ?== Development.Shake.Internal.FilePattern src/Development/Shake/Internal/FilePattern.hs:(226,1)-(230,34) 4062 2225801 25.6 14.2 37.8 30.3 split Data.List.Extra src/Data/List/Extra.hs:(569,1)-(571,48) 4063 184314560 12.1 16.0 12.1 16.0 isRelativePattern Development.Shake.Internal.FilePattern src/Development/Shake/Internal/FilePattern.hs:(152,1)-(155,27) 12746 2225801 0.0 0.0 0.0 0.0 fileNameToString Development.Shake.Internal.FileName src/Development/Shake/Internal/FileName.hs:38:1-55 12747 0 0.1 0.0 8.0 17.5 fileNameToByteString Development.Shake.Internal.FileName src/Development/Shake/Internal/FileName.hs:41:1-37 12748 2225801 0.0 0.0 0.0 0.0 toString Data.ByteString.UTF8 Data/ByteString/UTF8.hs:53:1-29 12750 2225801 0.1 0.0 7.9 17.5 foldr Data.ByteString.UTF8 Data/ByteString/UTF8.hs:(171,1)-(173,40) 12751 40082494 4.7 7.5 7.9 17.5 uncons Data.ByteString.UTF8 Data/ByteString/UTF8.hs:(166,1)-(167,38) 12752 40082494 0.8 0.0 3.1 10.0 decode Data.ByteString.UTF8 Data/ByteString/UTF8.hs:(68,1)-(124,32) 12753 40082494 2.3 10.0 2.3 10.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 23:42:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 23:42:43 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.30055c89d2a8abbb445e250396133c6e@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): Ah, I see. Thanks. It is indeed mysterious to me how allocating more less to less GC time. Paraffins is a reasonably small example, with a small inner loop, so there is some hope of finding out. With `+RTS -Sstderr` you'll get info on GC calls, including the residency numbers. With `-G1` (I think) you'll get just one generation, so every GC does a full sweep and you'll get accurate residency (= live data) info. That's useful as a way to avoid accidents such as the precise moment when major GC strikes. Does the improvement continue with one generation ? (I.e. both before and after with one generation.) With a program this small it must be possible to truly understand where the better GC numbers are coming from. It's be interesting to know if ignoring closure growth improves all programs (or at least does not make them worse). Even we didn't understand why, if it's generally true we can switch it off -- or just simplify the code by removing the analysis. One idea is this. After lambda-lifting, it's possible that `go` is strict in one of its new arguments, such as x, y, or z2. Ahh... but this lambda lifting occurs after strictness analysis, so it can't be that. OK, I'm at a loss. More info needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Nov 29 23:55:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Nov 2018 23:55:42 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.56a5df4d9075f1c3768cfccc1b7d3718@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): ...and ```validate --slow``` still fails to run as above. So whatever ```--slow``` adds to the mix is incorrectly configured. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 00:08:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 00:08:06 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.0ecc78c62f1ad7469e69136066f3b60e@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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 suspect to really solve this changes in Shake will be necessary. On quickly looking at the implementation a few things stood out: * paths are split on the directory separator every time we attempt to match it against a `FilePattern`. This is apparently how we end up with 180 million calls to `split`. * paths are represented as `ByteString`. Given the storage overhead and pinned nature of `ByteString`, I suspect there is a small amount of money on the table here -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 00:08:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 00:08:26 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.bc0151bf54cc055cd636b4e95e570dec@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): Thankfully, while things get quite bad in half-built trees (as seen in comment:16), they appear to get better once the build has finished (as suggested by mpickering in comment:1). After finishing the build the no-op rebuild time is around 15 seconds. Still bad, but at least it's not 45 seconds -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 00:25:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 00:25:10 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.eae176e512235605c33dc242905be084@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): Anyways, I should move on to other things. Tobias will pick it up from here tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 00:45:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 00:45:25 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.e1936201135f3bc075b4f5dccc356ba1@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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): Phab:D5283 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"fe57a5bae3f8cb87637359f615c77f4afae86d46/ghc" fe57a5ba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fe57a5bae3f8cb87637359f615c77f4afae86d46" Fix #15828, from `More explicit foralls` Summary: Fix a bug in commit 12eeb9 which permits the following: ``` class C a where type T a b instance C (Maybe a) where type forall a b. T (Maybe a) b = b ``` where instead, the user should write: ``` instance C (Maybe a) where type forall b. T (Maybe a) b = b ``` Update the users guide to discuss scoping of type variables in explicit foralls in type family instances. Test Plan: validate Reviewers: bgamari, goldfire, monoidal Reviewed By: goldfire Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #15828 Differential Revision: https://phabricator.haskell.org/D5283 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 00:45:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 00:45:25 -0000 Subject: [GHC] #15930: Add @since-annotations to the Foldable methods In-Reply-To: <046.1181e048db0e902f4cec12b70c302d38@haskell.org> References: <046.1181e048db0e902f4cec12b70c302d38@haskell.org> Message-ID: <061.5c80909db97cfb49d1cf85e50d485370@haskell.org> #15930: Add @since-annotations to the Foldable methods -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.3 Component: Core Libraries | Version: 8.6.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): Phab:D5379 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"9e3aaf8b58d0f0e12e2d19b6928b6c2461d58dda/ghc" 9e3aaf8b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9e3aaf8b58d0f0e12e2d19b6928b6c2461d58dda" Add missing since annotations Reviewers: hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15930 Differential Revision: https://phabricator.haskell.org/D5379 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 00:45:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 00:45:25 -0000 Subject: [GHC] #15962: Type family & typeclass interaction suppresses errors In-Reply-To: <045.fbecc62354ae71f4480f06a8c4ca26eb@haskell.org> References: <045.fbecc62354ae71f4480f06a8c4ca26eb@haskell.org> Message-ID: <060.e2f2d11dc6b44a5ac2e1b3270c5a0ac7@haskell.org> #15962: Type family & typeclass interaction suppresses errors -------------------------------------+------------------------------------- Reporter: madgen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypedHoles, Resolution: | newcomer 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 Ryan Scott ): In [changeset:"8d7496c42f049578187c4e5be08963cb497c2fac/ghc" 8d7496c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d7496c42f049578187c4e5be08963cb497c2fac" Add a test case for #15962 Test Plan: make test TEST=T15962 Reviewers: RyanGlScott, bgamari Reviewed By: RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #15962 Differential Revision: https://phabricator.haskell.org/D5393 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 00:45:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 00:45:25 -0000 Subject: [GHC] #15953: GHC always dumps the output of -ddump-hpc to STDOUT In-Reply-To: <048.f3a0e06abcd2b5b6e46368df0dc20149@haskell.org> References: <048.f3a0e06abcd2b5b6e46368df0dc20149@haskell.org> Message-ID: <063.ab2af4ec0e902820d909a05f05e40780@haskell.org> #15953: GHC always dumps the output of -ddump-hpc to STDOUT -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.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:D5382 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"dcf1f9268f6b338997f2c03891d7bc57da2ee78a/ghc" dcf1f92/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dcf1f9268f6b338997f2c03891d7bc57da2ee78a" Fix #15953 by consistently using dumpIfSet_dyn to print debug output Summary: In some modules we directly dump the debugging output to STDOUT via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file` is enabled, that output should be written to a file. Easily fixed. Certain tests (T3017, Roles3, T12763 etc.) expect part of the output generated by `-ddump-types` to be in 'PprUser' style. However, generally we want all other debugging output to use 'PprDump' style. `traceTcRn` and `traceTcRnForUser` help us accomplish this. This patch also documents some missing flags in the users guide. Reviewers: RyanGlScott, bgamari, hvr Reviewed By: RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #15953 Differential Revision: https://phabricator.haskell.org/D5382 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 00:47:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 00:47:19 -0000 Subject: [GHC] #15930: Add @since-annotations to the Foldable methods In-Reply-To: <046.1181e048db0e902f4cec12b70c302d38@haskell.org> References: <046.1181e048db0e902f4cec12b70c302d38@haskell.org> Message-ID: <061.317ba5d41716c94221f50c6d9d3cda2a@haskell.org> #15930: Add @since-annotations to the Foldable methods -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.6.2 Resolution: fixed | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5379 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: 8.6.3 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 00:48:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 00:48:19 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.a49d1ec4fd17ba564b89e00e771daf9b@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T15828 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5283 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => rename/should_fail/T15828 * status: new => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 00:49:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 00:49:37 -0000 Subject: [GHC] #15962: Type family & typeclass interaction suppresses errors In-Reply-To: <045.fbecc62354ae71f4480f06a8c4ca26eb@haskell.org> References: <045.fbecc62354ae71f4480f06a8c4ca26eb@haskell.org> Message-ID: <060.a674f75052a5f6a8a0a3da8f23620e7d@haskell.org> #15962: Type family & typeclass interaction suppresses errors -------------------------------------+------------------------------------- Reporter: madgen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypedHoles, Resolution: fixed | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | typecheck/should_fail/T15962 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_fail/T15962 * status: new => closed * resolution: => fixed * milestone: ⊥ => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 00:50:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 00:50:49 -0000 Subject: [GHC] #15953: GHC always dumps the output of -ddump-hpc to STDOUT In-Reply-To: <048.f3a0e06abcd2b5b6e46368df0dc20149@haskell.org> References: <048.f3a0e06abcd2b5b6e46368df0dc20149@haskell.org> Message-ID: <063.deceb65007a6ab73cf688be3b49c9df2@haskell.org> #15953: GHC always dumps the output of -ddump-hpc to STDOUT -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | utils/should_run/T15953 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5382 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => utils/should_run/T15953 * resolution: => fixed * milestone: 8.10.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 01:02:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 01:02:26 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.82696df629052906ccb2498b6973fbca@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T15828 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5283 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) * status: closed => new * resolution: fixed => Comment: Hm... I might have been a little too hasty in closing this ticket. This patch was undoubtedly an improvement over the status quo, as we now throw a proper error instead of silently accepting the original program. However, the error message leaves something to be desired: {{{ T15828.hs:9:3: error: • Type indexes must match class instance head Expected: T (Maybe a) _ Actual: T (Maybe a) b -- Defined at T15828.hs:9:20 • In the type instance declaration for ‘T’ In the instance declaration for ‘C (Maybe a)’ }}} Why did this fail? It's extremely hard to tell, but it's because the two `a` variables aren't the same! I suspect that we're missing some necessary tidying here. Simon, this behavior appears to be new as of your commit 2257a86daa72db382eb927df12a718669d5491f8 (`Taming the Kind Inference Monster`). In particular, this change looks suspicious: {{{#!diff + pp_expected_ty = pprIfaceType (toIfaceType (mkTyConApp fam_tc expected_args)) + -- Do /not/ tidy, because that will rename all those "_" + -- variables we have put in. And (I think) the intance type + -- is already tidy }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 05:12:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 05:12:20 -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.bdb6bbbf642f2ba45cf819194eb86e41@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.8.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 gnezdo): * cc: gnezdo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 07:05:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 07:05:07 -0000 Subject: [GHC] #15956: Linker error building `runghc` In-Reply-To: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> References: <050.1fc84599fef7e4f3d394a4a6b73df7fd@haskell.org> Message-ID: <065.7822e7886e56af016e06b4a974ea14cb@haskell.org> #15956: Linker error building `runghc` -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Oops, I never reported back! The offending commit is 561748cb507505bd5b7bd76bdc57796d896b62a2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 08:30:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 08:30:48 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.74bf2a0ae589e1fa008853d91c434bba@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): Replying to [comment:10 bgamari]: > tdammers, how long did you let the build run for before aborting it? I made multiple attempts from a freshly git-cleaned tree, aborting at various points during library compilation. A rebuild after any of these started to produce output within under 2 seconds, and started to perform actual compilation within 3 seconds. There is a significant delay (on the order of ~5-7 seconds) on the "Configure package 'ghc'" step, but nowhere near the reported 15-45 seconds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 08:32:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 08:32:21 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.2fd51f973155145fa373258e3205bc58@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): Actually, I just realized that you are using the cabal build flavor (`build.cabal.sh`), whereas I tried to reproduce with the vanilla one (`build.sh`). I'll try again with cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 08:40:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 08:40:45 -0000 Subject: [GHC] #15966: panic when using RebindableSyntax In-Reply-To: <049.7247f1a0db5afba1d19246a56c477ca0@haskell.org> References: <049.7247f1a0db5afba1d19246a56c477ca0@haskell.org> Message-ID: <064.1b74a7e8e0a6f817437e0470eddf50ae@haskell.org> #15966: panic when using RebindableSyntax -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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): Core lint fails as well: https://gist.github.com/mpickering/d72def64a6fd9df8c99e2ffe6d232dac -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 08:51:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 08:51:17 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.7d992327d27fb0cfc0b9fbe89774eb70@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): Aha! `build.cabal.sh` does indeed show a big pause between {{{Up to date}}} and the first {{{| Run}}} output (~25 seconds). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 08:52:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 08:52:06 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.ebc3f12bacbeed482d34697d470b61e7@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): If you are spending all the time in file pattern matching, I'd say that's a strong suggestion you are doing a lot more file pattern matching that is desirable. Yes, it could be faster, but in a normal build system I'd expect it to be in the weeds - less than 1%. The real culprit though is almost certainly TypeMap.unionWith, which corresponds to adding a user rule during startup (e.g. with %>). In a normal build system I'd expect perhaps 100 user rules. If you want to match on a million rules you have, you put them in a dictionary yourself and add a predicate rule. My guess is Hadrian probably has a list and unrolls it into Shake one at a time. Once you have a huge number of user rules, and match on each linearly, you become quadratic in a huge number. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 10:44:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 10:44:16 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.0dd7047e7dab9a5e0492f77cc91f89bf@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T15828 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5283 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Fix a bug in commit 12eeb9 which permits the following: What is 12eeb9? {{{ $ git show 12eeb9 fatal: ambiguous argument '12eeb9': unknown revision or path not in the working tree. }}} (In an up to date tree.) > hy did this fail? It's extremely hard to tell, but it's because the two a variables aren't the same! Quite true. So what would we ''like'' to show here? Once we decide that we can think how to achieve it. (It is perhaps fortunate that there is a dedicated pretty-printer for this particular error.) I'm quite keen on using "_" for the bits that don't matter, but if needs must, instead of printing `(F t1 t2 t3)` with one call, we can make separate calls for `t1`, `t2`, `t3` etc, and that would eliminate the need to fake-up a tyvar "_" which you'll see in the code. Would love to have your help if here if you are willing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 11:23:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 11:23:32 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.f19111d51ebe211bf83de605a1c0bae0@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): I think I know a way to reduce the number of file pattern matchings in Hadrian. Currently we generate build rules for each build context and there are hundreds of contexts, e.g. see generation of `Rules.Compile.compilePackage`: https://github.com/ghc/ghc/blob/master/hadrian/src/Rules.hs#L108 Instead, we should generate just one build rule per logical target and parse various context parameters from the path, as implemented in `libraryRules`: https://github.com/ghc/ghc/blob/master/hadrian/src/Rules/Library.hs#L22 We need to rewrite all build rules in the same manner. This will essentially replace hundred-long linear chains of file pattern matchings with a single matching and subsequent parsing. This is an obvious optimisation, but requires a good understanding of Hadrian internals. I am happy to volunteer to implement this, but I'm unlikely to find time until the end of teaching term in the university (end of December). If anyone has a chance to do this earlier, please go ahead, I can review a patch. P.S.: I still have no idea where the long pauses after `Ctrl-C`-ing come from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 12:01:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 12:01:05 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.7f1c7fd47dd837c4059debf89fd18f57@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): Thanks for pointing me to `-G1`, very interesting! The difference in bytes copied and consequently runtime is even more grave: {{{ $ ./default 19 +RTS -s -G1 > /dev/null 359,455,256 bytes allocated in the heap 334,966,000 bytes copied during GC 188,250,032 bytes maximum residency (9 sample(s)) 2,125,824 bytes maximum slop 179 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 9 colls, 0 par 0.431s 0.431s 0.0478s 0.2337s INIT time 0.000s ( 0.000s elapsed) MUT time 0.123s ( 0.123s elapsed) GC time 0.431s ( 0.431s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.554s ( 0.554s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 2,928,555,183 bytes per MUT second Productivity 22.2% of total user, 22.2% of total elapsed $ ./allow-cg 19 +RTS -s -G1 > /dev/null 401,712,312 bytes allocated in the heap 185,583,392 bytes copied during GC 97,712,192 bytes maximum residency (38 sample(s)) 1,275,840 bytes maximum slop 93 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 38 colls, 0 par 0.221s 0.221s 0.0058s 0.1098s INIT time 0.000s ( 0.000s elapsed) MUT time 0.104s ( 0.104s elapsed) GC time 0.221s ( 0.221s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.325s ( 0.325s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 3,878,228,290 bytes per MUT second Productivity 31.9% of total user, 31.9% of total elapsed }}} The residency was cut in half! Also note the difference in number of collections and that MUT is lower than the baseline (that doesn't lift the `go` function above). Probably a caching side-effect of the smaller residency, as the situation is still the same with `-A400M`, where the baseline is faster. I don't know how, but I suspect that lifting `go` causes the GC to be less conservative about liveness of some closure objects. If I had to guess, then something keeps the closure of `go` longer alive than the growing `sat2` thunk in `go`. I played around with heap/retainer profiling, but to no avail yet. Here is a gist with the `-S -G1` output: https://gist.github.com/sgraf812/5fbcf6b81fdd7c8af1a6060832bbfa11 There are two interesting things to point out: 1. The lifted version collects much more often, but only after completing the computing intensive work. Not sure why there are so many of them, seems redundant 2. Compared to the baseline, the residency (and consequently the total heap size, it seems) grows slower, but the increase in total bytes allocated leads to an additional collection before everything drops to constant space. Not sure what to make of that data, but it doesn't contradict what I said about the closure of `go` being kept alive longer than `sat2`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 12:04:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 12:04:24 -0000 Subject: [GHC] #15938: Hadrian's recompilation check is extremely slow In-Reply-To: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> References: <046.b262717c11592d3fa7c6de397ca3ee07@haskell.org> Message-ID: <061.c5e5aec5e5e9c37801a80e45e9912b88@haskell.org> #15938: Hadrian's recompilation check is extremely slow -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: | Keywords: Operating System: 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): `+RTS -s` output when starting on a half-built tree; kept hadrian running until the first proper compilations happen ("Run Ghc CompileHs ..."): {{{ 16,130,616,376 bytes allocated in the heap 1,080,660,392 bytes copied during GC 149,548,072 bytes maximum residency (12 sample(s)) 1,189,912 bytes maximum slop 339 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 14677 colls, 0 par 0.952s 1.016s 0.0001s 0.0022s Gen 1 12 colls, 0 par 0.532s 0.640s 0.0533s 0.1704s TASKS: 5 (1 bound, 4 peak workers (4 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.000s elapsed) MUT time 9.544s ( 13.735s elapsed) GC time 1.484s ( 1.656s elapsed) EXIT time 0.000s ( 0.009s elapsed) Total time 11.028s ( 15.400s elapsed) Alloc rate 1,690,131,640 bytes per MUT second Productivity 86.5% of total user, 89.2% of total elapsed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 12:16:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 12:16:23 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.c90816e5915ac06907b81d856616fa9d@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. The fact that this program has a tiny inner loop makes it feasibly to dig into. If I were doing this, I think the next thing I'd try would be to histogram the heap contents (info-pointer, number of closures with that info pointer) at each GC. This is roughly want heap profiling can do, but it may collapse too many things into one. More ambitiously, the heap profiler is supposed to be able to plot "lag"; that is, stuff that is kept alive, but is never subsequently referenced. If that is still working it'd be interesting to know whether or not the extra residency is hanging onto stuff that is never subsequently referenced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 13:02:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 13:02:19 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.709defeba18a35b59e5d7bba401e6abd@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): I'd like to give bibliographical profiling a try, but enabling profiling seems to get rid of the effects: No difference in residency anymore. If completely disable closure growth checks (not just for the particular hot loop), residency worsens. Runtime also is consistently worse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 13:05:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 13:05:46 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.8413e867b54bf14ee771b2f6a4443c39@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): ''Heap'' profiling should change nothing. (In contrast to ''time'' profiling with `-prof`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 13:30:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 13:30:09 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.c88331fe1c0372f783ceba3353ea428f@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): If I omit `-prof`, the RTS yells at me when doing anything other than `-hT` or `-h` (what's the difference between these two anyway?). The output of `-hT` is not particularly revealing: https://pp.ipd.kit.edu/~sgraf/hs/. It's climbing to 80MB for `:` and another 100MB for `C`. Interestingly, the maximum residency is higher than the baseline, so it seems it's not possible to observe the effects we are seeing without `-hT`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 13:55:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 13:55:40 -0000 Subject: [GHC] #15974: QuantifiedConstraints: Spurious error involving superclass constraints In-Reply-To: <050.d307c514290d9a7994760dbae0871226@haskell.org> References: <050.d307c514290d9a7994760dbae0871226@haskell.org> Message-ID: <065.8bc93f01f39905d3116dd04872009085@haskell.org> #15974: QuantifiedConstraints: Spurious error involving superclass constraints -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: invalid | Keywords: | 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Great explanation lexi.lambda. I too claim this is not a but. Reason: as you say: > `forall a. B a => B (f a)` does not actually entail `forall a. A a => A (f a)` So it's not a shortcoming in the implementation (although there are plenty of those). It's just that there is no way to construct evidence for `forall a. A a => A (f a)` from evidence for `forall a. B a => B (f a)` If you agree, would you like to close as invalid? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 14:03:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 14:03:11 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.ea69655f3ae294c04ac803a90a495002@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T15828 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5283 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:10 simonpj]: > What is 12eeb9? It's referring to commit 512eeb9bb9a81e915bfab25ca16bc87c62252064 (the leading "5" was simply dropped by mistake). > Quite true. So what would we ''like'' to show here? Once we decide that we can think how to achieve it. I was quite fond of the way it was printed at the time that I landed the patch: {{{ • Type indexes must match class instance head Expected: T (Maybe a1) Actual: T (Maybe a) b }}} That is, using tidying to emphasize the difference between the two `a`s. Unfortunately, I didn't notice that your commit had changed this until I `validate`d the whole set of patches I was about to commit, at which point I just accepted the new output and moved on. (Upon further thought, I realized the new output was rather smelly, which is why I reopened this ticket.) > I'm quite keen on using "_" for the bits that don't matter Sure. I have no preference as to whether we display other type variables as `_`, ``, or something else. > but if needs must, instead of printing `(F t1 t2 t3)` with one call, we can make separate calls for `t1`, `t2`, `t3` etc, and that would eliminate the need to fake-up a tyvar "_" which you'll see in the code. I'm afraid I have no idea what you are referring to with this sentence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 14:22:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 14:22:43 -0000 Subject: [GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags In-Reply-To: <042.e68200604de67ef001a98aff36406689@haskell.org> References: <042.e68200604de67ef001a98aff36406689@haskell.org> Message-ID: <057.4fbdea82f1b0b51870957ce4a5c4a3f1@haskell.org> #14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5318 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: RolandSenn => (none) * status: closed => new * resolution: fixed => Comment: The test T14452 is broken under Windows. Under Windows all the parameters of ''gcc'' including the last (''-O3'') are quoted: {{{ "C:\msys64\home\Roli\ghc\inplace\lib\../mingw/bin/gcc.exe" "-fno-stack- protector" "-DTABLES_NEXT_TO_CODE" "-x" "c" "C:\Users\Roli\AppData\Local\Temp\ghc7308_0\ghc_2.c" "-o" "C:\Users\Roli\AppData\Local\Temp\ghc7308_0\ghc_3.s" "-no-pie" "-Wimplicit" "-S" "-O2" "-include" "C:/msys64/home/Roli/ghc/includes\ghcversion.h" "-iquote." "-IC:\msys64\home\Roli\ghc\libraries\base\include" "-IC:\msys64\home\Roli\ghc\libraries\base\dist-install\build\include" "-IC:\msys64\home\Roli\ghc\libraries\integer-gmp\include" "-IC:\msys64\home\Roli\ghc\libraries\integer-gmp\dist- install\build\include" "-IC:/msys64/home/Roli/ghc/rts/dist/build" "-IC:/msys64/home/Roli/ghc/includes" "-IC:/msys64/home/Roli/ghc/includes /dist-derivedconstants/header" "-O3" }}} I'll create a better test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 14:23:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 14:23:02 -0000 Subject: [GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags In-Reply-To: <042.e68200604de67ef001a98aff36406689@haskell.org> References: <042.e68200604de67ef001a98aff36406689@haskell.org> Message-ID: <057.eefdf4992a3917f115750c423be939c1@haskell.org> #14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5318 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 14:38:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 14:38:58 -0000 Subject: [GHC] #14230: Gruesome kind mismatch errors for associated data family instances In-Reply-To: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> References: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> Message-ID: <065.828fef90723ced04c2d069a7c1bd0d19@haskell.org> #14230: Gruesome kind mismatch errors for associated data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14175 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"80d665a123305721c58a3d7652c64e2b3c69b70e/ghc" 80d665a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="80d665a123305721c58a3d7652c64e2b3c69b70e" Two tests for Trac #14230 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 14:47:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 14:47:13 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.c100cf6470fa13a7e8bfdad90fdb6024@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): It seems this whole fuzz was about nothing. Obvious in hind-sight, I wasn't aware that the maximum residency and bytes copied are just based on sampling when the GC runs, which in turn depends on heap size. Although I played around with `-A` before, I just ran a script which would find the maximum residency over multiple different heap sizes, to get these numbers: {{{ $ ./default 19 +RTS -s -G1 -A56M 359,289,696 bytes allocated in the heap 313,229,544 bytes copied during GC 192,670,160 bytes maximum residency (4 sample(s)) 2,757,856 bytes maximum slop 183 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 4 colls, 0 par 0.405s 0.405s 0.1013s 0.2541s INIT time 0.001s ( 0.001s elapsed) MUT time 0.119s ( 0.119s elapsed) GC time 0.405s ( 0.405s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.524s ( 0.525s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 3,031,050,062 bytes per MUT second Productivity 22.6% of total user, 22.6% of total elapsed $ ./allow-cg 19 +RTS -s -G1 -A76M 401,485,600 bytes allocated in the heap 331,564,512 bytes copied during GC 196,161,944 bytes maximum residency (4 sample(s)) 1,389,968 bytes maximum slop 187 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 4 colls, 0 par 0.436s 0.441s 0.1102s 0.2637s INIT time 0.001s ( 0.001s elapsed) MUT time 0.132s ( 0.132s elapsed) GC time 0.436s ( 0.441s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.569s ( 0.574s elapsed) %GC time 0.0% (0.0% elapsed) Alloc rate 3,049,743,734 bytes per MUT second Productivity 23.1% of total user, 23.0% of total elapsed }}} Still, the impact of GC parameters is very annoying. Also, when I vary `-A$iM`, where `$i` is an integer between 1 and 200, in 123 of 200 cases, the baseline has higher maximum residency than when we also decide to lift `go`. It seems that the GC parameterisation for the baseline is just in a bad (bitter?) spot. The question is, how do I sell this in the paper? I guess I could increase nursery size even further (I'm currently benchmarking with `-A128M -H1G`), but that's not very realistic, either... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 14:47:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 14:47:41 -0000 Subject: [GHC] #15961: TH 'Lift' instance for 'NonEmpty' In-Reply-To: <051.90d75a5175e6db422bbc9467bb1f108a@haskell.org> References: <051.90d75a5175e6db422bbc9467bb1f108a@haskell.org> Message-ID: <066.1b63b6e07ed5abb0cc54f0c6e61f74bc@haskell.org> #15961: TH 'Lift' instance for 'NonEmpty' -------------------------------------+------------------------------------- Reporter: fr33domlover | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.3 Component: Template Haskell | Version: 8.6.2 Resolution: | Keywords: lift, | instance, nonempty Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5391 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"47875bd4d79ca633b589e63e320aa5a5c631d096/ghc" 47875bd4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="47875bd4d79ca633b589e63e320aa5a5c631d096" Add 'Lift' instances for 'NonEmpty' and 'Void' Summary: Since 'NonEmpty' and 'Void' are now part of 'base', it makes sense that we put 'Lift' instances for them in 'template-haskell'. Not doing so is going to force users to define their own (possibly colliding) orphan instances downstream. Test Plan: ./validate Reviewers: goldfire, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15961 Differential Revision: https://phabricator.haskell.org/D5391 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 14:49:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 14:49:44 -0000 Subject: [GHC] #15961: TH 'Lift' instance for 'NonEmpty' In-Reply-To: <051.90d75a5175e6db422bbc9467bb1f108a@haskell.org> References: <051.90d75a5175e6db422bbc9467bb1f108a@haskell.org> Message-ID: <066.861d71bb50f7d6a297836bf3e4ec8b5a@haskell.org> #15961: TH 'Lift' instance for 'NonEmpty' -------------------------------------+------------------------------------- Reporter: fr33domlover | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.2 Resolution: fixed | Keywords: lift, | instance, nonempty Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5391 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: 8.6.3 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 15:04:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 15:04:45 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.1c513bf5b9cd73bba4bd166c25a9e22d@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch 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: Blocked By: | Blocking: Related Tickets: #13780, #15872 | Differential Rev(s): Phab:D5397 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5397 * related: #13780 => #13780, #15872 Comment: Phab:D5397 wraps things up by removing the outdated users' guide text about this feature, and adding a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 15:05:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 15:05:13 -0000 Subject: [GHC] #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) In-Reply-To: <051.a307612084bbe4f5b88300af043b1425@haskell.org> References: <051.a307612084bbe4f5b88300af043b1425@haskell.org> Message-ID: <066.784e4586a422cf7167ca80425655d99a@haskell.org> #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #12102, #13933 | Differential Rev(s): Phab:D5397 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5397 * related: #13933 => #12102, #13933 Comment: Phab:D5397 wraps things up by removing the outdated users' guide text about this feature, and adding a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 15:05:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 15:05:31 -0000 Subject: [GHC] #15974: QuantifiedConstraints: Spurious error involving superclass constraints In-Reply-To: <050.d307c514290d9a7994760dbae0871226@haskell.org> References: <050.d307c514290d9a7994760dbae0871226@haskell.org> Message-ID: <065.84a11897d9d5431f95acb48845d29daf@haskell.org> #15974: QuantifiedConstraints: Spurious error involving superclass constraints -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: invalid | Keywords: | 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: | -------------------------------------+------------------------------------- Comment (by lexi.lambda): > If you agree, would you like to close as invalid? Yes, I have already done so, though I appreciate the confirmation that my reasoning was correct. Sorry for the noise! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 15:06:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 15:06:28 -0000 Subject: [GHC] #14230: Gruesome kind mismatch errors for associated data family instances In-Reply-To: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> References: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> Message-ID: <065.bf8d239041087f955b705234cdb15a5a@haskell.org> #14230: Gruesome kind mismatch errors for associated data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: indexed- error message | types/should_fail/T14230{,a} Blocked By: | Blocking: Related Tickets: #14175 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => indexed-types/should_fail/T14230{,a} * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 15:22:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 15:22:28 -0000 Subject: [GHC] #15976: Can't run nofib in parallel Message-ID: <044.6b763c1045515d0de2893323c731af6a@haskell.org> #15976: Can't run nofib in parallel -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: NoFib | Version: benchmark suite | 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 was under the impression that `make -j$n` within `nofib` would run benchmarks in parallel, but it doesn't. The following warning is indicative: {{{ make[1]: warning: -jN forced in submake: disabling jobserver mode. }}} Whenever `make` is called recursively, any `-j` flags will lead to this warning and consequently disable parallelisation (which would lead to a number of jobs exponential in the depth of recursive calls). Parallel benchmarks are useful to get deterministic metrics such as allocations or counted instructions really fast. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 15:28:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 15:28:02 -0000 Subject: [GHC] #15972: Test nofib tests for correctness in CI In-Reply-To: <046.8fe3d40c0f27a0626ca7e97da6b5107e@haskell.org> References: <046.8fe3d40c0f27a0626ca7e97da6b5107e@haskell.org> Message-ID: <061.8e68ae96490a70b061329d871e732822@haskell.org> #15972: Test nofib tests for correctness in CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.9 Component: Continuous | Version: 8.6.2 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 sgraf): We recently committed https://phabricator.haskell.org/D4989 which adjusted some benchmarks to run for a longer time. There might be some stdout files which weren't adjusted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 15:29:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 15:29:21 -0000 Subject: [GHC] #15899: Testcase tcfail158 is broken In-Reply-To: <049.7f6552ee392f2083aa812ec96556b9fa@haskell.org> References: <049.7f6552ee392f2083aa812ec96556b9fa@haskell.org> Message-ID: <064.bb7ae71f7f9b56518782cb1bdd3d8ea2@haskell.org> #15899: Testcase tcfail158 is broken -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12906 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: This regression was introduced in commit c955a514f033a12f6d0ab0fbacec3e18a5757ab5 (`Remove decideKindGeneralisationPlan`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 15:34:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 15:34:19 -0000 Subject: [GHC] #14452: `-optc-O3` getting shadowed by automatically injected -O flags In-Reply-To: <042.e68200604de67ef001a98aff36406689@haskell.org> References: <042.e68200604de67ef001a98aff36406689@haskell.org> Message-ID: <057.cd6fe9c82ecd42ec655b315aac3f7ec3@haskell.org> #14452: `-optc-O3` getting shadowed by automatically injected -O flags -------------------------------------+------------------------------------- Reporter: hvr | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T14452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5318 Wiki Page: | Phab:D5398 -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * differential: Phab:D5318 => Phab:D5318 Phab:D5398 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 15:57:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 15:57:50 -0000 Subject: [GHC] #15899: Testcase tcfail158 is broken In-Reply-To: <049.7f6552ee392f2083aa812ec96556b9fa@haskell.org> References: <049.7f6552ee392f2083aa812ec96556b9fa@haskell.org> Message-ID: <064.eff15da362e6d6f3a0a35178a1334f64@haskell.org> #15899: Testcase tcfail158 is broken -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12906 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * cc: monoidal (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 16:04:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 16:04:02 -0000 Subject: [GHC] #15977: Restructure typechecking modules Message-ID: <047.9aa6c2afb30a286793f62adc04241498@haskell.org> #15977: Restructure typechecking modules -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Some of the kind-checking and type-checking modules have become unruly. Simon and I propose the new structure: - KcTyClsDecls will handle kind-checking and generalization of datatype declarations. (That is, `kcTyClGroup` and children, including related functions in TcHsType) - TcInstBinds will handle `tcInstDecls2` and children - TcTyConValidity will handle `checkValidTyCon` and children - Fold the rest of TcInstDecls (essentially, `tcInstDecls1`) into what's left of TcTyClsDecls. TcInstDecls is removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 16:22:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 16:22:46 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.bce241ae3368e3861d4dc5d9672ec25b@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): Ah, just remembered that counted instructions were the original reason to look into this and with the NCG, cachegrind reports less instructions for `./allow-cg 17 +RTS -s -A128M -H1G` than for `./default 17 +RTS -s -A128M -H1G`. Compiling with `-fllvm -optlo -Os` works around this, so I'll try a benchmark run with that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 16:44:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 16:44:51 -0000 Subject: [GHC] #15862: Panic with promoted types that Typeable doesn't support In-Reply-To: <050.a59278de72961367e1dea424ce2860fa@haskell.org> References: <050.a59278de72961367e1dea424ce2860fa@haskell.org> Message-ID: <065.d6c74403e2902c36c1abc42c13a5e667@haskell.org> #15862: Panic with promoted types that Typeable doesn't support -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Typeable, | TypeInType 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): * keywords: Typeable => Typeable, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 16:55:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 16:55:24 -0000 Subject: [GHC] #15923: Skip performance tests if not in a git repo In-Reply-To: <045.e5c4020e231e1edc79694f98c0600925@haskell.org> References: <045.e5c4020e231e1edc79694f98c0600925@haskell.org> Message-ID: <060.f9a0c80db89a30dc11de179cd894f923@haskell.org> #15923: Skip performance tests if not in a git repo -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: high | Milestone: 8.6.3 Component: Test Suite | Version: 8.6.2 Resolution: | Keywords: performance | tests git notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12758 | Differential Rev(s): D5367 Wiki Page: | Performance/Tests | -------------------------------------+------------------------------------- Comment (by David Eichmann ): In [changeset:"6e24a0bee0d0be8da040c3d5a1e90141abd89852/ghc" 6e24a0b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e24a0bee0d0be8da040c3d5a1e90141abd89852" Skip all performance tests if not in a git repo. Reviewers: bgamari, tdammers, osa1 Reviewed By: tdammers Subscribers: osa1, tdammers, rwbarton, carter GHC Trac Issues: #15923 Differential Revision: https://phabricator.haskell.org/D5367 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 17:25:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 17:25:57 -0000 Subject: [GHC] #13492: -p option report much less time than actual on high intensity of FFI calls application In-Reply-To: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> References: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> Message-ID: <060.8e9f8942cdfe55b93eb672ca783d41f9@haskell.org> #13492: -p option report much less time than actual on high intensity of FFI calls application -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.5 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 adamse): * cc: adamse (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 17:47:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 17:47:14 -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.ce1c722616ccb6d628951249fba98855@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.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): Phab:D4817 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): qnikst: That's up to you, really. If you think it makes sense to do it all in one patch, just do it. I suspect that it will be a rather small change, so I'd do it all in one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 17:48:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 17:48:50 -0000 Subject: [GHC] #15979: Core Lint error with LiberalTypeSynonyms Message-ID: <050.d6568a31486e44363c5be2100f0ea2e2@haskell.org> #15979: Core Lint error with LiberalTypeSynonyms -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE LiberalTypeSynonyms #-} {-# LANGUAGE PolyKinds #-} {-# OPTIONS_GHC -dcore-lint #-} module Bug where import Data.Kind type KindOf (a :: k) = k wat :: KindOf (forall (a :: ()). a) wat = () }}} {{{ $ /opt/ghc/8.6.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the type ‘KindOf (forall (a :: ()). a)’ Non-*-like kind when *-like expected: () when checking the body of forall: forall (a :: ()). a *** Offending Program *** Rec { $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Bug"#) wat :: KindOf (forall (a :: ()). a) [LclIdX] wat = () end Rec } *** End of Offense *** : error: Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 17:50:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 17:50:05 -0000 Subject: [GHC] #14230: Gruesome kind mismatch errors for associated data family instances In-Reply-To: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> References: <050.be2138b3feceaf8cddb1acd9189d3e67@haskell.org> Message-ID: <065.6bff1668be7a52b1913f08595d1a0f08@haskell.org> #14230: Gruesome kind mismatch errors for associated data family instances -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: indexed- error message | types/should_fail/T14230{,a} Blocked By: | Blocking: Related Tickets: #14175 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for identifying this one Ryan. It had completely slipped off my radar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 18:22:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 18:22:55 -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.76729077179e31bf9e30a4b53d044093@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.10.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): * priority: high => highest * milestone: 8.8.1 => 8.10.1 Comment: Given the recent activity on this I am going to bump its priority again. We should try to work this out once and for all. However, it doesn't seem likely that this will happen on a 8.8-compatible timescale. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 21:09:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 21:09:35 -0000 Subject: [GHC] #15980: unpin a mutable byte array Message-ID: <049.6fae43fc48b8f2a786c0b90fd894adb8@haskell.org> #15980: unpin a mutable byte array -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Sometimes, it necessary to allocate a mutable byte array as pinned. This commonly happens when the mutable byte array will immidiately be handed over to a `safe` FFI routine to be initialized. However, after it has been initialized, it might not be useful for it to be pinned anymore. If it's a little byte array, it may contribute to a fragmented heap. Even if it's large, the fact that the user explicitly asked pin it prohibits it from ever being added to a compact region (pinned bytearrays that were pinned simply because they are over 3KB can be added to compact regions). A workaround for either of these problems is to copy the pinned bytearray into an unpinned byte array afterwards. But that's kind of wasteful. Is it possible to have a primop {{{ unpinMutableByteArray :: MutableByteArray s -> State# s -> State# s }}} After this, the mutable byte array could be moved in memory. This would require `isMutableByteArrayPinned#` to undergo a similar transition as `sizeofMutableByteArray#` (which was superceeded by `getSizeofMutableByteArray#`) underwent. Is this possible? Or are pinned things allocated in a special place that makes unpinning impossible? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 21:41:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 21:41:39 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.60f706206b81e8bf1c71528de0ee5129@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): I think there is an option to force GC to happen more frequently, but I can't see it in the manual. Simon Marlow might know. In any case, getting an accurate residency profile, by using one generation and frequent gcs, is a Good Thing. when you do that, to the residency profiles of the two versions differ? I didn't understand the figures you show above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 21:59:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 21:59:05 -0000 Subject: [GHC] #15942: Type family used invisibly (with Visible Kind Applications) In-Reply-To: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> References: <051.a4fe98f7583aaab4f0dd66b510144eb3@haskell.org> Message-ID: <066.ce9cc194f52c6cb105c7b09035106f9a@haskell.org> #15942: Type family used invisibly (with Visible Kind Applications) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | TypeApplications, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeApplications => TypeApplications, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 22:01:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 22:01:48 -0000 Subject: [GHC] #15943: "ASSERT failed" with quantified constraints In-Reply-To: <051.f4e585065410b8c1f622561bba68547c@haskell.org> References: <051.f4e585065410b8c1f622561bba68547c@haskell.org> Message-ID: <066.818bcbf57809c1e948796679be6fc9a8@haskell.org> #15943: "ASSERT failed" with quantified constraints -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: | 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 simonpj): * status: new => closed * resolution: => fixed Comment: I'm going to declare this fixed. In an ideal world I'd track down the original cause, but life is short. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 22:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 22:21:06 -0000 Subject: [GHC] #15981: Implement the Linear Types proposal Message-ID: <047.d120bae67b3605a8591155b8b91e9b8f@haskell.org> #15981: Implement the Linear Types proposal -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 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: -------------------------------------+------------------------------------- This ticket tracks the implementation of the [https://github.com/ghc- proposals/ghc-proposals/pull/111 linear types proposal]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 23:27:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 23:27:19 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.57af8b9c86f2fe352520a87cb8f88987@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5692 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Awesome explanations. Makes sense. Thanks! Having a go at it now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 23:34:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 23:34:09 -0000 Subject: [GHC] #15981: Implement the Linear Types proposal In-Reply-To: <047.d120bae67b3605a8591155b8b91e9b8f@haskell.org> References: <047.d120bae67b3605a8591155b8b91e9b8f@haskell.org> Message-ID: <062.70ba507081a88ea9aaea8c42b2eb6cbf@haskell.org> #15981: Implement the Linear Types proposal -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 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:D5401 Wiki Page: | -------------------------------------+------------------------------------- Changes (by aspiwack): * differential: => Phab:D5401 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 23:34:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 23:34:23 -0000 Subject: [GHC] #15954: LiberalTypeSynonyms unsaturation check doesn't kick in In-Reply-To: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> References: <050.62fb22b6b518feb5c73f77868aa8d78f@haskell.org> Message-ID: <065.46159e99b33e610874fc338bfd0734e4@haskell.org> #15954: LiberalTypeSynonyms unsaturation check doesn't kick in -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler (Type | Version: 8.6.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sorry to be slow. 1. Yes, this is a good message 2. I'm not so bothered here. Is it really better to say `Illegal polymorphic type: PolyId`? It doesn't look polymorphic. (In (1) would you have preferred `Illegal polymorphic type A`? That doesn't look polymorphic either. Also if we had {{{ type A = (forall a. a->a) -> Int foo :: F A foo = ... }}} we couldn't possibly report in terms of `A`. It's easy to see why it happens: we've moved synonym expansion first! 3. `tc149`. Yes I agree, it should have `Language LiberalTypeSynonyms` at the top. I think the test predates the flag. This change fixes an outright bug; and I think the regression is arguably and improvement. So let's do it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 23:35:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 23:35:06 -0000 Subject: [GHC] #15840: Inline data constructor wrappers very late In-Reply-To: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> References: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> Message-ID: <062.7c6dfb1361d55fcd66b40c75ad96cc43@haskell.org> #15840: Inline data constructor wrappers very late -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5400 Wiki Page: | -------------------------------------+------------------------------------- Changes (by aspiwack): * differential: => Phab:D5400 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Nov 30 16:41:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Nov 2018 16:41:47 -0000 Subject: [GHC] #15978: slow test suite failures on 8.6 DARWIN : Message-ID: <045.849e4ef8731748c150c0f0c398d58d80@haskell.org> #15978: slow test suite failures on 8.6 DARWIN : -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- step to reproduce {{{ cd testsuite; make slow TEST="EtaExpandLevPoly ManyAlternatives ManyConstructors MultiLayerModules T10370 T11535 T12707 T13379 T13701 T13719 T14683 T14697 T14936 T15349 T4334 T6132 T7702 T9203 T9630 ghci063 haddock.Cabal haddock.base haddock.compiler hpc_fork signals004 space_leak_001" }}} {{{ =====> T11535(normal) 1 of 26 [0, 0, 0] cd "./deriving/should_run/T11535.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T11535 T11535.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output cd "./deriving/should_run/T11535.run" && ./T11535 =====> T11535(hpc) 1 of 26 [0, 0, 0] cd "./deriving/should_run/T11535.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T11535 T11535.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -O -fhpc cd "./deriving/should_run/T11535.run" && ./T11535 =====> T11535(optasm) 1 of 26 [0, 0, 0] cd "./deriving/should_run/T11535.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T11535 T11535.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -O -fasm cd "./deriving/should_run/T11535.run" && ./T11535 =====> T11535(profasm) 1 of 26 [0, 0, 0] cd "./deriving/should_run/T11535.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T11535 T11535.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto cd "./deriving/should_run/T11535.run" && ./T11535 +RTS -hc -p -RTS cd "./deriving/should_run/T11535.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/hp2ps" T11535 =====> T11535(ghci) 1 of 26 [0, 0, 0] cd "./deriving/should_run/T11535.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" T11535.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot- ghci -fno-ghci-history -fghci-leak-check +RTS -I0.1 -RTS < T11535.genscript Wrong exit code for T11535(ghci) (expected 0 , actual 134 ) *** unexpected failure for T11535(ghci) =====> T11535(threaded1) 1 of 26 [0, 1, 0] cd "./deriving/should_run/T11535.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T11535 T11535.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug cd "./deriving/should_run/T11535.run" && ./T11535 =====> T11535(threaded2) 1 of 26 [0, 1, 0] cd "./deriving/should_run/T11535.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T11535 T11535.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -O -threaded -eventlog cd "./deriving/should_run/T11535.run" && ./T11535 +RTS -N2 -ls -RTS =====> T11535(dyn) 1 of 26 [0, 1, 0] cd "./deriving/should_run/T11535.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T11535 T11535.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -O -dynamic cd "./deriving/should_run/T11535.run" && ./T11535 =====> T11535(profthreaded) 1 of 26 [0, 1, 0] cd "./deriving/should_run/T11535.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T11535 T11535.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -threaded cd "./deriving/should_run/T11535.run" && ./T11535 +RTS -p -RTS =====> ghci063(ghci) 2 of 26 [0, 1, 0] cd "./ghci/scripts/ghci063.run" && HC="/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" HC_OPTS ="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output " "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot- ghci -fno-ghci-history -fghci-leak-check +RTS -I0.1 -RTS < ghci063.script Actual stderr output differs from expected: diff -uw "/dev/null" "./ghci/scripts/ghci063.run/ghci063.run.stderr.normalised" --- /dev/null 2018-11-30 11:28:25.000000000 -0500 +++ ./ghci/scripts/ghci063.run/ghci063.run.stderr.normalised 2018-11-30 11:28:26.000000000 -0500 @@ -0,0 +1,2 @@ + +B.hs:1:1: parse error on input ‘***’ *** unexpected failure for ghci063(ghci) =====> T10370(optasm) 3 of 26 [0, 2, 0] cd "./perf/compiler/T10370.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T10370.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output +RTS -G1 -RTS -O -fasm +RTS -V0 -tT10370.comp.stats --machine-readable -RTS max_bytes_used value is too high: Expected T10370(optasm) max_bytes_used: 31524048 +/-15% Lower bound T10370(optasm) max_bytes_used: 26795440 Upper bound T10370(optasm) max_bytes_used: 36252656 Actual T10370(optasm) max_bytes_used: 36718312 Deviation T10370(optasm) max_bytes_used: 16.5 % peak_megabytes_allocated value is too high: Expected T10370(optasm) peak_megabytes_allocated: 117 +/-15% Lower bound T10370(optasm) peak_megabytes_allocated: 99 Upper bound T10370(optasm) peak_megabytes_allocated: 135 Actual T10370(optasm) peak_megabytes_allocated: 137 Deviation T10370(optasm) peak_megabytes_allocated: 17.1 % *** unexpected stat test failure for T10370(optasm) =====> T12707(normal) 4 of 26 [0, 2, 0] cd "./perf/compiler/T12707.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T12707.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output +RTS -V0 -tT12707.comp.stats --machine-readable -RTS =====> T12707(hpc) 4 of 26 [0, 2, 0] cd "./perf/compiler/T12707.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T12707.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fhpc +RTS -V0 -tT12707.comp.stats --machine- readable -RTS bytes allocated value is too high: Expected T12707(hpc) bytes allocated: 1141555816 +/-5% Lower bound T12707(hpc) bytes allocated: 1084478025 Upper bound T12707(hpc) bytes allocated: 1198633607 Actual T12707(hpc) bytes allocated: 3332600544 Deviation T12707(hpc) bytes allocated: 191.9 % *** unexpected stat test failure for T12707(hpc) =====> T12707(optasm) 4 of 26 [0, 2, 0] cd "./perf/compiler/T12707.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T12707.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fasm +RTS -V0 -tT12707.comp.stats --machine- readable -RTS bytes allocated value is too high: Expected T12707(optasm) bytes allocated: 1141555816 +/-5% Lower bound T12707(optasm) bytes allocated: 1084478025 Upper bound T12707(optasm) bytes allocated: 1198633607 Actual T12707(optasm) bytes allocated: 3552770216 Deviation T12707(optasm) bytes allocated: 211.2 % *** unexpected stat test failure for T12707(optasm) =====> T12707(profasm) 4 of 26 [0, 2, 0] cd "./perf/compiler/T12707.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T12707.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -prof -static -fprof-auto +RTS -V0 -tT12707.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected T12707(profasm) bytes allocated: 1141555816 +/-5% Lower bound T12707(profasm) bytes allocated: 1084478025 Upper bound T12707(profasm) bytes allocated: 1198633607 Actual T12707(profasm) bytes allocated: 4024687592 Deviation T12707(profasm) bytes allocated: 252.6 % *** unexpected stat test failure for T12707(profasm) =====> T13379(normal) 5 of 26 [0, 2, 0] cd "./perf/compiler/T13379.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T13379.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output +RTS -V0 -tT13379.comp.stats --machine-readable -RTS =====> T13379(hpc) 5 of 26 [0, 2, 0] cd "./perf/compiler/T13379.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T13379.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fhpc +RTS -V0 -tT13379.comp.stats --machine- readable -RTS bytes allocated value is too high: Expected T13379(hpc) bytes allocated: 453166912 +/-10% Lower bound T13379(hpc) bytes allocated: 407850220 Upper bound T13379(hpc) bytes allocated: 498483604 Actual T13379(hpc) bytes allocated: 1840473752 Deviation T13379(hpc) bytes allocated: 306.1 % *** unexpected stat test failure for T13379(hpc) =====> T13379(optasm) 5 of 26 [0, 2, 0] cd "./perf/compiler/T13379.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T13379.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fasm +RTS -V0 -tT13379.comp.stats --machine- readable -RTS =====> T13379(profasm) 5 of 26 [0, 2, 0] cd "./perf/compiler/T13379.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T13379.hs -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -prof -static -fprof-auto +RTS -V0 -tT13379.comp.stats --machine-readable -RTS =====> MultiLayerModules(normal) 6 of 26 [0, 2, 0] cd "./perf/compiler/MultiLayerModules.run" && ./genMultiLayerModules cd "./perf/compiler/MultiLayerModules.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" --make MultiLayerModules -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -v0 +RTS -V0 -tMultiLayerModules.comp.stats --machine-readable -RTS =====> MultiLayerModules(hpc) 6 of 26 [0, 2, 0] cd "./perf/compiler/MultiLayerModules.run" && ./genMultiLayerModules cd "./perf/compiler/MultiLayerModules.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" --make MultiLayerModules -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fhpc -v0 +RTS -V0 -tMultiLayerModules.comp.stats --machine-readable -RTS Timeout happened...killed process "cd "./perf/compiler/MultiLayerModules.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make MultiLayerModules -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -O -fhpc -v0 +RTS -V0 -tMultiLayerModules.comp.stats --machine-readable -RTS"... Compile failed (exit code 99) errors were: Failed to find field: bytes allocated *** framework failure for MultiLayerModules(hpc) 'NoneType' object has no attribute 'group' Traceback (most recent call last): File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 788, in test_common_work do_test(name, way, func, args, files) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 873, in do_test result = func(*[name,way] + args) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1004, in multimod_compile return do_compile( name, way, 0, top_mod, [], extra_hc_opts ) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1023, in do_compile result = simple_build(name, way, extra_hc_opts, should_fail, top_mod, 0, 1, **kwargs) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1235, in simple_build statsResult = checkStats(name, way, stats_file, opts.compiler_stats_range_fields) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1125, in checkStats val = int(m.group(1)) AttributeError: 'NoneType' object has no attribute 'group' =====> MultiLayerModules(optasm) 6 of 26 [0, 2, 1] cd "./perf/compiler/MultiLayerModules.run" && ./genMultiLayerModules cd "./perf/compiler/MultiLayerModules.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" --make MultiLayerModules -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fasm -v0 +RTS -V0 -tMultiLayerModules.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected MultiLayerModules(optasm) bytes allocated: 5619893176 +/-10% Lower bound MultiLayerModules(optasm) bytes allocated: 5057903858 Upper bound MultiLayerModules(optasm) bytes allocated: 6181882494 Actual MultiLayerModules(optasm) bytes allocated: 6362463680 Deviation MultiLayerModules(optasm) bytes allocated: 13.2 % *** unexpected stat test failure for MultiLayerModules(optasm) =====> MultiLayerModules(profasm) 6 of 26 [0, 2, 1] cd "./perf/compiler/MultiLayerModules.run" && ./genMultiLayerModules cd "./perf/compiler/MultiLayerModules.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" --make MultiLayerModules -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof- auto -v0 +RTS -V0 -tMultiLayerModules.comp.stats --machine-readable -RTS Timeout happened...killed process "cd "./perf/compiler/MultiLayerModules.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make MultiLayerModules -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -v0 +RTS -V0 -tMultiLayerModules.comp.stats --machine-readable -RTS"... Compile failed (exit code 99) errors were: Failed to find field: bytes allocated *** framework failure for MultiLayerModules(profasm) 'NoneType' object has no attribute 'group' Traceback (most recent call last): File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 788, in test_common_work do_test(name, way, func, args, files) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 873, in do_test result = func(*[name,way] + args) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1004, in multimod_compile return do_compile( name, way, 0, top_mod, [], extra_hc_opts ) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1023, in do_compile result = simple_build(name, way, extra_hc_opts, should_fail, top_mod, 0, 1, **kwargs) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1235, in simple_build statsResult = checkStats(name, way, stats_file, opts.compiler_stats_range_fields) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1125, in checkStats val = int(m.group(1)) AttributeError: 'NoneType' object has no attribute 'group' =====> ManyConstructors(normal) 7 of 26 [0, 2, 2] cd "./perf/compiler/ManyConstructors.run" && ./genManyConstructors cd "./perf/compiler/ManyConstructors.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make ManyConstructors -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -v0 +RTS -V0 -tManyConstructors.comp.stats --machine-readable -RTS =====> ManyConstructors(hpc) 7 of 26 [0, 2, 2] cd "./perf/compiler/ManyConstructors.run" && ./genManyConstructors cd "./perf/compiler/ManyConstructors.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make ManyConstructors -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -O -fhpc -v0 +RTS -V0 -tManyConstructors.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected ManyConstructors(hpc) bytes allocated: 4246959352 +/-10% Lower bound ManyConstructors(hpc) bytes allocated: 3822263416 Upper bound ManyConstructors(hpc) bytes allocated: 4671655288 Actual ManyConstructors(hpc) bytes allocated: 9359235576 Deviation ManyConstructors(hpc) bytes allocated: 120.4 % *** unexpected stat test failure for ManyConstructors(hpc) =====> ManyConstructors(optasm) 7 of 26 [0, 2, 2] cd "./perf/compiler/ManyConstructors.run" && ./genManyConstructors cd "./perf/compiler/ManyConstructors.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make ManyConstructors -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -O -fasm -v0 +RTS -V0 -tManyConstructors.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected ManyConstructors(optasm) bytes allocated: 4246959352 +/-10% Lower bound ManyConstructors(optasm) bytes allocated: 3822263416 Upper bound ManyConstructors(optasm) bytes allocated: 4671655288 Actual ManyConstructors(optasm) bytes allocated: 9348447040 Deviation ManyConstructors(optasm) bytes allocated: 120.1 % *** unexpected stat test failure for ManyConstructors(optasm) =====> ManyConstructors(profasm) 7 of 26 [0, 2, 2] cd "./perf/compiler/ManyConstructors.run" && ./genManyConstructors cd "./perf/compiler/ManyConstructors.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make ManyConstructors -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -v0 +RTS -V0 -tManyConstructors.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected ManyConstructors(profasm) bytes allocated: 4246959352 +/-10% Lower bound ManyConstructors(profasm) bytes allocated: 3822263416 Upper bound ManyConstructors(profasm) bytes allocated: 4671655288 Actual ManyConstructors(profasm) bytes allocated: 11167847640 Deviation ManyConstructors(profasm) bytes allocated: 163.0 % *** unexpected stat test failure for ManyConstructors(profasm) =====> ManyAlternatives(normal) 8 of 26 [0, 2, 2] cd "./perf/compiler/ManyAlternatives.run" && ./genManyAlternatives cd "./perf/compiler/ManyAlternatives.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make ManyAlternatives -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -v0 +RTS -V0 -tManyAlternatives.comp.stats --machine-readable -RTS =====> ManyAlternatives(hpc) 8 of 26 [0, 2, 2] cd "./perf/compiler/ManyAlternatives.run" && ./genManyAlternatives cd "./perf/compiler/ManyAlternatives.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make ManyAlternatives -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -O -fhpc -v0 +RTS -V0 -tManyAlternatives.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected ManyAlternatives(hpc) bytes allocated: 1398898072 +/-10% Lower bound ManyAlternatives(hpc) bytes allocated: 1259008264 Upper bound ManyAlternatives(hpc) bytes allocated: 1538787880 Actual ManyAlternatives(hpc) bytes allocated: 2101087728 Deviation ManyAlternatives(hpc) bytes allocated: 50.2 % *** unexpected stat test failure for ManyAlternatives(hpc) =====> ManyAlternatives(optasm) 8 of 26 [0, 2, 2] cd "./perf/compiler/ManyAlternatives.run" && ./genManyAlternatives cd "./perf/compiler/ManyAlternatives.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make ManyAlternatives -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -O -fasm -v0 +RTS -V0 -tManyAlternatives.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected ManyAlternatives(optasm) bytes allocated: 1398898072 +/-10% Lower bound ManyAlternatives(optasm) bytes allocated: 1259008264 Upper bound ManyAlternatives(optasm) bytes allocated: 1538787880 Actual ManyAlternatives(optasm) bytes allocated: 2069547176 Deviation ManyAlternatives(optasm) bytes allocated: 47.9 % *** unexpected stat test failure for ManyAlternatives(optasm) =====> ManyAlternatives(profasm) 8 of 26 [0, 2, 2] cd "./perf/compiler/ManyAlternatives.run" && ./genManyAlternatives cd "./perf/compiler/ManyAlternatives.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make ManyAlternatives -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -v0 +RTS -V0 -tManyAlternatives.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected ManyAlternatives(profasm) bytes allocated: 1398898072 +/-10% Lower bound ManyAlternatives(profasm) bytes allocated: 1259008264 Upper bound ManyAlternatives(profasm) bytes allocated: 1538787880 Actual ManyAlternatives(profasm) bytes allocated: 2191392512 Deviation ManyAlternatives(profasm) bytes allocated: 56.7 % *** unexpected stat test failure for ManyAlternatives(profasm) =====> T13701(normal) 9 of 26 [0, 2, 2] cd "./perf/compiler/T13701.run" && ./genT13701 cd "./perf/compiler/T13701.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T13701 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -v0 +RTS -V0 -tT13701.comp.stats --machine- readable -RTS =====> T13701(hpc) 9 of 26 [0, 2, 2] cd "./perf/compiler/T13701.run" && ./genT13701 cd "./perf/compiler/T13701.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T13701 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fhpc -v0 +RTS -V0 -tT13701.comp.stats --machine-readable -RTS Timeout happened...killed process "cd "./perf/compiler/T13701.run" && "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/inplace/test spaces/ghc-stage2" --make T13701 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fhpc -v0 +RTS -V0 -tT13701.comp.stats --machine-readable -RTS"... Compile failed (exit code 99) errors were: Failed to find field: bytes allocated *** framework failure for T13701(hpc) 'NoneType' object has no attribute 'group' Traceback (most recent call last): File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 788, in test_common_work do_test(name, way, func, args, files) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 873, in do_test result = func(*[name,way] + args) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1004, in multimod_compile return do_compile( name, way, 0, top_mod, [], extra_hc_opts ) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1023, in do_compile result = simple_build(name, way, extra_hc_opts, should_fail, top_mod, 0, 1, **kwargs) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1235, in simple_build statsResult = checkStats(name, way, stats_file, opts.compiler_stats_range_fields) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1125, in checkStats val = int(m.group(1)) AttributeError: 'NoneType' object has no attribute 'group' =====> T13701(optasm) 9 of 26 [0, 2, 3] cd "./perf/compiler/T13701.run" && ./genT13701 cd "./perf/compiler/T13701.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T13701 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fasm -v0 +RTS -V0 -tT13701.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected T13701(optasm) bytes allocated: 2549206272 +/-10% Lower bound T13701(optasm) bytes allocated: 2294285644 Upper bound T13701(optasm) bytes allocated: 2804126900 Actual T13701(optasm) bytes allocated: 3222935032 Deviation T13701(optasm) bytes allocated: 26.4 % *** unexpected stat test failure for T13701(optasm) =====> T13701(profasm) 9 of 26 [0, 2, 3] cd "./perf/compiler/T13701.run" && ./genT13701 cd "./perf/compiler/T13701.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T13701 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -prof -static -fprof-auto -v0 +RTS -V0 -tT13701.comp.stats --machine-readable -RTS Timeout happened...killed process "cd "./perf/compiler/T13701.run" && "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/inplace/test spaces/ghc-stage2" --make T13701 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -v0 +RTS -V0 -tT13701.comp.stats --machine- readable -RTS"... Compile failed (exit code 99) errors were: Failed to find field: bytes allocated *** framework failure for T13701(profasm) 'NoneType' object has no attribute 'group' Traceback (most recent call last): File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 788, in test_common_work do_test(name, way, func, args, files) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 873, in do_test result = func(*[name,way] + args) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1004, in multimod_compile return do_compile( name, way, 0, top_mod, [], extra_hc_opts ) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1023, in do_compile result = simple_build(name, way, extra_hc_opts, should_fail, top_mod, 0, 1, **kwargs) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1235, in simple_build statsResult = checkStats(name, way, stats_file, opts.compiler_stats_range_fields) File "/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/testsuite/driver/testlib.py", line 1125, in checkStats val = int(m.group(1)) AttributeError: 'NoneType' object has no attribute 'group' =====> T13719(normal) 10 of 26 [0, 2, 4] cd "./perf/compiler/T13719.run" && ./genT13719 cd "./perf/compiler/T13719.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T13719 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -v0 +RTS -V0 -tT13719.comp.stats --machine- readable -RTS =====> T13719(hpc) 10 of 26 [0, 2, 4] cd "./perf/compiler/T13719.run" && ./genT13719 cd "./perf/compiler/T13719.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T13719 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fhpc -v0 +RTS -V0 -tT13719.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected T13719(hpc) bytes allocated: 5187889872 +/-10% Lower bound T13719(hpc) bytes allocated: 4669100884 Upper bound T13719(hpc) bytes allocated: 5706678860 Actual T13719(hpc) bytes allocated: 6491534040 Deviation T13719(hpc) bytes allocated: 25.1 % *** unexpected stat test failure for T13719(hpc) =====> T13719(optasm) 10 of 26 [0, 2, 4] cd "./perf/compiler/T13719.run" && ./genT13719 cd "./perf/compiler/T13719.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T13719 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fasm -v0 +RTS -V0 -tT13719.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected T13719(optasm) bytes allocated: 5187889872 +/-10% Lower bound T13719(optasm) bytes allocated: 4669100884 Upper bound T13719(optasm) bytes allocated: 5706678860 Actual T13719(optasm) bytes allocated: 6008103400 Deviation T13719(optasm) bytes allocated: 15.8 % *** unexpected stat test failure for T13719(optasm) =====> T13719(profasm) 10 of 26 [0, 2, 4] cd "./perf/compiler/T13719.run" && ./genT13719 cd "./perf/compiler/T13719.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T13719 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -prof -static -fprof-auto -v0 +RTS -V0 -tT13719.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected T13719(profasm) bytes allocated: 5187889872 +/-10% Lower bound T13719(profasm) bytes allocated: 4669100884 Upper bound T13719(profasm) bytes allocated: 5706678860 Actual T13719(profasm) bytes allocated: 6613843944 Deviation T13719(profasm) bytes allocated: 27.5 % *** unexpected stat test failure for T13719(profasm) =====> T14697(normal) 11 of 26 [0, 2, 4] cd "./perf/compiler/T14697.run" && ./genT14697 cd "./perf/compiler/T14697.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T14697 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output $(cat T14697-flags) -v0 +RTS -V0 -tT14697.comp.stats --machine-readable -RTS =====> T14697(hpc) 11 of 26 [0, 2, 4] cd "./perf/compiler/T14697.run" && ./genT14697 cd "./perf/compiler/T14697.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T14697 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output $(cat T14697-flags) -O -fhpc -v0 +RTS -V0 -tT14697.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected T14697(hpc) bytes allocated: 371030912 +/-10% Lower bound T14697(hpc) bytes allocated: 333927820 Upper bound T14697(hpc) bytes allocated: 408134004 Actual T14697(hpc) bytes allocated: 589481848 Deviation T14697(hpc) bytes allocated: 58.9 % *** unexpected stat test failure for T14697(hpc) =====> T14697(optasm) 11 of 26 [0, 2, 4] cd "./perf/compiler/T14697.run" && ./genT14697 cd "./perf/compiler/T14697.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T14697 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output $(cat T14697-flags) -O -fasm -v0 +RTS -V0 -tT14697.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected T14697(optasm) bytes allocated: 371030912 +/-10% Lower bound T14697(optasm) bytes allocated: 333927820 Upper bound T14697(optasm) bytes allocated: 408134004 Actual T14697(optasm) bytes allocated: 434183536 Deviation T14697(optasm) bytes allocated: 17.0 % *** unexpected stat test failure for T14697(optasm) =====> T14697(profasm) 11 of 26 [0, 2, 4] cd "./perf/compiler/T14697.run" && ./genT14697 cd "./perf/compiler/T14697.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T14697 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output $(cat T14697-flags) -O -prof -static -fprof-auto -v0 +RTS -V0 -tT14697.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected T14697(profasm) bytes allocated: 371030912 +/-10% Lower bound T14697(profasm) bytes allocated: 333927820 Upper bound T14697(profasm) bytes allocated: 408134004 Actual T14697(profasm) bytes allocated: 595098104 Deviation T14697(profasm) bytes allocated: 60.4 % *** unexpected stat test failure for T14697(profasm) =====> T14683(normal) 12 of 26 [0, 2, 4] cd "./perf/compiler/T14683.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T14683 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -v0 +RTS -V0 -tT14683.comp.stats --machine- readable -RTS =====> T14683(hpc) 12 of 26 [0, 2, 4] cd "./perf/compiler/T14683.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T14683 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fhpc -v0 +RTS -V0 -tT14683.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected T14683(hpc) bytes allocated: 10521594688 +/-10% Lower bound T14683(hpc) bytes allocated: 9469435219 Upper bound T14683(hpc) bytes allocated: 11573754157 Actual T14683(hpc) bytes allocated: 24859356896 Deviation T14683(hpc) bytes allocated: 136.3 % *** unexpected stat test failure for T14683(hpc) =====> T14683(optasm) 12 of 26 [0, 2, 4] cd "./perf/compiler/T14683.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T14683 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fasm -v0 +RTS -V0 -tT14683.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected T14683(optasm) bytes allocated: 10521594688 +/-10% Lower bound T14683(optasm) bytes allocated: 9469435219 Upper bound T14683(optasm) bytes allocated: 11573754157 Actual T14683(optasm) bytes allocated: 24961281960 Deviation T14683(optasm) bytes allocated: 137.2 % *** unexpected stat test failure for T14683(optasm) =====> T14683(profasm) 12 of 26 [0, 2, 4] cd "./perf/compiler/T14683.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T14683 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -prof -static -fprof-auto -v0 +RTS -V0 -tT14683.comp.stats --machine-readable -RTS bytes allocated value is too high: Expected T14683(profasm) bytes allocated: 10521594688 +/-10% Lower bound T14683(profasm) bytes allocated: 9469435219 Upper bound T14683(profasm) bytes allocated: 11573754157 Actual T14683(profasm) bytes allocated: 23501401952 Deviation T14683(profasm) bytes allocated: 123.4 % *** unexpected stat test failure for T14683(profasm) =====> T9630(normal) 13 of 26 [0, 2, 4] cd "./perf/compiler/T9630.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T9630 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -v0 -O +RTS -V0 -tT9630.comp.stats --machine- readable -RTS =====> T9630(hpc) 13 of 26 [0, 2, 4] cd "./perf/compiler/T9630.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T9630 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fhpc -v0 -O +RTS -V0 -tT9630.comp.stats --machine-readable -RTS max_bytes_used value is too high: Expected T9630(hpc) max_bytes_used: 35324712 +/-15% Lower bound T9630(hpc) max_bytes_used: 30026005 Upper bound T9630(hpc) max_bytes_used: 40623419 Actual T9630(hpc) max_bytes_used: 45243520 Deviation T9630(hpc) max_bytes_used: 28.1 % *** unexpected stat test failure for T9630(hpc) =====> T9630(optasm) 13 of 26 [0, 2, 4] cd "./perf/compiler/T9630.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T9630 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -fasm -v0 -O +RTS -V0 -tT9630.comp.stats --machine-readable -RTS =====> T9630(profasm) 13 of 26 [0, 2, 4] cd "./perf/compiler/T9630.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" --make T9630 -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show- caret -dno-debug-output -O -prof -static -fprof-auto -v0 -O +RTS -V0 -tT9630.comp.stats --machine-readable -RTS max_bytes_used value is too high: Expected T9630(profasm) max_bytes_used: 35324712 +/-15% Lower bound T9630(profasm) max_bytes_used: 30026005 Upper bound T9630(profasm) max_bytes_used: 40623419 Actual T9630(profasm) max_bytes_used: 47703656 Deviation T9630(profasm) max_bytes_used: 35.0 % *** unexpected stat test failure for T9630(profasm) =====> haddock.base(normal) 14 of 26 [0, 2, 4] bytes allocated value is too high: Expected haddock.base(normal) bytes allocated: 26201242752 +/-5% Lower bound haddock.base(normal) bytes allocated: 24891180614 Upper bound haddock.base(normal) bytes allocated: 27511304890 Actual haddock.base(normal) bytes allocated: 36323781512 Deviation haddock.base(normal) bytes allocated: 38.6 % *** unexpected stat test failure for haddock.base(normal) =====> haddock.Cabal(normal) 15 of 26 [0, 2, 4] bytes allocated value is too high: Expected haddock.Cabal(normal) bytes allocated: 27520214496 +/-5% Lower bound haddock.Cabal(normal) bytes allocated: 26144203771 Upper bound haddock.Cabal(normal) bytes allocated: 28896225221 Actual haddock.Cabal(normal) bytes allocated: 39795743696 Deviation haddock.Cabal(normal) bytes allocated: 44.6 % *** unexpected stat test failure for haddock.Cabal(normal) =====> haddock.compiler(normal) 16 of 26 [0, 2, 4] bytes allocated value is too high: Expected haddock.compiler(normal) bytes allocated: 63038317672 +/-10% Lower bound haddock.compiler(normal) bytes allocated: 56734485904 Upper bound haddock.compiler(normal) bytes allocated: 69342149440 Actual haddock.compiler(normal) bytes allocated: 156651062064 Deviation haddock.compiler(normal) bytes allocated: 148.5 % *** unexpected stat test failure for haddock.compiler(normal) =====> T9203(normal) 17 of 26 [0, 2, 4] cd "./perf/should_run/T9203.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T9203 T9203.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O2 cd "./perf/should_run/T9203.run" && ./T9203 +RTS -V0 -tT9203.stats --machine-readable -RTS bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T9203(normal) bytes allocated: 98360576 +/-5% Lower bound T9203(normal) bytes allocated: 93442547 Upper bound T9203(normal) bytes allocated: 103278605 Actual T9203(normal) bytes allocated: 46371880 Deviation T9203(normal) bytes allocated: -52.9 % *** unexpected stat test failure for T9203(normal) =====> T14936(normal) 18 of 26 [0, 2, 4] cd "./perf/should_run/T14936.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T14936 T14936.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O2 cd "./perf/should_run/T14936.run" && ./T14936 +RTS -V0 -tT14936.stats --machine-readable -RTS =====> T14936(hpc) 18 of 26 [0, 2, 4] cd "./perf/should_run/T14936.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T14936 T14936.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fhpc -O2 cd "./perf/should_run/T14936.run" && ./T14936 +RTS -V0 -tT14936.stats --machine-readable -RTS bytes allocated value is too high: Expected T14936(hpc) bytes allocated: 51792 +/-5% Lower bound T14936(hpc) bytes allocated: 49202 Upper bound T14936(hpc) bytes allocated: 54382 Actual T14936(hpc) bytes allocated: 1440051256 Deviation T14936(hpc) bytes allocated: 2780351.1 % *** unexpected stat test failure for T14936(hpc) =====> T14936(optasm) 18 of 26 [0, 2, 4] cd "./perf/should_run/T14936.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T14936 T14936.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fasm -O2 cd "./perf/should_run/T14936.run" && ./T14936 +RTS -V0 -tT14936.stats --machine-readable -RTS =====> T14936(profasm) 18 of 26 [0, 2, 4] cd "./perf/should_run/T14936.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T14936 T14936.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof- auto -O2 cd "./perf/should_run/T14936.run" && ./T14936 +RTS -V0 -tT14936.stats --machine-readable -RTS +RTS -hc -p -RTS cd "./perf/should_run/T14936.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/hp2ps" T14936 bytes allocated value is too high: Expected T14936(profasm) bytes allocated: 51792 +/-5% Lower bound T14936(profasm) bytes allocated: 49202 Upper bound T14936(profasm) bytes allocated: 54382 Actual T14936(profasm) bytes allocated: 56280 Deviation T14936(profasm) bytes allocated: 8.7 % *** unexpected stat test failure for T14936(profasm) =====> T14936(ghci) 18 of 26 [0, 2, 4] cd "./perf/should_run/T14936.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" T14936.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot- ghci -fno-ghci-history -fghci-leak-check +RTS -I0.1 -RTS -O2< T14936.genscript =====> T14936(threaded1) 18 of 26 [0, 2, 4] cd "./perf/should_run/T14936.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T14936 T14936.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug -O2 cd "./perf/should_run/T14936.run" && ./T14936 +RTS -V0 -tT14936.stats --machine-readable -RTS bytes allocated value is too high: Expected T14936(threaded1) bytes allocated: 51792 +/-5% Lower bound T14936(threaded1) bytes allocated: 49202 Upper bound T14936(threaded1) bytes allocated: 54382 Actual T14936(threaded1) bytes allocated: 73432 Deviation T14936(threaded1) bytes allocated: 41.8 % *** unexpected stat test failure for T14936(threaded1) =====> T14936(threaded2) 18 of 26 [0, 2, 4] cd "./perf/should_run/T14936.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T14936 T14936.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -threaded -eventlog -O2 cd "./perf/should_run/T14936.run" && ./T14936 +RTS -V0 -tT14936.stats --machine-readable -RTS +RTS -N2 -ls -RTS bytes allocated value is too high: Expected T14936(threaded2) bytes allocated: 51792 +/-5% Lower bound T14936(threaded2) bytes allocated: 49202 Upper bound T14936(threaded2) bytes allocated: 54382 Actual T14936(threaded2) bytes allocated: 91320 Deviation T14936(threaded2) bytes allocated: 76.3 % *** unexpected stat test failure for T14936(threaded2) =====> T14936(dyn) 18 of 26 [0, 2, 4] cd "./perf/should_run/T14936.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T14936 T14936.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -dynamic -O2 cd "./perf/should_run/T14936.run" && ./T14936 +RTS -V0 -tT14936.stats --machine-readable -RTS =====> T14936(profthreaded) 18 of 26 [0, 2, 4] cd "./perf/should_run/T14936.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T14936 T14936.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof- auto -threaded -O2 cd "./perf/should_run/T14936.run" && ./T14936 +RTS -V0 -tT14936.stats --machine-readable -RTS +RTS -p -RTS bytes allocated value is too high: Expected T14936(profthreaded) bytes allocated: 51792 +/-5% Lower bound T14936(profthreaded) bytes allocated: 49202 Upper bound T14936(profthreaded) bytes allocated: 54382 Actual T14936(profthreaded) bytes allocated: 126784 Deviation T14936(profthreaded) bytes allocated: 144.8 % *** unexpected stat test failure for T14936(profthreaded) =====> space_leak_001(normal) 19 of 26 [0, 2, 4] cd "./perf/space_leaks/space_leak_001.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o space_leak_001 space_leak_001.hs -dcore-lint -dcmm-lint -no- user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning- groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug- output cd "./perf/space_leaks/space_leak_001.run" && ./space_leak_001 +RTS -V0 -tspace_leak_001.stats --machine-readable -RTS =====> space_leak_001(hpc) 19 of 26 [0, 2, 4] cd "./perf/space_leaks/space_leak_001.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o space_leak_001 space_leak_001.hs -dcore-lint -dcmm-lint -no- user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning- groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug- output -O -fhpc cd "./perf/space_leaks/space_leak_001.run" && ./space_leak_001 +RTS -V0 -tspace_leak_001.stats --machine-readable -RTS max_bytes_used value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected space_leak_001(hpc) max_bytes_used: 440000 +/-15% Lower bound space_leak_001(hpc) max_bytes_used: 374000 Upper bound space_leak_001(hpc) max_bytes_used: 506000 Actual space_leak_001(hpc) max_bytes_used: 291048 Deviation space_leak_001(hpc) max_bytes_used: -33.9 % *** unexpected stat test failure for space_leak_001(hpc) =====> space_leak_001(optasm) 19 of 26 [0, 2, 4] cd "./perf/space_leaks/space_leak_001.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o space_leak_001 space_leak_001.hs -dcore-lint -dcmm-lint -no- user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning- groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug- output -O -fasm cd "./perf/space_leaks/space_leak_001.run" && ./space_leak_001 +RTS -V0 -tspace_leak_001.stats --machine-readable -RTS max_bytes_used value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected space_leak_001(optasm) max_bytes_used: 440000 +/-15% Lower bound space_leak_001(optasm) max_bytes_used: 374000 Upper bound space_leak_001(optasm) max_bytes_used: 506000 Actual space_leak_001(optasm) max_bytes_used: 291048 Deviation space_leak_001(optasm) max_bytes_used: -33.9 % *** unexpected stat test failure for space_leak_001(optasm) =====> space_leak_001(ghci) 19 of 26 [0, 2, 4] cd "./perf/space_leaks/space_leak_001.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" space_leak_001.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history -fghci-leak-check +RTS -I0.1 -RTS < space_leak_001.genscript =====> space_leak_001(dyn) 19 of 26 [0, 2, 4] cd "./perf/space_leaks/space_leak_001.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o space_leak_001 space_leak_001.hs -dcore-lint -dcmm-lint -no- user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning- groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug- output -O -dynamic cd "./perf/space_leaks/space_leak_001.run" && ./space_leak_001 +RTS -V0 -tspace_leak_001.stats --machine-readable -RTS max_bytes_used value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected space_leak_001(dyn) max_bytes_used: 440000 +/-15% Lower bound space_leak_001(dyn) max_bytes_used: 374000 Upper bound space_leak_001(dyn) max_bytes_used: 506000 Actual space_leak_001(dyn) max_bytes_used: 291048 Deviation space_leak_001(dyn) max_bytes_used: -33.9 % *** unexpected stat test failure for space_leak_001(dyn) =====> T4334(normal) 20 of 26 [0, 2, 4] cd "./perf/space_leaks/T4334.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T4334 T4334.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output cd "./perf/space_leaks/T4334.run" && ./T4334 +RTS -V0 -tT4334.stats --machine-readable -RTS 1000000 2 t =====> T4334(hpc) 20 of 26 [0, 2, 4] cd "./perf/space_leaks/T4334.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T4334 T4334.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fhpc cd "./perf/space_leaks/T4334.run" && ./T4334 +RTS -V0 -tT4334.stats --machine-readable -RTS 1000000 2 t =====> T4334(optasm) 20 of 26 [0, 2, 4] cd "./perf/space_leaks/T4334.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T4334 T4334.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fasm cd "./perf/space_leaks/T4334.run" && ./T4334 +RTS -V0 -tT4334.stats --machine-readable -RTS 1000000 2 t =====> T4334(ghci) 20 of 26 [0, 2, 4] cd "./perf/space_leaks/T4334.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" T4334.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot- ghci -fno-ghci-history -fghci-leak-check +RTS -I0.1 -RTS < T4334.genscript =====> T4334(threaded1) 20 of 26 [0, 2, 4] cd "./perf/space_leaks/T4334.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T4334 T4334.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug cd "./perf/space_leaks/T4334.run" && ./T4334 +RTS -V0 -tT4334.stats --machine-readable -RTS 1000000 2 t =====> T4334(threaded2) 20 of 26 [0, 2, 4] cd "./perf/space_leaks/T4334.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T4334 T4334.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -threaded -eventlog cd "./perf/space_leaks/T4334.run" && ./T4334 +RTS -V0 -tT4334.stats --machine-readable -RTS +RTS -N2 -ls -RTS 1000000 2 t peak_megabytes_allocated value is too high: Expected T4334(threaded2) peak_megabytes_allocated: 2 +/-1% Lower bound T4334(threaded2) peak_megabytes_allocated: 1 Upper bound T4334(threaded2) peak_megabytes_allocated: 3 Actual T4334(threaded2) peak_megabytes_allocated: 4 Deviation T4334(threaded2) peak_megabytes_allocated: 100.0 % *** unexpected stat test failure for T4334(threaded2) =====> T4334(dyn) 20 of 26 [0, 2, 4] cd "./perf/space_leaks/T4334.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -o T4334 T4334.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -dynamic cd "./perf/space_leaks/T4334.run" && ./T4334 +RTS -V0 -tT4334.stats --machine-readable -RTS 1000000 2 t =====> T6132(normal) 21 of 26 [0, 2, 4] cd "./runghc/T6132.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T6132.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output *** unexpected pass for T6132(normal) =====> T6132(hpc) 21 of 26 [1, 2, 4] cd "./runghc/T6132.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T6132.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fhpc *** unexpected pass for T6132(hpc) =====> T6132(optasm) 21 of 26 [2, 2, 4] cd "./runghc/T6132.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T6132.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fasm *** unexpected pass for T6132(optasm) =====> T6132(profasm) 21 of 26 [3, 2, 4] cd "./runghc/T6132.run" && "/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T6132.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof- auto *** unexpected pass for T6132(profasm) =====> T7702(normal) 22 of 26 [4, 2, 4] cd "./simplCore/should_compile/T7702.run" && $MAKE -s --no-print-directory -C T7702plugin package.T7702 TOP=/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/testsuite cd "./simplCore/should_compile/T7702.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T7702.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -v0 -package-db T7702plugin/pkg.T7702/local.package.conf -fplugin T7702Plugin -package T7702plugin -dynamic +RTS -V0 -tT7702.comp.stats --machine-readable -RTS =====> T7702(hpc) 22 of 26 [4, 2, 4] cd "./simplCore/should_compile/T7702.run" && $MAKE -s --no-print-directory -C T7702plugin package.T7702 TOP=/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/testsuite cd "./simplCore/should_compile/T7702.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T7702.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fhpc -v0 -package-db T7702plugin/pkg.T7702/local.package.conf -fplugin T7702Plugin -package T7702plugin -dynamic +RTS -V0 -tT7702.comp.stats --machine-readable -RTS =====> T7702(optasm) 22 of 26 [4, 2, 4] cd "./simplCore/should_compile/T7702.run" && $MAKE -s --no-print-directory -C T7702plugin package.T7702 TOP=/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/testsuite cd "./simplCore/should_compile/T7702.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T7702.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fasm -v0 -package-db T7702plugin/pkg.T7702/local.package.conf -fplugin T7702Plugin -package T7702plugin -dynamic +RTS -V0 -tT7702.comp.stats --machine-readable -RTS =====> T7702(profasm) 22 of 26 [4, 2, 4] cd "./simplCore/should_compile/T7702.run" && $MAKE -s --no-print-directory -C T7702plugin package.T7702 TOP=/Users/carter/dev-checkouts/ghc- tree/ghc-8.6.2-checkout-build/testsuite cd "./simplCore/should_compile/T7702.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" -c T7702.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof- auto -v0 -package-db T7702plugin/pkg.T7702/local.package.conf -fplugin T7702Plugin -package T7702plugin -dynamic +RTS -V0 -tT7702.comp.stats --machine-readable -RTS Compile failed (exit code 1) errors were: : Could not find module ‘T7702Plugin’ Perhaps you haven't installed the "p_dyn" libraries for package ‘T7702plugin-0.1’? Use -v to see a list of the files searched for. *** unexpected failure for T7702(profasm) =====> EtaExpandLevPoly(normal) 23 of 26 [4, 3, 4] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o EtaExpandLevPoly EtaExpandLevPoly.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly =====> EtaExpandLevPoly(hpc) 23 of 26 [4, 3, 4] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o EtaExpandLevPoly EtaExpandLevPoly.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output -O -fhpc cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly =====> EtaExpandLevPoly(optasm) 23 of 26 [4, 3, 4] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o EtaExpandLevPoly EtaExpandLevPoly.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output -O -fasm cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly =====> EtaExpandLevPoly(profasm) 23 of 26 [4, 3, 4] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o EtaExpandLevPoly EtaExpandLevPoly.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output -O -prof -static -fprof-auto cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly +RTS -hc -p -RTS cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/hp2ps" EtaExpandLevPoly *** unexpected pass for EtaExpandLevPoly(profasm) =====> EtaExpandLevPoly(threaded1) 23 of 26 [5, 3, 4] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o EtaExpandLevPoly EtaExpandLevPoly.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output -threaded -debug cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly =====> EtaExpandLevPoly(threaded2) 23 of 26 [5, 3, 4] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o EtaExpandLevPoly EtaExpandLevPoly.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output -O -threaded -eventlog cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly +RTS -N2 -ls -RTS =====> EtaExpandLevPoly(dyn) 23 of 26 [5, 3, 4] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o EtaExpandLevPoly EtaExpandLevPoly.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output -O -dynamic cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly =====> EtaExpandLevPoly(profthreaded) 23 of 26 [5, 3, 4] cd "./typecheck/should_run/EtaExpandLevPoly.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o EtaExpandLevPoly EtaExpandLevPoly.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow- warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno- debug-output -O -prof -static -fprof-auto -threaded cd "./typecheck/should_run/EtaExpandLevPoly.run" && ./EtaExpandLevPoly +RTS -p -RTS *** unexpected pass for EtaExpandLevPoly(profthreaded) =====> T15349(normal) 24 of 26 [6, 3, 4] cd "../../libraries/base/tests/T15349.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o T15349 T15349.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output cd "../../libraries/base/tests/T15349.run" && ./T15349 =====> T15349(hpc) 24 of 26 [6, 3, 4] cd "../../libraries/base/tests/T15349.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o T15349 T15349.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fhpc cd "../../libraries/base/tests/T15349.run" && ./T15349 =====> T15349(optasm) 24 of 26 [6, 3, 4] cd "../../libraries/base/tests/T15349.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o T15349 T15349.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fasm cd "../../libraries/base/tests/T15349.run" && ./T15349 =====> T15349(profasm) 24 of 26 [6, 3, 4] cd "../../libraries/base/tests/T15349.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o T15349 T15349.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto cd "../../libraries/base/tests/T15349.run" && ./T15349 +RTS -hc -p -RTS cd "../../libraries/base/tests/T15349.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/hp2ps" T15349 =====> T15349(ghci) 24 of 26 [6, 3, 4] cd "../../libraries/base/tests/T15349.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" T15349.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore- dot-ghci -fno-ghci-history -fghci-leak-check +RTS -I0.1 -RTS < T15349.genscript Timeout happened...killed process "cd "../../libraries/base/tests/T15349.run" && "/Users/carter/dev-checkouts /ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc-stage2" T15349.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn- missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore- dot-ghci -fno-ghci-history -fghci-leak-check +RTS -I0.1 -RTS "... Wrong exit code for T15349(ghci) (expected 1 , actual 99 ) *** unexpected failure for T15349(ghci) =====> T15349(threaded1) 24 of 26 [6, 4, 4] cd "../../libraries/base/tests/T15349.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o T15349 T15349.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug cd "../../libraries/base/tests/T15349.run" && ./T15349 =====> T15349(threaded2) 24 of 26 [6, 4, 4] cd "../../libraries/base/tests/T15349.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o T15349 T15349.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -threaded -eventlog cd "../../libraries/base/tests/T15349.run" && ./T15349 +RTS -N2 -ls -RTS =====> T15349(dyn) 24 of 26 [6, 4, 4] cd "../../libraries/base/tests/T15349.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o T15349 T15349.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -dynamic cd "../../libraries/base/tests/T15349.run" && ./T15349 =====> T15349(profthreaded) 24 of 26 [6, 4, 4] cd "../../libraries/base/tests/T15349.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o T15349 T15349.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -threaded cd "../../libraries/base/tests/T15349.run" && ./T15349 +RTS -p -RTS =====> hpc_fork(normal) 25 of 26 [6, 4, 4] cd "../../libraries/hpc/tests/fork/hpc_fork.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o hpc_fork hpc_fork.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -fhpc cd "../../libraries/hpc/tests/fork/hpc_fork.run" && perl hpcrun.pl --clear --exeext= --hpc="/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/inplace/test spaces/hpc" ./hpc_fork =====> hpc_fork(hpc) 25 of 26 [6, 4, 4] cd "../../libraries/hpc/tests/fork/hpc_fork.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o hpc_fork hpc_fork.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fhpc -fhpc cd "../../libraries/hpc/tests/fork/hpc_fork.run" && perl hpcrun.pl --clear --exeext= --hpc="/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/inplace/test spaces/hpc" ./hpc_fork =====> hpc_fork(optasm) 25 of 26 [6, 4, 4] cd "../../libraries/hpc/tests/fork/hpc_fork.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o hpc_fork hpc_fork.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fasm -fhpc cd "../../libraries/hpc/tests/fork/hpc_fork.run" && perl hpcrun.pl --clear --exeext= --hpc="/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/inplace/test spaces/hpc" ./hpc_fork =====> hpc_fork(profasm) 25 of 26 [6, 4, 4] cd "../../libraries/hpc/tests/fork/hpc_fork.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o hpc_fork hpc_fork.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -fhpc cd "../../libraries/hpc/tests/fork/hpc_fork.run" && perl hpcrun.pl --clear --exeext= --hpc="/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/inplace/test spaces/hpc" ./hpc_fork +RTS -hc -p -RTS cd "../../libraries/hpc/tests/fork/hpc_fork.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/hp2ps" hpc_fork hp2ps error when processing heap profile for hpc_fork *** unexpected failure for hpc_fork(profasm) =====> hpc_fork(threaded1) 25 of 26 [6, 5, 4] cd "../../libraries/hpc/tests/fork/hpc_fork.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o hpc_fork hpc_fork.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug -fhpc cd "../../libraries/hpc/tests/fork/hpc_fork.run" && perl hpcrun.pl --clear --exeext= --hpc="/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/inplace/test spaces/hpc" ./hpc_fork =====> hpc_fork(dyn) 25 of 26 [6, 5, 4] cd "../../libraries/hpc/tests/fork/hpc_fork.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o hpc_fork hpc_fork.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -dynamic -fhpc cd "../../libraries/hpc/tests/fork/hpc_fork.run" && perl hpcrun.pl --clear --exeext= --hpc="/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/inplace/test spaces/hpc" ./hpc_fork =====> hpc_fork(profthreaded) 25 of 26 [6, 5, 4] cd "../../libraries/hpc/tests/fork/hpc_fork.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o hpc_fork hpc_fork.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -threaded -fhpc cd "../../libraries/hpc/tests/fork/hpc_fork.run" && perl hpcrun.pl --clear --exeext= --hpc="/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2-checkout- build/inplace/test spaces/hpc" ./hpc_fork +RTS -p -RTS =====> signals004(normal) 26 of 26 [6, 5, 4] cd "../../libraries/unix/tests/signals004.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o signals004 signals004.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -package unix cd "../../libraries/unix/tests/signals004.run" && ./signals004 =====> signals004(hpc) 26 of 26 [6, 5, 4] cd "../../libraries/unix/tests/signals004.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o signals004 signals004.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fhpc -package unix cd "../../libraries/unix/tests/signals004.run" && ./signals004 =====> signals004(optasm) 26 of 26 [6, 5, 4] cd "../../libraries/unix/tests/signals004.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o signals004 signals004.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -fasm -package unix cd "../../libraries/unix/tests/signals004.run" && ./signals004 =====> signals004(profasm) 26 of 26 [6, 5, 4] cd "../../libraries/unix/tests/signals004.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o signals004 signals004.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -package unix cd "../../libraries/unix/tests/signals004.run" && ./signals004 +RTS -hc -p -RTS cd "../../libraries/unix/tests/signals004.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/hp2ps" signals004 =====> signals004(ghci) 26 of 26 [6, 5, 4] cd "../../libraries/unix/tests/signals004.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" signals004.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history -fghci-leak-check +RTS -I0.1 -RTS -package unix< signals004.genscript =====> signals004(threaded1) 26 of 26 [6, 5, 4] cd "../../libraries/unix/tests/signals004.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o signals004 signals004.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug -package unix cd "../../libraries/unix/tests/signals004.run" && ./signals004 =====> signals004(threaded2) 26 of 26 [6, 5, 4] cd "../../libraries/unix/tests/signals004.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o signals004 signals004.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -threaded -eventlog -package unix cd "../../libraries/unix/tests/signals004.run" && ./signals004 +RTS -N2 -ls -RTS Timeout happened...killed process "cd "../../libraries/unix/tests/signals004.run" && ./signals004 +RTS -N2 -ls -RTS "... Wrong exit code for signals004(threaded2)(expected 0 , actual 99 ) *** unexpected failure for signals004(threaded2) =====> signals004(dyn) 26 of 26 [6, 6, 4] cd "../../libraries/unix/tests/signals004.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o signals004 signals004.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -dynamic -package unix cd "../../libraries/unix/tests/signals004.run" && ./signals004 =====> signals004(profthreaded) 26 of 26 [6, 6, 4] cd "../../libraries/unix/tests/signals004.run" && "/Users/carter/dev- checkouts/ghc-tree/ghc-8.6.2-checkout-build/inplace/test spaces/ghc- stage2" -o signals004 signals004.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -threaded -package unix cd "../../libraries/unix/tests/signals004.run" && ./signals004 +RTS -p -RTS Unexpected results from: TEST="EtaExpandLevPoly ManyAlternatives ManyConstructors MultiLayerModules T10370 T11535 T12707 T13379 T13701 T13719 T14683 T14697 T14936 T15349 T4334 T6132 T7702 T9203 T9630 ghci063 haddock.Cabal haddock.base haddock.compiler hpc_fork signals004 space_leak_001" SUMMARY for test run started at Fri Nov 30 11:28:02 2018 EST 0:56:11 spent to go through 26 total tests, which gave rise to 137 test cases, of which 20 were skipped 0 had missing libraries 64 expected passes 0 expected failures 4 caused framework failures 0 caused framework warnings 6 unexpected passes 6 unexpected failures 37 unexpected stat failures Unexpected passes: runghc/T6132.run T6132 [unexpected] (normal) runghc/T6132.run T6132 [unexpected] (hpc) runghc/T6132.run T6132 [unexpected] (optasm) runghc/T6132.run T6132 [unexpected] (profasm) typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profasm) typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profthreaded) Unexpected failures: deriving/should_run/T11535.run T11535 [bad exit code] (ghci) ghci/scripts/ghci063.run ghci063 [bad stderr] (ghci) simplCore/should_compile/T7702.run T7702 [exit code non-0] (profasm) ../../libraries/base/tests/T15349.run T15349 [bad exit code] (ghci) ../../libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) ../../libraries/unix/tests/signals004.run signals004 [bad exit code] (threaded2) Unexpected stat failures: perf/compiler/T10370.run T10370 [stat not good enough] (optasm) perf/compiler/T12707.run T12707 [stat not good enough] (hpc) perf/compiler/T12707.run T12707 [stat not good enough] (optasm) perf/compiler/T12707.run T12707 [stat not good enough] (profasm) perf/compiler/T13379.run T13379 [stat not good enough] (hpc) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (optasm) perf/compiler/ManyConstructors.run ManyConstructors [stat not good enough] (hpc) perf/compiler/ManyConstructors.run ManyConstructors [stat not good enough] (optasm) perf/compiler/ManyConstructors.run ManyConstructors [stat not good enough] (profasm) perf/compiler/ManyAlternatives.run ManyAlternatives [stat not good enough] (hpc) perf/compiler/ManyAlternatives.run ManyAlternatives [stat not good enough] (optasm) perf/compiler/ManyAlternatives.run ManyAlternatives [stat not good enough] (profasm) perf/compiler/T13701.run T13701 [stat not good enough] (optasm) perf/compiler/T13719.run T13719 [stat not good enough] (hpc) perf/compiler/T13719.run T13719 [stat not good enough] (optasm) perf/compiler/T13719.run T13719 [stat not good enough] (profasm) perf/compiler/T14697.run T14697 [stat not good enough] (hpc) perf/compiler/T14697.run T14697 [stat not good enough] (optasm) perf/compiler/T14697.run T14697 [stat not good enough] (profasm) perf/compiler/T14683.run T14683 [stat not good enough] (hpc) perf/compiler/T14683.run T14683 [stat not good enough] (optasm) perf/compiler/T14683.run T14683 [stat not good enough] (profasm) perf/compiler/T9630.run T9630 [stat not good enough] (hpc) perf/compiler/T9630.run T9630 [stat not good enough] (profasm) perf/haddock/haddock.base.run haddock.base [stat not good enough] (normal) perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) perf/should_run/T9203.run T9203 [stat too good] (normal) perf/should_run/T14936.run T14936 [stat not good enough] (hpc) perf/should_run/T14936.run T14936 [stat not good enough] (profasm) perf/should_run/T14936.run T14936 [stat not good enough] (threaded1) perf/should_run/T14936.run T14936 [stat not good enough] (threaded2) perf/should_run/T14936.run T14936 [stat not good enough] (profthreaded) perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (hpc) perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optasm) perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (dyn) perf/space_leaks/T4334.run T4334 [stat not good enough] (threaded2) Framework failures: perf/compiler/MultiLayerModules.run MultiLayerModules [hpc] ('NoneType' object has no attribute 'group') perf/compiler/MultiLayerModules.run MultiLayerModules [profasm] ('NoneType' object has no attribute 'group') perf/compiler/T13701.run T13701 [hpc] ('NoneType' object has no attribute 'group') perf/compiler/T13701.run T13701 [profasm] ('NoneType' object has no attribute 'group') ../mk/test.mk:329: recipe for target 'test' failed make[2]: *** [test] Error 1 make[2]: Leaving directory '/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2 -checkout-build/testsuite/tests' ../mk/test.mk:348: recipe for target 'slow' failed make[1]: *** [slow] Error 2 make[1]: Leaving directory '/Users/carter/dev-checkouts/ghc-tree/ghc-8.6.2 -checkout-build/testsuite/tests' Makefile:35: recipe for target 'slow' failed make: *** [slow] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler