From ghc-devs at haskell.org Fri Dec 1 05:43:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 05:43:07 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns Message-ID: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: incomplete- | Operating System: Linux patterns OverloadedLists | TypeFamilies | Type of failure: Incorrect Architecture: x86 | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Wrong warning occur where I use -Wincomplete-patterns with OverloadedLists and TypeFamilies. {{{#!hs {-# LANGUAGE OverloadedLists #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wall -fno-warn-tabs #-} class Foo f where type It f foo :: [It f] -> f data List a = Empty | a :! List a deriving Show instance Foo (List a) where type It (List a) = a foo [] = Empty foo (x : xs) = x :! foo xs }}} Pattern match(es) are non-exhaustive In an equation for `foo': Patterns not matched: [] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 06:10:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 06:10:35 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.7447241e0aa8cef25d3ae4bbd7f87018@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): Thanks. That makes sense, if I think about it. In my example it just happens to be a closed set, this will not always be true. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 08:55:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 08:55:46 -0000 Subject: [GHC] #14531: tcIfaceGlobal (local): not found In-Reply-To: <044.574a009d0a229a581813260133be5712@haskell.org> References: <044.574a009d0a229a581813260133be5712@haskell.org> Message-ID: <059.a3f56eef92d191502bf601af52d7005c@haskell.org> #14531: tcIfaceGlobal (local): not found -------------------------------------+------------------------------------- Reporter: bigos | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14382 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => hs-boot -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 09:02:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 09:02:09 -0000 Subject: [GHC] #14547: Wrong warning by -Wincomplete-patterns In-Reply-To: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> References: <052.21a9ad8704f084ec9db31f385a693f01@haskell.org> Message-ID: <067.5ab5994b15815b0a5e47abd1a6b5b8ea@haskell.org> #14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: incomplete- | patterns OverloadedLists, | PatternMatchWarnings TypeFamilies Operating System: Linux | Architecture: x86 Type of failure: Incorrect | Test Case: error/warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: incomplete-patterns OverloadedLists TypeFamilies => incomplete-patterns OverloadedLists, PatternMatchWarnings TypeFamilies -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 09:06:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 09:06:20 -0000 Subject: [GHC] #14539: untouchable type inside the constraints In-Reply-To: <046.e791a4fd7c5c8d50126f67c9980c3ee6@haskell.org> References: <046.e791a4fd7c5c8d50126f67c9980c3ee6@haskell.org> Message-ID: <061.08cb6bb71e3da19deea14b31d00208ba@haskell.org> #14539: untouchable type inside the constraints -------------------------------------+------------------------------------- Reporter: Lemming | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * status: new => closed * resolution: => wontfix Comment: If this is intended behavior, I'll close the ticket. It's confusing, though. It was code that worked before. But I cannot attribute it to GHC alone, since there were changes in the imported libraries, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 09:58:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 09:58:47 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.b0d1ff1b0ea1264360acc0508429d47d@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by simonpj): I'm ok with Plan B. But can you explain what you mean by this? > Plan F is complex, and requires special case treatment of traversals into extension points that are actually used. What is the special case treatment and why do we need it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 11:41:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 11:41:19 -0000 Subject: [GHC] #14548: Lexically scoped kind variables Message-ID: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> #14548: Lexically scoped kind variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this, with `ScopedTypeVariables`: {{{ f :: forall a. Char -> Proxy (a::k) -> Int f = }}} Clearly `a` scopes over ``. But did you know that `k` does too? I think we'd ''expect'' `k` to scope if we wrote {{{ f :: forall (a :: K). Char -> Proxy (a::k) -> Int }}} with `k` appearing in the kind of an explicitly-forall'd binder. For long time we could not have an explicit forall for a kind variable (although we can now), so this was the ''only'' way to bring `k` into scope. But it seems altogether less desirable that an occurrence of `k` buried deep in the type should scope over `f`'s body. That's why we don't make implicitly-bound type variables scope over the body: {{{ f :: Char -> Proxy (a::k) -> Int }}} Here `a` does ''not'' scope over ``. I doubt anyone would notice if we changed this behaviour, like this. * A type variable from the signature scopes over the body if * It is explicitly forall'd, or * It appears in a kind annotation of an explicitly-forall'd type variable My reason for raising this is that it's solve #14498, (by making `kk` not scope) in a uniform way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 11:41:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 11:41:37 -0000 Subject: [GHC] #14548: Lexically scoped kind variables In-Reply-To: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> References: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> Message-ID: <061.c13f72281304546bd3d98940363e39ad@haskell.org> #14548: Lexically scoped kind variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider this, with `ScopedTypeVariables`: > {{{ > f :: forall a. Char -> Proxy (a::k) -> Int > f = > }}} > Clearly `a` scopes over ``. But did you know that `k` does too? > > I think we'd ''expect'' `k` to scope if we wrote > {{{ > f :: forall (a :: K). Char -> Proxy (a::k) -> Int > }}} > with `k` appearing in the kind of an explicitly-forall'd binder. For > long time we could not have an explicit forall for a kind variable > (although we can now), so this was the ''only'' way to bring `k` into > scope. > > But it seems altogether less desirable that an occurrence of `k` buried > deep in the type should scope over `f`'s body. That's why we don't make > implicitly-bound type variables scope over the body: > {{{ > f :: Char -> Proxy (a::k) -> Int > }}} > Here `a` does ''not'' scope over ``. > > I doubt anyone would notice if we changed this behaviour, like this. > > * A type variable from the signature scopes over the body if > * It is explicitly forall'd, or > * It appears in a kind annotation of an explicitly-forall'd type > variable > > My reason for raising this is that it's solve #14498, (by making `kk` not > scope) in > a uniform way. New description: Consider this, with `ScopedTypeVariables`: {{{ f :: forall a. Char -> Proxy (a::k) -> Int f = }}} Clearly `a` scopes over ``. But did you know that `k` does too? I think we'd ''expect'' `k` to scope if we wrote {{{ f :: forall (a :: K). Char -> Proxy (a::k) -> Int }}} with `k` appearing in the kind of an explicitly-forall'd binder. For long time we could not have an explicit forall for a kind variable (although we can now), so this was the ''only'' way to bring `k` into scope. But it seems altogether less desirable that an occurrence of `k` buried deep in the type should scope over `f`'s body. That's why we don't make implicitly-bound type variables scope over the body: {{{ f :: Char -> Proxy (a::k) -> Int }}} Here `a` does ''not'' scope over ``. I doubt anyone would notice if we changed this behaviour, like this. * A type variable from the signature scopes over the body if * It is explicitly forall'd, or * It appears in a kind annotation of an explicitly-forall'd type variable My reason for raising this is that it's solve #14498 (by making `kk` not scope) in a uniform way. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 11:46:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 11:46:13 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.edfc380ce980d8c2a1cf70de8d548cb3@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See #144548. And I am increasingly dubious about comment:1 and comment:2, which suggest that `kk` should be in scope in the pattern. I can't make sense of that. (The builder is different, as discussed in comment:6 of #14288.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 11:48:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 11:48:42 -0000 Subject: [GHC] #14490: TTG Snags In-Reply-To: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> References: <044.f4edb979bc1a87286428a7690bab92e2@haskell.org> Message-ID: <059.f8ba0ffaf9f9248b8fd171be8f71f1c1@haskell.org> #14490: TTG Snags -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14482 | Differential Rev(s): Wiki Page: | ImplementingTreesThatGrow | -------------------------------------+------------------------------------- Comment (by alanz): > What is the special case treatment and why do we need it? My understanding is that we would still need to implement something like Plan D, which requires the `IsGhcPass` class. It could well be that Plan F *is* a good option, but I just do not understand the mechanics of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 11:50:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 11:50:02 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.896edc45675f8573f0612a9788112e17@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:10 simonpj]: > And I am increasingly dubious about comment:1 and comment:2, which suggest that `kk` should be in scope in the pattern. I can't make sense of that. I'm not sure how you came to that conclusion. I'm suggesting the opposite—`kk` (from the type signature) should //not// be brought into scope over the body of `SS`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 11:53:51 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 11:53:51 -0000 Subject: [GHC] #14548: Lexically scoped kind variables In-Reply-To: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> References: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> Message-ID: <061.f336ef7b954afc03d9d5d8ddf07dac31@haskell.org> #14548: Lexically scoped kind variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14288, #14498 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14288, #14498 Comment: Sounds good to me. I tried implementing this at one point, but alas, the structure of `HsImplicitBndrs` does not make it easy to distinguish between a `k` appearing in `forall a. Char -> Proxy (a::k) -> Int` and a `k` appearing in `forall (a :: k). Char -> Proxy (a::k) -> Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 12:00:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 12:00:23 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.17b937f66d29f21820f1b27b49592b38@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I'm suggesting the opposite—kk (from the type signature) should not be brought into scope over the body of SS! Fine. I think so too. But comment:2 says "Yes, kk should definitely scope over the pattern synonym body." I think we are saying "no" to that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 12:01:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 12:01:22 -0000 Subject: [GHC] #14548: Lexically scoped kind variables In-Reply-To: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> References: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> Message-ID: <061.c549609dd938c7bdfde1e531b76bcf0d@haskell.org> #14548: Lexically scoped kind variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14288, #14498 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I know. But before implementing anything we should agree the design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 12:26:47 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 12:26:47 -0000 Subject: [GHC] #14548: Lexically scoped kind variables In-Reply-To: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> References: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> Message-ID: <061.49cba8ca758e5bc59eba42f2bf200348@haskell.org> #14548: Lexically scoped kind variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14288, #14498 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not sure what "design" you're talking about. I agree to the proposal in the ticket. Done. What else are we blocked on? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 12:29:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 12:29:27 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.34330b29bfca8d61830183fd8ed30a78@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Apoligies, I can see why you'd be misled by comment:2. What I meant in comment:2 is "under the design proposed in #14288, `kk` would be brought into scope". But I later realized there was a simpler way forward that didn't require implementing all of #14288, so you can ignore anything I said before that :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 12:30:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 12:30:01 -0000 Subject: [GHC] #14548: Lexically scoped kind variables In-Reply-To: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> References: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> Message-ID: <061.195c1d541da60bbee2215c86bb2ad7cd@haskell.org> #14548: Lexically scoped kind variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14288, #14498 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, that's the design. Before implementing it, though, we need to check that others are happy. Perhaps it's too much of a corner case to bother with a GHC proposal? What do others think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 13:00:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 13:00:17 -0000 Subject: [GHC] #14549: RecordWildCards doesn't work properly in repl Message-ID: <046.4673855b1aa87324cadebb3b1903efa3@haskell.org> #14549: RecordWildCards doesn't work properly in repl -------------------------------------+------------------------------------- Reporter: akegalj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.2.1 Keywords: repl, | Operating System: Unknown/Multiple recordwildcards | Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs Prelude> :set -XRecordWildCards Prelude> data Test = Test { t1 :: Int, t2 :: Int } deriving Show Prelude> t1 = 2 Prelude> Test { t2 = 2, ..} :15:1: warning: [-Wmissing-fields] • Fields of 'Test' not initialised: t1 • In the expression: Test {t2 = 2, ..} In an equation for 'it': it = Test {t2 = 2, ..} :15:1: warning: [-Wmissing-fields] • Fields of 'Test' not initialised: t1 • In the expression: Test {t2 = 2, ..} In an equation for 'it': it = Test {t2 = 2, ..} Test {t1 = *** Exception: :15:1-18: Missing field in record construction t1 }}} I would expect above to return `Test {t1 = 2, t2 = 2}` instead of throwing an error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 13:19:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 13:19:01 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.47cf1b1f1fa657ca63184b893af4af8f@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by simonpj): > Now, when forcing `outer` we push an update frame which overwrites `outer`s closure to be an indirection to the resulting value hereby turning the free variables effectively into garbage. Ah! That's an excellent point, one that I had totally neglected. Possibilities: * Step 1. Don't do this for thunks. We have no data about what the troublesome cases are, but the one case we do know about has functions. * Step 2. Still don't do the this for thunks, but {{{ let k1 = [fv1, ..., fvn] \ [] let k2 = [fv1, ..., fvn] \ [] -> ... in ... in ... ===> let t = (fv1, ..., fvn) in let k1 = [t{fv1, ..., fvn}] \ [] -> let k2 = [t{fv1, ..., fvn}]] \ [] -> ... in ... in ... }}} NB: here I am allowing the `t{fv1,..,fvn}` as a way to access the free vars of a data constructor, as well as a function closure. I don't think this should be hard to arrange. And it might be useful anyway. Now the shared bit is a separate tuple, which won't get updated. One thing that would help would be some '''data''' on how common this kind of thing is. Even deciding what to measure is non-obvious. For example: * For each STG let-binding {{{ let x = [fv1..fvn] \ argsx -> ex }}} How often is it the case that there is an enclosing binding {{{ let y = [gv1,...gvm] \ argsy -> ey }}} where the `[gv1,..gvm]` is a subset of `[fv1,..fvn]`? And what is the distribution of savings? By "enclosing" here, in the RHS of a let, I include the let-binding itself, ''even if it is non-recursive''. All the examples above have this form. Some data along these lines would be extremely helpful in guiding what we do. Another variant: currently we insist that `[gv1,..gvm]` is a '''subset''' of `[fv1,..fvn]`, to avoid space leaks. But with some RTS support we could do better: the closure for `x` could point to the closure for `y`, but ''also'' have a bitmap (in `x`'s info table) to say which of `y`'s free vars are actually used by `x`. That would open up the possibility for much more flexible sharing, at the cost of more bitmaps etc. E.g. {{{ x = [fv1,...fv100] \ [a] -> let y = [fv1,...fv99, a] \ [] -> ... in ... }}} Here `y` needs all but one of `x`'s free vars. Data on how often this happens would be would be jolly useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 13:38:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 13:38:25 -0000 Subject: [GHC] #14396: Hs-boot woes during family instance consistency checks In-Reply-To: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> References: <046.2ccc4fa31be03dddd3503a257243a5e2@haskell.org> Message-ID: <061.4403bdc1120b5b200f85d805c8bd5de2@haskell.org> #14396: Hs-boot woes during family instance consistency checks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4154 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"6998772043a7f0b0360116eb5ffcbaa5630b21fb/ghc" 69987720/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6998772043a7f0b0360116eb5ffcbaa5630b21fb" Make use of boot TyThings during typechecking. Summary: Suppose that you are typechecking A.hs, which transitively imports, via B.hs, A.hs-boot. When we poke on B.hs and discover that it has a reference to a type from A, what TyThing should we wire it up with? Clearly, if we have already typechecked A, we should use the most up-to-date TyThing: the one we freshly generated when we typechecked A. But what if we haven't typechecked it yet? For the longest time, GHC adopted the policy that this was *an error condition*; that you MUST NEVER poke on B.hs's reference to a thing defined in A.hs until A.hs has gotten around to checking this. However, actually ensuring this is the case has proven to be a bug farm. The problem was especially poignant with type family consistency checks, which eagerly happen before any typechecking takes place. This patch takes a different strategy: if we ever try to access an entity from A which doesn't exist, we just fall back on the definition of A from the hs-boot file. This means that you may end up with a mix of A.hs and A.hs-boot TyThings during the course of typechecking. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, bgamari, austin, goldfire Subscribers: thomie, rwbarton GHC Trac Issues: #14396 Differential Revision: https://phabricator.haskell.org/D4154 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 13:38:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 13:38:25 -0000 Subject: [GHC] #14525: Backpack doesn't work with CPP In-Reply-To: <045.32abb777bece6efc430ddbb385cddc79@haskell.org> References: <045.32abb777bece6efc430ddbb385cddc79@haskell.org> Message-ID: <060.57c80b6f591e6232752779d2ec23c326@haskell.org> #14525: Backpack doesn't work with CPP -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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:D4234 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"e1fb28384c44fcd29b0e60b9fd44767be22646af/ghc" e1fb283/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e1fb28384c44fcd29b0e60b9fd44767be22646af" Handle CPP properly in Backpack Summary: Previously, we attempted to lookup 'hole' packages for include directories; this obviously is not going to work. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: ekmett, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14525 Differential Revision: https://phabricator.haskell.org/D4234 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 13:59:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 13:59:49 -0000 Subject: [GHC] #14550: Report the provenance of TyThings Message-ID: <045.a5cd0ea41a77c0b96a25ed0a6ac7848b@haskell.org> #14550: Report the provenance of TyThings -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One thing we are slightly nervous about regarding our resolution to #14396 is whether or not there will be a difficult to understand bug stemming from the fact that we may silently pick up an hs-boot TyThing, depending on when you do a lookup. You may be able to find the information by printing the TyThing with pprTyThing, but nothing is going to tell you, in the face, "Hey! This came from a boot file!" So, simonpj suggested that we extend the TyThing pretty-printer to say where a TyThing came from. This is a good question. The big question: where will we put the provenance? There are two possibilities: 1. Add a field in each constructor TyThing recording the provenance (this feels like a disruptive to an otherwise very simple union) 2. Add a field to each of the constructors Id, ConLike, TyCon, CoAxiom (this involves a lot more typing, but these constructors already have lots of fields so it's not as disruptive) The provenance will, for now, look something like: {{{ newtype TyThingSrc = TyThingSrc { tyThingFromBoot :: Bool } }}} and then `TcIface` will be extended to know if we're in boot and will fill things in accordingly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 14:09:39 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 14:09:39 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.4f49150d220500d53845285381b6d11b@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by alexbiehl): I hacked up a POC of this transformation (it excludes updatable thunks from consideration). I had a quick (non-scientific) glance over the amount of CMM code generated for W2.hs (example from #7258): {{{ vanilla ghc ~380000 LOC hacked ghc ~270000 LOC }}} I noticed a lots of small, nested closures which only needed a fraction of the free variables of their outer closures and hence didn't benefit from the transformation. > Some data along these lines would be extremely helpful in guiding what we do. I will instrument my GHC to collect some data to guide us from here. > Another variant: currently we insist that `[gv1,..gvm]` is a '''subset''' of `[fv1,..fvn]`, to avoid space leaks. But with some RTS support we could do better: the closure for `x` could point to the closure for `y`, but ''also'' have a bitmap (in `x`'s info table) to say which of `y`'s free vars are actually used by `x`. That would open up the possibility for much more flexible sharing, at the cost of more bitmaps etc. E.g. > {{{ > x = [fv1,...fv100] \ [a] -> > let y = [fv1,...fv99, a] \ [] -> ... > in ... > }}} Sound reasonable. Let's see what the data shows.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 15:21:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 15:21:18 -0000 Subject: [GHC] #14550: Report the provenance of TyThings In-Reply-To: <045.a5cd0ea41a77c0b96a25ed0a6ac7848b@haskell.org> References: <045.a5cd0ea41a77c0b96a25ed0a6ac7848b@haskell.org> Message-ID: <060.cac4dc8164553903baedc94cc143d3c6@haskell.org> #14550: Report the provenance of TyThings -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): For `TyCon` at least we already have this: the `AlgTyConRhs` is an `AbstractTyCon`. For type functions we have `FamTyConFlav` = `AbstractClosedSynFamilyTyCon`. Etc. I think this is probably the way to go. For `Id` we have `IdDetails`, which could perhaps add `AbstractVanillaId`. Etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 16:05:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 16:05:06 -0000 Subject: [GHC] #14548: Lexically scoped kind variables In-Reply-To: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> References: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> Message-ID: <061.3589f377b7c557c359b6294e75273ee4@haskell.org> #14548: Lexically scoped kind variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14288, #14498 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider this, with `ScopedTypeVariables`: > {{{ > f :: forall a. Char -> Proxy (a::k) -> Int > f = > }}} > Clearly `a` scopes over ``. But did you know that `k` does too? > > I think we'd ''expect'' `k` to scope if we wrote > {{{ > f :: forall (a :: K). Char -> Proxy (a::k) -> Int > }}} > with `k` appearing in the kind of an explicitly-forall'd binder. For > long time we could not have an explicit forall for a kind variable > (although we can now), so this was the ''only'' way to bring `k` into > scope. > > But it seems altogether less desirable that an occurrence of `k` buried > deep in the type should scope over `f`'s body. That's why we don't make > implicitly-bound type variables scope over the body: > {{{ > f :: Char -> Proxy (a::k) -> Int > }}} > Here `a` does ''not'' scope over ``. > > I doubt anyone would notice if we changed this behaviour, like this. > > * A type variable from the signature scopes over the body if > * It is explicitly forall'd, or > * It appears in a kind annotation of an explicitly-forall'd type > variable > > My reason for raising this is that it's solve #14498 (by making `kk` not > scope) in > a uniform way. New description: Consider this, with `ScopedTypeVariables`: {{{ f :: forall a. Char -> Proxy (a::k) -> Int f = }}} Clearly `a` scopes over ``. But did you know that `k` does too? I think we'd ''expect'' `k` to scope if we wrote {{{ f :: forall (a :: k). Char -> Proxy (a::k) -> Int }}} with `k` appearing in the kind of an explicitly-forall'd binder. For long time we could not have an explicit forall for a kind variable (although we can now), so this was the ''only'' way to bring `k` into scope. But it seems altogether less desirable that an occurrence of `k` buried deep in the type should scope over `f`'s body. That's why we don't make implicitly-bound type variables scope over the body: {{{ f :: Char -> Proxy (a::k) -> Int }}} Here `a` does ''not'' scope over ``. I doubt anyone would notice if we changed this behaviour, like this. * A type variable from the signature scopes over the body if * It is explicitly forall'd, or * It appears in a kind annotation of an explicitly-forall'd type variable My reason for raising this is that it's solve #14498 (by making `kk` not scope) in a uniform way. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 17:19:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 17:19:03 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.8abdd5f291366f8018067ce861b822cc@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard claims that `a` (and `kk`) ''should'' be in scope in the pattern declaration. But he didn't have time to explain wny. This comment is to remind him to add that explanation :-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 19:06:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 19:06:14 -0000 Subject: [GHC] #14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules Message-ID: <045.cb7cce9290a571655339780c5a935547@haskell.org> #14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.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: -------------------------------------+------------------------------------- Because of the way the GHCi defaults are applied, specifying `-XMonomorphismRestriction` or `-XNoExtendedDefaultRules` on the GHCi command line doesn't actually make those take effect at the interactive prompt. They get reset to their interactive defaults afterwards. This is rather surprising, and I think it should be fixed. One option is to dig through the parsed flags after setting the defaults to try to find these, but that sounds unpleasant. We're slowly accumulating hacks in this area, and it would be nice to find a better approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 19:16:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 19:16:49 -0000 Subject: [GHC] #14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules In-Reply-To: <045.cb7cce9290a571655339780c5a935547@haskell.org> References: <045.cb7cce9290a571655339780c5a935547@haskell.org> Message-ID: <060.fff04ed59cea9176a6cd6514ec853fea@haskell.org> #14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.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: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > Because of the way the GHCi defaults are applied, specifying > `-XMonomorphismRestriction` or `-XNoExtendedDefaultRules` on the GHCi > command line doesn't actually make those take effect at the interactive > prompt. They get reset to their interactive defaults afterwards. This is > rather surprising, and I think it should be fixed. > > One option is to dig through the parsed flags after setting the defaults > to try to find these, but that sounds unpleasant. We're slowly > accumulating hacks in this area, and it would be nice to find a better > approach. New description: Because of the way the GHCi defaults are applied, specifying `-XMonomorphismRestriction` or `-XNoExtendedDefaultRules` on the GHCi command line doesn't actually make those take effect at the interactive prompt. They get reset to their interactive defaults afterwards. This is rather surprising, and I think it should be fixed. {{{ dfeuer at squirrel> ghci -XMonomorphismRestriction Prelude> x = 3 Prelude> :t x x :: Num t => t -- What? I said I wanted the restriction! Prelude> :set -XMonomorphismRestriction Prelude> y = 3 Prelude> :t y y :: Integer }}} One option is to dig through the parsed flags after setting the defaults to try to find these, but that sounds unpleasant. We're slowly accumulating hacks in this area, and it would be nice to find a better approach. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 20:03:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 20:03:57 -0000 Subject: [GHC] #11503: TypeError woes (incl. pattern match checker) In-Reply-To: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> References: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> Message-ID: <062.7827039ee73f43f26d36fdf2a6ab6586@haskell.org> #11503: TypeError woes (incl. pattern match checker) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings, | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #14141 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon, I imagine there's a broad reason somewhere for {{{ [G] c ~ fsk, [G] fsk }}} not to be simplified to {{{ [G] c }}} Assuming that's the case I suspect maybe we should track known insoluble constraints the way we track known-bottoming expressions. Since `TypeError ... ~ fsk` and `TypeError ...` is insoluble, we could conclude that `fsk` is insoluble. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 21:43:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 21:43:12 -0000 Subject: [GHC] #14263: typeKind is quadratic In-Reply-To: <047.347eff46dcda74aa975a5781e6cb08f5@haskell.org> References: <047.347eff46dcda74aa975a5781e6cb08f5@haskell.org> Message-ID: <062.c2ffc34cb22d83c611b8e8b5238fa031@haskell.org> #14263: typeKind is quadratic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: dfeuer => (none) Comment: I'm told this shouldn't be a priority for me at the moment, so I'll release it for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 21:52:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 21:52:07 -0000 Subject: [GHC] #1290: ghc runs preprocessor too much In-Reply-To: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> References: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> Message-ID: <059.4c50f7758dd576c99b8c303ae4490862@haskell.org> #1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think this is essentially impossible to fix. Along with the ''import'' dependencies, there are also the ''preprocessing'' dependencies. If I have {{{#!hs module Blah where #include Foo.h }}} then I need to preprocess `Blah.hs` any time `Foo.h` changes. But that means we need to know that `Blah.hs` depends on `Foo.h`. Without detailed knowledge of the preprocessor language, I don't see any way to determine this. I'm very tempted to close this ticket as invalid, but let's see if anyone disagrees. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 21:56:53 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 21:56:53 -0000 Subject: [GHC] #1290: ghc runs preprocessor too much In-Reply-To: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> References: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> Message-ID: <059.b8f23ba1f093362e441112f1ba58d888@haskell.org> #1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 22:06:17 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 22:06:17 -0000 Subject: [GHC] #1290: ghc runs preprocessor too much In-Reply-To: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> References: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> Message-ID: <059.610238887b3f2eab979bea21c4f965ad@haskell.org> #1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): bgamari points out that if something like https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp goes in, we may get the information we need about preprocessor dependencies for CPP. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 22:56:38 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 22:56:38 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.6e6108b44d82543171b704e8c7cd71d2@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => dfeuer Comment: I'll trace this out some and see how far I can get. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 22:57:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 22:57:13 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.8955976f4553897535f50c4678098074@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): That is, try to learn something about what goes wrong in Phab:D3981. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 23:37:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 23:37:41 -0000 Subject: [GHC] #14254: The Binary instance for TypeRep smells a bit expensive In-Reply-To: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> References: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> Message-ID: <060.c6df4ff9e61bbbc6f6a349bab43f2823@haskell.org> #14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14337 | Differential Rev(s): Phab:D3998, Wiki Page: | Phab:D4082, Phab:D4085 -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"bc761ad9c65c7aa62d38db39c59a6c0ae59c8ab8/ghc" bc761ad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bc761ad9c65c7aa62d38db39c59a6c0ae59c8ab8" Cache TypeRep kinds aggressively Cache `TypeRep k` in each `TrApp` or `TrTyCon` constructor of `TypeRep (a :: k)`. This makes `typeRepKind` cheap. With this change, we won't need any special effort to deserialize typereps efficiently. The downside, of course, is that we make `TypeRep`s slightly larger. Reviewers: austin, hvr, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: carter, simonpj, rwbarton, thomie GHC Trac Issues: #14254 Differential Revision: https://phabricator.haskell.org/D4085 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 1 23:40:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Dec 2017 23:40:16 -0000 Subject: [GHC] #14254: The Binary instance for TypeRep smells a bit expensive In-Reply-To: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> References: <045.b0b485439de28cadfa61420f4ccc13a7@haskell.org> Message-ID: <060.c763467ece4bb182326494c69f603b83@haskell.org> #14254: The Binary instance for TypeRep smells a bit expensive -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14337 | Differential Rev(s): Phab:D3998, Wiki Page: | Phab:D4082, Phab:D4085 -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed Comment: Fixed by bc761ad9c65c7aa62d38db39c59a6c0ae59c8ab8. We now cache the `TypeRep` of the kind in each `TrTyCon` and `TrApp` constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 2 00:29:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Dec 2017 00:29:20 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.fab3a705975583c71356331dc328a540@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): It seems a bit disturbing that the T13822 panic with Phab:D3981 only seems to happen with the stage 2 compiler. I can compile it just fine with the stage 1 compiler. I'm compiling a profiling build now to try to get a better backtrace. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 2 00:43:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Dec 2017 00:43:22 -0000 Subject: [GHC] #14552: GHC panic on pattern synonym Message-ID: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> #14552: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, TypeInType, | ViewPatterns | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes, ViewPatterns, PatternSynonyms, TypeOperators, KindSignatures, PolyKinds, DataKinds, TypeFamilies, TypeInType, GADTs #-} import Data.Kind data family Sing a type a --> b = (a, b) -> Type type family (@@) (f::a --> b) (x::a) :: b data Proxy a = Proxy newtype Limit' :: (k --> Type) -> Type where Limit' :: (forall xx. Proxy xx -> f@@xx) -> Limit' f data Exp :: [Type] -> Type -> Type where TLam' :: Proxy f -> (forall aa. Proxy aa -> Exp xs (f @@ aa)) -> Exp xs (Limit' f) pattern FOO f <- TLam' Proxy (($ Proxy) -> f) }}} ---> {{{ $ ghci -ignore-dot-ghci 119-bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 119-bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {a_a1Mh b_a1Mi rep_a1MB r_a1MC} tenv [a1MC :-> r_a1MC] cenv [] tys [k_a1Mj[ssk:3]] cos [] needInScope [a1Mj :-> k_a1Mj[ssk:3]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1205:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2136:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2159:29 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:2364:41 in ghc:TyCoRep substTyVarBndr, called at compiler/coreSyn/CoreSubst.hs:571:10 in ghc:CoreSubst Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1203:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2136:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2159:29 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:2364:41 in ghc:TyCoRep substTyVarBndr, called at compiler/coreSyn/CoreSubst.hs:571:10 in ghc:CoreSubst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 2 02:36:24 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Dec 2017 02:36:24 -0000 Subject: [GHC] #14549: RecordWildCards doesn't work properly in repl In-Reply-To: <046.4673855b1aa87324cadebb3b1903efa3@haskell.org> References: <046.4673855b1aa87324cadebb3b1903efa3@haskell.org> Message-ID: <061.5a138d46ccbb04b461e7bb8d7972cf59@haskell.org> #14549: RecordWildCards doesn't work properly in repl -------------------------------------+------------------------------------- Reporter: akegalj | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: repl, | recordwildcards Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): I would expect an error; the question is what error? If you write that code as a program, the compiler doesn't go past the second line: `Multiple declarations of ‘t1’` * The declaration for `Test` puts name `t1` in scope -- as a field selector function. * The `t1 = 2` (tries to) create a different declaration of `t1` ===> fail. In the repl, I guess the `t1 = 2` shadows `Test`'s declaration of `t1`, so you don't get a failure at that point. This works: {{{ data Test = Test { t1 :: Int, t2 :: Int } deriving Show tt = let t1 = 2 in Test { t2 = 2, ..} main = print tt }}} You might also get your code to work if you compiled the declaration for `Test` into a separate module and imported it. (In effect that's what I'm doing with the `let`.) Then `t1` would refer to your local variable, and wouldn't clash with imported `t1`. In an expression using record syntax `Test { t2 = 2, t1 = t1 }`, the lhs `t1` must be a field label, the rhs `t1` must be your local variable. Then `Test { t2 = 2, .. }` should work. In general, the repl is a tool for hacking quick-and-dirty. Don't expect that if it accepts some line of code you have an overall coherent program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 2 06:40:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Dec 2017 06:40:45 -0000 Subject: [GHC] #14549: RecordWildCards doesn't work properly in repl In-Reply-To: <046.4673855b1aa87324cadebb3b1903efa3@haskell.org> References: <046.4673855b1aa87324cadebb3b1903efa3@haskell.org> Message-ID: <061.44bc939e5d87208cc678e1bfbd4d5347@haskell.org> #14549: RecordWildCards doesn't work properly in repl -------------------------------------+------------------------------------- Reporter: akegalj | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: Component: GHCi | Version: 8.2.1 Resolution: invalid | Keywords: repl, | recordwildcards Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akegalj): * status: new => closed * resolution: => invalid Comment: > I guess the t1 = 2 shadows Test's declaration of t1, so you don't get a failure at that point. ah, yes. I didn't think of that it could be name shadowing. It would be clear to me if I got warning about shadowing but I guess that is suppressed by default in the repl as otherways people would be annoyed seeing that error all the time - as it is a common use case for repl to shadow a variable. > You might also get your code to work if you compiled the declaration for Test into a separate module yes, that's why I got confused with the repl as it was working with compiled module. Thank you for a very detailed explanation - it makes perfect sense now. Closing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 2 14:41:27 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Dec 2017 14:41:27 -0000 Subject: [GHC] #14382: The 'impossible' happened whilst installing gi-gtk via cabal In-Reply-To: <052.f9c10851d0906622baeb7996269cc8e7@haskell.org> References: <052.f9c10851d0906622baeb7996269cc8e7@haskell.org> Message-ID: <067.17334d0c357d48080a0f6c6652080d8b@haskell.org> #14382: The 'impossible' happened whilst installing gi-gtk via cabal -------------------------------------+------------------------------------- Reporter: maartenjacobs | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: gtk, pango, | hs-boot Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This may have been fixed by 6998772043a7f0b0360116eb5ffcbaa5630b21fb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 2 15:46:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Dec 2017 15:46:59 -0000 Subject: [GHC] #481: Recompilation check fails for TH In-Reply-To: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> References: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> Message-ID: <061.6e07837e1440d03e1065dda0cd8ab649@haskell.org> #481: Recompilation check fails for TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: TH_recompile Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by saurabhnanda): * cc: saurabhnanda (added) Comment: Just wondering what would be the perf-impact of doing the extra "stability check" (as mentioned in https://ghc.haskell.org/trac/ghc/ticket/481#comment:11 )? A lot of the code that we write uses TH heavily (eg. deriving ToJSON/FromJSON instances, test-suites, deriving lenses, etc) and I was wondering if this particular issue is the reason for generally slow compile times. (Not that I have isolated this to be the reason -- just asking.) We have 1,200+ modules in our code-base and we use TH so heavily that it's enabled by default (via the Cabal file). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 2 21:32:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Dec 2017 21:32:08 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.fe9aff5c3b93c8b71e09ebab3b96db63@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Something really weird is going on. I tried building GHC with profiling to trace down the problem, but that made it go away. If GHC is encountering a correctness problems ''compiling itself'', then we have serious trouble on our hands. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 3 00:15:31 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Dec 2017 00:15:31 -0000 Subject: [GHC] #14553: Implement native CPP Message-ID: <045.adf1dad4e79717b77bccedf2aee73f71@haskell.org> #14553: Implement native CPP -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Proposal/NativeCpp explains why we might want to embed a C-like preprocessor (e.g., hpp) into GHC. This ticket tracks that proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 3 00:16:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Dec 2017 00:16:16 -0000 Subject: [GHC] #1290: ghc runs preprocessor too much In-Reply-To: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> References: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> Message-ID: <059.85be6886a846805f04936dbc14b1a325@haskell.org> #1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: 14553 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * blockedby: => 14553 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 3 00:18:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Dec 2017 00:18:01 -0000 Subject: [GHC] #1290: ghc runs preprocessor too much In-Reply-To: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> References: <044.83cfd67f7a50c84991c554d518089ac4@haskell.org> Message-ID: <059.127133099d400009849fc6cb55ac10ce@haskell.org> #1290: ghc runs preprocessor too much -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 6.7 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: 14553 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * keywords: => cpp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 3 01:21:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Dec 2017 01:21:01 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.9975f2e7c3dcc80ee509428b1ea1d49e@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Results so far: 1. If I compile GHC+D3981 with either `quick` or `prof`, then T13822 works fine, and passes Core lint. 2. If I compile GHC+D3981 with devel2, then it crashes as described in the differential comments. I'm hoping this info can help someone point me to a likely area to look for the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 3 04:48:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Dec 2017 04:48:17 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.d8f4712afee08bb74a6900f8525f95bb@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): What about this example: {{{#!hs data Ex = forall a. C a => MkEx (Proxy a) (F a) class C a where type F a type G a meth :: F a -> G a pattern P :: () => forall a. C a => G a -> Ex pattern P x <- MkEx _ (meth @a -> x) }}} Note that `meth`'s type is ambiguous, and thus we want to specialize it to the existential variable `a`. You might argue that we could bring `a` into scope by matching on the `Proxy` argument -- and you'd be right -- but that's akin to arguing that `forall` should never bring variables into scope in the bodies of definition because you can (almost) always use a pattern signature to bring a type variable into scope. I thus claim that bringing existentials into scope in pattern synonyms is indeed useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 3 04:54:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Dec 2017 04:54:10 -0000 Subject: [GHC] #14548: Lexically scoped kind variables In-Reply-To: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> References: <046.c2d8afd3f25b91d4bc36319eb48ef501@haskell.org> Message-ID: <061.d62e7fb6b9d3549b1cf9dee6e165c519@haskell.org> #14548: Lexically scoped kind variables -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14288, #14498 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I wouldn't expect `k` to scope over the body in either of the original examples. I think that users should have to explicitly bind `k` in the `forall` to get it to scope. However, making this not so painful will require sorting out [https://github.com/ghc-proposals/ghc-proposals/pull/83 this proposal] first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 3 05:33:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Dec 2017 05:33:45 -0000 Subject: [GHC] #14554: Core Lint error mixing Message-ID: <051.5e0e6c0ed6a121855ea808a25d27d322@haskell.org> #14554: Core Lint error mixing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to deeply embed ''Singletons''-style defunctionalization symbol application using the code from [http://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1014&context=compsci_pubs System FC with Explicit Kind Equality], I ran into the following `-dcore- lint` error: {{{#!hs {-# Language UndecidableInstances, DataKinds, TypeOperators, KindSignatures, PolyKinds, TypeInType, TypeFamilies, GADTs, LambdaCase, ScopedTypeVariables #-} import Data.Kind import Data.Proxy type a ~> b = (a, b) -> Type type family (@@) (f::k ~> k') (a::k)::k' data IdSym0 :: Type ~> Type type instance IdSym0 @@ a = a data KIND = X | FNARR KIND KIND data TY :: KIND -> Type where ID :: TY (FNARR X X) FNAPP :: TY (FNARR k k') -> TY k -> TY k' data TyRep (kind::KIND) :: TY kind -> Type where TID :: TyRep (FNARR X X) ID TFnApp :: TyRep (FNARR k k') f -> TyRep k a -> TyRep k' (FNAPP f a) type family IK (kind::KIND) :: Type where IK X = Type IK (FNARR k k') = IK k ~> IK k' type family IT (ty::TY kind) :: IK kind where IT ID = IdSym0 IT (FNAPP f x) = IT f @@ IT x zero :: TyRep X a -> IT a zero = \case TFnApp TID a -> undefined }}} {{{ $ ghci -ignore-dot-ghci -dcore-lint ~/hs/123-bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /home/baldur/hs/123-bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): ASSERT failed! Bad coercion hole {a2UN}: (IT (a_a1S5 |> Sym (TY (Sym co_a2UC))_N) |> D:R:IK[0]) (IT (a_a1S5 |> Sym (TY (Sym co_a2UC))_N) |> D:R:IK[0]) nominal <(IT (a_a1S5 |> Sym (TY (Sym co_a2UC))_N) |> D:R:IK[0])>_N IT (a_a1S5 |> Sym (TY (Sym co_a2UC))_N) IT (a_a1S5[ssk:3] |> Sym (TY (Sym co_a2UC))_N) nominal Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1205:22 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:305:105 in ghc:TcMType Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1203:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:305:105 in ghc:TcMType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 3 21:03:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Dec 2017 21:03:20 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.e6b69c638d6aa01e4117bac278ee077b@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by duog): Hope this isn't all obvious: Of the four flavours [quick, prof, devel2-stage1, devel2-stage2], only devel2-stage2 is compiled with -DDEBUG and hence has the failing assertion enabled. I would expect that commenting out the assertion would have devl2-stage2 succeed as well (or fail on another assertion!). Either the assertion is wrong, or it's problem is later corrected (since core lint passes). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 4 01:05:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Dec 2017 01:05:37 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.cbe742fc6aad1892b19d5ae2e3b89845@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Yes that's obvious, but I missed it anyway. Whoops! I'll have to run a prof build with debug on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 4 11:41:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Dec 2017 11:41:37 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.6b817ed939a23f173afabf59f6e1c6ed@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johndoe): I still want to resolve my issue. So I need to specify `-specs=` in gcc commandline. How can I do it now? Is there some ghc config, or environment variable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 4 11:58:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Dec 2017 11:58:36 -0000 Subject: [GHC] #14372: CMM contains a bunch of tail-merging opportunities In-Reply-To: <048.1c543d9c1482e4763ed7a0bf48a66309@haskell.org> References: <048.1c543d9c1482e4763ed7a0bf48a66309@haskell.org> Message-ID: <063.567102d9b17d5172a90bae593e6c1327@haskell.org> #14372: CMM contains a bunch of tail-merging opportunities -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jp.rider63): Yes, I was slightly confused about the CBE discussion, but it seems somewhat related. FYI, this is my [https://github.com/bos/aeson/pull/599 motivating example]. The speedup I thought was happening due to eliminating common tails actually turned out to be from (lack of) inlining on someone else's machine. Either way, I think it makes sense to benchmark performance differences and see if this change is worthwhile. Even if performance is similar, it might be worth implementing to reduce code size. For my use case, one optimization that might help more is creating lookup tables when matching on `Word8`. Maybe I'll create another ticket for that in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 4 16:19:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Dec 2017 16:19:16 -0000 Subject: [GHC] #14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so In-Reply-To: <047.5a0900c5c72a8eef1106855d270e16d7@haskell.org> References: <047.5a0900c5c72a8eef1106855d270e16d7@haskell.org> Message-ID: <062.b9f5e048cf43801036721e1e7a5a7c91@haskell.org> #14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 4 16:20:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Dec 2017 16:20:00 -0000 Subject: [GHC] #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA In-Reply-To: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> References: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> Message-ID: <058.fb9836bfeaac52796febc3a1c6b72e73@haskell.org> #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | https://github.com/ntc2/ghc-8.2.1 | -regex-lazy-text- | bug/tree/07b7bb32c6e90e8f2d2eada4b59943f37e632d53 Blocked By: | Blocking: Related Tickets: #13745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Don't forget to try with `-fno-state-hack`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 4 16:39:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Dec 2017 16:39:36 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.aa91cebba7b811ac8291d8e741219d35@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by dfeuer): As discussed today, the plan in comment:10 seems to offer the ability to deal also with the case where several, but not all, of the free variables are reused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 4 16:40:42 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Dec 2017 16:40:42 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.e2f1a0b745f3d8b706ff1e6d66991f7c@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 4 20:31:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Dec 2017 20:31:10 -0000 Subject: [GHC] #14524: Use sortOn instead of sortWith In-Reply-To: <047.0bc1966b1ffbd164ce0f293aadc3e1a2@haskell.org> References: <047.0bc1966b1ffbd164ce0f293aadc3e1a2@haskell.org> Message-ID: <062.7daf9936da4bdb5fb0f4b358ba69712a@haskell.org> #14524: Use sortOn instead of sortWith -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | 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:D4233 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => closed * resolution: => wontfix Comment: The patch increased allocations (slightly) when compiling files. Doing a quick benchmark to check if/how much faster it is showed that: `sortWith` is at least still faster when the given function is a simple pattern match like the function below for any reasonably sized list. When testing up to 500 000 elements sortWith beat sortOn by >10% consistently. Even more so when it's just a selector like `\(a,_,_) -> a`. {{{ f:: T -> T -> T -> Int f _ A A = 1 f B _ _ = 2 f C _ C = 3 f D _ _ = 4 f _ C B = 7 f A E A = 8 f _ _ _ = 5 }}} So using `sortWith` by default in GHC is the right call. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 4 21:55:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Dec 2017 21:55:58 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.5a3b991996aba09b8032e29006ae7c22@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): In your cabal file you can use `cc-options: -specs=` or from the commandline `optc-specs=`. You may also need to change in `lib\package.conf.d\` the `base-*.conf` and the `ghc-prim-*.conf` files changing the extra-libraries part. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 4 23:59:10 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Dec 2017 23:59:10 -0000 Subject: [GHC] #14555: GHC Panic with TypeInType / levity polymorphism Message-ID: <051.f3f2f3a78aa3ad60bb5bcdd87ce66417@haskell.org> #14555: GHC Panic with TypeInType / levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism, TypeInType | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language TypeInType #-} {-# Language TypeOperators, DataKinds, PolyKinds #-} import Data.Kind import GHC.Types (TYPE) data Exp :: [TYPE rep] -> TYPE rep -> Type where Lam :: Exp (a:xs) b -> Exp xs (a -> b) }}} gives {{{ $ ghci -ignore-dot-ghci hs/126-bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/126-bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): zonkTcTyVarToVar 'LiftedRep Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcType.hs:1640:17 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} caused by `TypeInType`. Removing the first line, we get an error {{{ GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/126-bug.hs, interpreted ) hs/126-bug.hs:7:19: error: • Expected kind ‘GHC.Types.RuntimeRep’, but ‘rep’ has kind ‘*’ • In the first argument of ‘TYPE’, namely ‘rep’ In the kind ‘[TYPE rep] -> TYPE rep -> Type’ | 7 | data Exp :: [TYPE rep] -> TYPE rep -> Type where | ^^^ hs/126-bug.hs:7:32: error: • Expected kind ‘GHC.Types.RuntimeRep’, but ‘rep’ has kind ‘*’ • In the first argument of ‘TYPE’, namely ‘rep’ In the kind ‘[TYPE rep] -> TYPE rep -> Type’ | 7 | data Exp :: [TYPE rep] -> TYPE rep -> Type where | ^^^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 00:03:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 00:03:27 -0000 Subject: [GHC] #14555: GHC Panic with TypeInType / levity polymorphism In-Reply-To: <051.f3f2f3a78aa3ad60bb5bcdd87ce66417@haskell.org> References: <051.f3f2f3a78aa3ad60bb5bcdd87ce66417@haskell.org> Message-ID: <066.03b2cf56ad41ad6a780084fec1e0fb4c@haskell.org> #14555: GHC Panic with TypeInType / levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism, 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): Simpler example {{{#!hs data Exp :: TYPE rep -> Type where Lam :: Exp (a -> b) }}} can be fixed by explicitly quantifying over `rep` {{{#!hs data Exp :: forall rep. TYPE rep -> Type where -- ... -- data Exp :: forall (rep::RuntimeRep). TYPE rep -> Type where -- ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 01:07:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 01:07:53 -0000 Subject: [GHC] #14505: CircleCI only builds pushed heads In-Reply-To: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> References: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> Message-ID: <061.495a9c666725a4b22ee15babe461c65f@haskell.org> #14505: CircleCI only builds pushed heads -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chak): Replying to [comment:2 bgamari]: > Indeed it appears that the CircleCI API [[https://circleci.com/docs/2.0/faq/#can-i-use-the-api-with-workflows|can not be used]] to start workflow builds. That is bad, but from what I understand it is a not-yet-implemented type of shortcoming (i.e., workflows are new in 2.0 and the API hasn't caught up to all 2.0 features yet). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 04:12:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 04:12:37 -0000 Subject: [GHC] #14556: Core Lint error: Ill-kinded result in coercion Message-ID: <051.0e355f10cac8235c3846ef7abeef362e@haskell.org> #14556: Core Lint error: Ill-kinded result in coercion -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14554 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language UndecidableInstances, DataKinds, TypeOperators, KindSignatures, PolyKinds, TypeInType, TypeFamilies, GADTs, LambdaCase, ScopedTypeVariables #-} import Data.Kind import Data.Proxy data Fn a b where IdSym :: Fn Type Type type family (@@) (f::Fn k k') (a::k)::k' where IdSym @@ a = a data KIND = X | FNARR KIND KIND data TY :: KIND -> Type where ID :: TY (FNARR X X) FNAPP :: TY (FNARR k k') -> TY k -> TY k' data TyRep (kind::KIND) :: TY kind -> Type where TID :: TyRep (FNARR X X) ID TFnApp :: TyRep (FNARR k k') f -> TyRep k a -> TyRep k' (FNAPP f a) type family IK (kind::KIND) :: Type where IK X = Type IK (FNARR k k') = Fn (IK k) (IK k') type family IT (ty::TY kind) :: IK kind where IT ID = IdSym IT (FNAPP f x) = IT f @@ IT x zero :: TyRep X a -> IT a zero = undefined }}} which gives Core lint error when run with `ghci -ignore-dot-ghci -dcore- lint` (8.3.20171122) attached. It compiles fine with {{{#!hs zero :: TyRep X a -> IT a zero = zero }}} but fails with `zero = let x = x in x`. See #14554. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 04:12:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 04:12:56 -0000 Subject: [GHC] #14556: Core Lint error: Ill-kinded result in coercion In-Reply-To: <051.0e355f10cac8235c3846ef7abeef362e@haskell.org> References: <051.0e355f10cac8235c3846ef7abeef362e@haskell.org> Message-ID: <066.27fcbbb3b17a2bddae59406d01b2e189@haskell.org> #14556: Core Lint error: Ill-kinded result in coercion -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14554 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "bug.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 04:13:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 04:13:43 -0000 Subject: [GHC] #14554: Core Lint error mixing In-Reply-To: <051.5e0e6c0ed6a121855ea808a25d27d322@haskell.org> References: <051.5e0e6c0ed6a121855ea808a25d27d322@haskell.org> Message-ID: <066.b20dd60577345db8ad09c29efe5d6194@haskell.org> #14554: Core Lint error mixing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | PolyKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14556 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * keywords: => TypeInType, PolyKinds * related: => #14556 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 13:03:53 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 13:03:53 -0000 Subject: [GHC] #14557: NoFib : fasta benchmark produces unexpected output on slow/fast modes. Message-ID: <047.d132111645495dd5344c5ba0e4fdc056@haskell.org> #14557: NoFib : fasta benchmark produces unexpected output on slow/fast modes. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib | Version: benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I aborted after hitting this one so maybe the issue exists for other benchmarks as well. Fails with HEAD/stage2 and ghc-8.2.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 13:04:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 13:04:43 -0000 Subject: [GHC] #14557: NoFib : fasta benchmark produces unexpected output on slow/fast modes. In-Reply-To: <047.d132111645495dd5344c5ba0e4fdc056@haskell.org> References: <047.d132111645495dd5344c5ba0e4fdc056@haskell.org> Message-ID: <062.2a4fd80fe13ec09c3fa778283a60d2f1@haskell.org> #14557: NoFib : fasta benchmark produces unexpected output on slow/fast modes. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by AndreasK: Old description: > I aborted after hitting this one so maybe the issue exists for other > benchmarks as well. > > Fails with HEAD/stage2 and ghc-8.2.1. New description: I aborted after hitting this one so maybe the issue exists for other benchmarks as well. Fails with HEAD/stage2 and ghc-8.2.1. Nofib commit at: ef4f8dc8ef51ce3353b76a0761c1a09e5ff30b67 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 15:11:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 15:11:48 -0000 Subject: [GHC] #14557: NoFib : fasta benchmark produces unexpected output on slow/fast modes. In-Reply-To: <047.d132111645495dd5344c5ba0e4fdc056@haskell.org> References: <047.d132111645495dd5344c5ba0e4fdc056@haskell.org> Message-ID: <062.51b4529c2ef10aaf45ba06d4c9c04bae@haskell.org> #14557: NoFib : fasta benchmark produces unexpected output on slow/fast modes. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => closed * resolution: => fixed * component: NoFib benchmark suite => Documentation Comment: Turns out `mode=slow` needs to be passed to `make boot` as well. I will update the wiki to include the info. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 19:32:18 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 19:32:18 -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.5d61eba468e6c57136757d185cf76392@haskell.org> #14534: Split T12971 into its own Makefile -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: patch Priority: low | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.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:D4252 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4252 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 22:12:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 22:12:41 -0000 Subject: [GHC] #9364: GHCi (or haskeline?) confused by non-single-width characters In-Reply-To: <046.188450f148764a8992314b4689d05445@haskell.org> References: <046.188450f148764a8992314b4689d05445@haskell.org> Message-ID: <061.90a2e521b0d88a842024cb8d3b0ad378@haskell.org> #9364: GHCi (or haskeline?) confused by non-single-width characters -------------------------------------+------------------------------------- Reporter: cheater | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: linux, | terminal, colour, color, prompt Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #5850 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cheater): Evan Laforge brought up the following fix on ghc-dev: ------------ Here's what I use: :set prompt "\ESC[46m\STX%s>\ESC[39;49m\STX " I believe \STX is a signal to haskeline for control sequences. Documentation is here: https://github.com/judah/haskeline/wiki/ControlSequencesInPrompt -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 22:14:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 22:14:07 -0000 Subject: [GHC] #9364: GHCi (or haskeline?) confused by non-single-width characters In-Reply-To: <046.188450f148764a8992314b4689d05445@haskell.org> References: <046.188450f148764a8992314b4689d05445@haskell.org> Message-ID: <061.e19a58019699db936b33f16539600cb9@haskell.org> #9364: GHCi (or haskeline?) confused by non-single-width characters -------------------------------------+------------------------------------- Reporter: cheater | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: wontfix | Keywords: linux, | terminal, colour, color, prompt Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #5850 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by cheater): * status: new => closed * resolution: => wontfix Comment: Because the \STX escape character works well for reaching the intended scenario, I am resolving this bug. The resolution comes from haskeline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 22:25:25 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 22:25:25 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.7e72c0c3a77493442648f2b7fb229c28@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * Attachment "criterion_log.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 5 22:29:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Dec 2017 22:29:56 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.32481931289071fdc5c7aca5d552b4a5@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): I added rudimentary support for Records and made it work nicely with -XStrict. After playing around with nofib a lot I have essentially given up using it as a primary benchmarking tool I tried using nofib to benchmark (compile times) for #14524 which was inconclusive even when the performance difference for the function in question was ~10%. Running nofib with my changes didn't really produce results for the same issue of variance drowning out any difference the results would have made. == So my plan for now is: * Ditch nofib for the time being. * Create micro benchmarks and use criterion to check the difference. * Once I feel i have a reasonably sized set of benchmarks: * Look for pattern matching heavy real world examples and benchmark these. Based on the results of the OCaml implementation I don't expect measurable results unless there are not trivial patterns in a inner loop. * Gather feedback if gain/complexity trade off warrants inclusion in GHC. * Depending on the outcome of the above stop working on this or tidy up my code and get it into HEAD. == Micro Benchmarks: I mirror them on [https://github.com/AndreasPK/pattern_benchmarks Github]. Here is a [https://cdn.rawgit.com/AndreasPK/pattern_benchmarks/31dd3321/results/res_noinline.html result] for two simple patterns. I've uploaded the results also as attachment if GH becomes unavailable. (criterion_log) The two patterns I started with (each once used with enums once with Int) are at worst as fast and at best ~15% faster. (But then 15% of little is still not much). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 05:10:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 05:10:28 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file Message-ID: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.2.2 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- integer-gmp version 1.0.1.0 has this line in [https://hackage.haskell.org/package/integer-gmp-1.0.1.0/revision/0.cabal its Cabal file]: {{{ build-depends: ghc-prim ^>= 0.5.1.0 }}} That uses the new caret constraint syntax. That syntax was introduced by Cabal 2 a few months ago in July/August. Attempting to build integer-gmp with a slightly older version of Cabal, like 1.24.2.0, or with the latest released version of Stack (1.5.1) fails with this error: {{{ Unable to parse cabal file for integer-gmp-1.0.1.0: NoParse "build- depends" 58 }}} This was reported on Stack's issue tracker and on Reddit: - https://github.com/commercialhaskell/stack/issues/3624 - https://www.reddit.com/r/haskell/comments/7hs20y/how_to_fix_stack_unable_to_parse_cabal_file/ I was not able to find an issue tracker for integer-gmp. Someone suggested that I open an issue here instead. I can see how this isn't a bug per se because integer-gmp's Cabal file specifies {{{ cabal-version: 2.0}}}. Nevertheless, it's frustrating that a core library is using a bleeding edge feature for basically no reason. It would be nice if integer-gmp used the more typical {{{ cabal-version: >= 1.10}}} and specified its dependency as {{{ build-depends: ghc-prim >= 0.5.1 && <0.6}}}, without the caret operator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 05:30:05 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 05:30:05 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.4a24943c7bb0765bf653b0b93c7a9a15@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snoyberg): In addition, I'm unable to find this format of the cabal file anywhere in GHC's git repo. Both master and ghc-8.2.2-release show an integer- gmp.cabal with cabal-version set to >= 1.10. At the very least, it seems like good practice to ensure that whatever is uploaded to Hackage matches the files GHC itself is shipping artifacts from. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 05:43:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 05:43:39 -0000 Subject: [GHC] #14298: Let Template Haskell dynamically add something with which to link In-Reply-To: <050.5b84ef44d6dba8c28fe71b17d035f8a7@haskell.org> References: <050.5b84ef44d6dba8c28fe71b17d035f8a7@haskell.org> Message-ID: <065.deb304c00c512ee063ca94155e888373@haskell.org> #14298: Let Template Haskell dynamically add something with which to link -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4064 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcdonell): * cc: tmcdonell (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 08:16:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 08:16:15 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.12fabd719020a78eaf3c36c908c35d77@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: (none) => hvr * failure: Compile-time crash or panic => None/Unknown Comment: Thank you for contacting GHC HQ. I'll look into this claim. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 09:05:20 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 09:05:20 -0000 Subject: [GHC] #14559: When overlapping instances lead to a compile error, show import chains for the instances Message-ID: <051.049a0f6ffedae651165b0f2b3fb85fbd@haskell.org> #14559: When overlapping instances lead to a compile error, show import chains for the instances -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's an example from work: {{{ • Overlapping instances for ToJSON BackupPhrase arising from a use of 'aesonRoundtripProp' Matching instances: instance ToJSON BackupPhrase -- Defined in 'Cardano.Wallet.Orphans.Aeson' instance ToJSON BackupPhrase -- Defined in 'Pos.Wallet.Aeson.ClientTypes' }}} Currently resolving such issues requires looking carefully at all imports and trying to guess which ones bring the instance into scope. It'd be quite helpful if the error was explicit about the import chain: {{{ • Overlapping instances for ToJSON BackupPhrase arising from a use of 'aesonRoundtripProp' Matching instances: instance ToJSON BackupPhrase -- Defined in 'Cardano.Wallet.Orphans.Aeson', -- imported by 'Cardano.Wallet.Orphans' instance ToJSON BackupPhrase -- Defined in 'Pos.Wallet.Aeson.ClientTypes', -- imported by 'Pos.Wallet.Web.Mode', -- and then by 'Cardano.Wallet.API.V1.Migration' }}} Thoughts? I'm worried about two things here: 1. Might these chains get too long? 2. Is it sufficiently obvious that “imported by `A` and then by `B`” means that you have imported `B` and `B` imported `A`, and not vice-versa? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 09:58:30 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 09:58:30 -0000 Subject: [GHC] #481: Recompilation check fails for TH In-Reply-To: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> References: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> Message-ID: <061.421e973fa8a3e741e68c11c9a703d883@haskell.org> #481: Recompilation check fails for TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: TH_recompile Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): We already do that stability check. But recompilation of TH could be improved if we had a better idea of what the TH code actually depended on - when it's arbitrary I/O, we have to be necessarily conservative and assume that anything could change. There's some design to do here to figure out what a better solution would look like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 11:33:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 11:33:44 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.8d0d2b5e9a4714b81554b02bc1851bd9@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 11:35:28 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 11:35:28 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.e060b5db1f2bf4b873731cd5a584d128@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by steshaw): * cc: steshaw (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 15:08:12 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 15:08:12 -0000 Subject: [GHC] #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms Message-ID: <049.25bf49feed284d8f44f75075401b54fa@haskell.org> #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Keywords: type error | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In section Associated pattern synonyms on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms is written class ListLike l where pattern Nil :: l a pattern Cons :: a -> l a -> a isNil :: l a -> Bool isNil Nil = True isNil (Cons _ _) = False yet should Cons not have signature pattern Cons :: a -> l a -> l a append :: l a -> l a -> l a -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 15:09:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 15:09:44 -0000 Subject: [GHC] #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms In-Reply-To: <049.25bf49feed284d8f44f75075401b54fa@haskell.org> References: <049.25bf49feed284d8f44f75075401b54fa@haskell.org> Message-ID: <064.8d10b726b92ba7e5f368573110b29f95@haskell.org> #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: type error Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by pjljvdlaar: Old description: > In section Associated pattern synonyms on > https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms > is written > > class ListLike l where > pattern Nil :: l a > pattern Cons :: a -> l a -> a > isNil :: l a -> Bool > isNil Nil = True > isNil (Cons _ _) = False > > yet should Cons not have signature > > pattern Cons :: a -> l a -> l a > > append :: l a -> l a -> l a New description: In section Associated pattern synonyms on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms is written {{{ class ListLike l where pattern Nil :: l a pattern Cons :: a -> l a -> a isNil :: l a -> Bool isNil Nil = True isNil (Cons _ _) = False }}} yet should Cons not have signature {{{ pattern Cons :: a -> l a -> l a }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 15:23:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 15:23:35 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.255ddf0eba3279c07cbc7c8e87ccf17a@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * cc: mboes (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 15:26:06 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 15:26:06 -0000 Subject: [GHC] #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms In-Reply-To: <049.25bf49feed284d8f44f75075401b54fa@haskell.org> References: <049.25bf49feed284d8f44f75075401b54fa@haskell.org> Message-ID: <064.fdca87bb42b1b8c99d18680bae0fd4c8@haskell.org> #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: type error, | 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: type error => type error, newcomer Comment: Indeed. Do note that you can edit the wiki yourself (by clicking "Edit this page" at the bottom), so it should be quite straightforward to fix this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 16:10:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 16:10:24 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.bceceddc40e9ba8aaf6d56b2c9383bea@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Comment (by George): Is the plan to remove proc-point splitting for 8.4.1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 16:23:40 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 16:23:40 -0000 Subject: [GHC] #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms In-Reply-To: <049.25bf49feed284d8f44f75075401b54fa@haskell.org> References: <049.25bf49feed284d8f44f75075401b54fa@haskell.org> Message-ID: <064.a385fab442406de8c3fc025efb3f2eaf@haskell.org> #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: type error, | 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 pjljvdlaar): indeed: easy to change... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 16:24:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 16:24:04 -0000 Subject: [GHC] #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms In-Reply-To: <049.25bf49feed284d8f44f75075401b54fa@haskell.org> References: <049.25bf49feed284d8f44f75075401b54fa@haskell.org> Message-ID: <064.06dc21b8f7f5acb11641d910c5526e72@haskell.org> #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: pjljvdlaar Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: | Keywords: type error, | 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 pjljvdlaar): * owner: (none) => pjljvdlaar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 16:24:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 16:24:27 -0000 Subject: [GHC] #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms In-Reply-To: <049.25bf49feed284d8f44f75075401b54fa@haskell.org> References: <049.25bf49feed284d8f44f75075401b54fa@haskell.org> Message-ID: <064.cbef565989a4bb8bd780fc20835e919c@haskell.org> #14560: Typo in example on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: pjljvdlaar Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 Resolution: fixed | Keywords: type error, | 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 pjljvdlaar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 6 20:04:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Dec 2017 20:04:04 -0000 Subject: [GHC] #14561: Panic on levity polymorphic very unsafe coerce Message-ID: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> #14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeInType #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE MagicHash #-} module LevityId where import GHC.Types import GHC.Prim levityPolymorphicId :: forall (a :: TYPE r). a -> a levityPolymorphicId = unsafeCoerce# }}} {{{ (GHC version 8.3.20170928 for x86_64-apple-darwin): runtimeRepPrimRep typePrimRep (a_aW0 :: TYPE r_aVZ) r_aVZ Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1144:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:358:5 in ghc:RepType runtimeRepPrimRep, called at compiler/simplStg/RepType.hs:344:5 in ghc:RepType kindPrimRep, called at compiler/simplStg/RepType.hs:307:18 in ghc:RepType typePrimRep, called at compiler/simplStg/UnariseStg.hs:666:8 in ghc:UnariseStg Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} As originally mentioned [https://github.com/ghc-proposals/ghc- proposals/pull/98#issuecomment-349727273 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 05:11:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 05:11:12 -0000 Subject: [GHC] #481: Recompilation check fails for TH In-Reply-To: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> References: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> Message-ID: <061.63251624760dd03e125b6f41704892df@haskell.org> #481: Recompilation check fails for TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: TH_recompile Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by saurabhnanda): > We already do that stability check. My earlier comment was more about whether anyone has studied the perf- impact of the existing stability check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 07:03:26 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 07:03:26 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.24909126217a644b163ac7eae0481e62@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bergmark): * cc: bergmark (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 08:57:21 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 08:57:21 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.7bdba0f3be911d2d01cd1cb01b44fcff@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4254 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D4254 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 10:33:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 10:33:31 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.341a48b33e5905a9eb07de5e7023cdef@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed * type: bug => task Comment: I'm happy to inform you the issue has been resolved and we've taken steps that will ensure this won't be an issue in the future anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 11:28:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 11:28:47 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.00bb5ae1fca1dde2894c0a0c48155932@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by leon): If you haven't done so already, please also look at base-4.10.1.0\\ It has the same problem and it's the next thing stack will trip over after fixing integer-gmp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 12:24:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 12:24:53 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.ff81b21737eed031f3a04291f0eb94be@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snoyberg): Can you clarify how this has been resolved? The file on Hackage and in 01-index.tar.gz both appear to still have cabal-version: 2.0, preventing Stack 1.5 from building with GHC 8.2. Also, it would be helpful to know what steps have been taken to ensure it won't happen in the future, and what led to this situation in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 12:29:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 12:29:50 -0000 Subject: [GHC] #14561: Panic on levity polymorphic very unsafe coerce In-Reply-To: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> References: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> Message-ID: <062.6736081c50b4462a6dff106604f8dfcc@haskell.org> #14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah, hum. Lint rejects the program thus {{{ *** Core Lint errors : in result of Desugar (after optimization) *** : warning: [in body of lambda with binder v_B1 :: a_aVG] Levity-polymorphic binder: v_B1 :: (a_aVG :: TYPE r_aVF) *** Offending Program *** levityPolymorphicId :: forall (a :: TYPE r). a -> a [LclIdX] levityPolymorphicId = \ (@ (r_aVF :: RuntimeRep)) (@ (a_aVG :: TYPE r_aVF)) (v_B1 :: a_aVG) -> v_B1 }}} This happens because we want to allow {{{ unsafeCoerce# (x::Int#) }}} and expand it to {{{ x |> (UnsafeCo ...) }}} So we give `unsafeCoerce#` the extremely dodgy unfolding {{{ /\r1 r2 (a:Type r1) (b:Type r2) (x:a). x |> UnsafeCo ... }}} It's dodgy because it has a bad lambda: we can't lambda-bind a levity- polymorphic variable `x`. It only works when `unsafeCoerce#` is saturated. This is tiresome. The only paths forward I can see are * Do not allow `unsafeCoerce` on unboxed values. I don't know how much it is used. * Check that all uses are saturated. Perhaps in the desugarer. The latter would be least destabilising. Any thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 13:21:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 13:21:10 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.4033fba41b7fbbeeb95d3d392fd6f35d@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by taylorfausak): Seconding everything @snoyberg said. There are no new versions or revisions of integer-gmp. The current version/revision has not changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 13:27:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 13:27:38 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.5b4dde5b36b91c6a701264202bce4c7b@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): It seems that only comment:1 has been "fixed": * https://git.haskell.org/ghc.git/commitdiff/5f332e1dab000e1f79c127d441f618280d14d2bd * https://git.haskell.org/ghc.git/commit/3fa061a647d2fdc182eff9296eea02d6a7d516cd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 13:29:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 13:29:54 -0000 Subject: [GHC] #14562: IntRep vs WordRep Message-ID: <049.2af6b30a2d125c78a368294cddd4b9bc@haskell.org> #14562: IntRep vs WordRep -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Why do `Int#` and `Word#` have different runtime representations? By this I mean that: {{{#!hs Int# :: TYPE 'IntRep Word# :: TYPE 'WordRep }}} To my understanding, they are always the same size and always live in the same set of registers. The docs for unsafeCoerce# state that it can be used for: > Casting an unboxed type to another unboxed type of the same size (but not coercions between floating-point and integral types) The implies that a cast between `Int#` and `Word#` is acceptable. But if you're able to unsafeCoerce# between two types, shouldn't they be defined as having the same representation? What I'm suggesting is that it may be better to collapse `IntRep` and `WordRep` into a single representation (probably named `WordRep`). We would then get slightly more reusable code in some cases: {{{#!hs data WordList (x :: TYPE 'WordRep) = WordListCons x (WordList x) | WordListNil ints :: WordList Int# ints = WordListCons 5# (WordListCons 8# WordListNil) words :: WordList Word# words = WordListCons 4## (WordListCons 12## WordListNil) mapWordList :: forall (x :: TYPE 'WordRep). (x -> x) -> WordList x -> WordList x mapWordList _ WordListNil = WordListNil mapWordList f (WordListCons x xs) = WordListCons (f x) xs biggerInts :: WordList Int# biggerInts = mapWordList (\x -> x +# 3) ints biggerWords :: WordList Int# biggerWords = mapWordList (\x -> plusWord# x 3) ints }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 13:36:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 13:36:17 -0000 Subject: [GHC] #14562: IntRep vs WordRep In-Reply-To: <049.2af6b30a2d125c78a368294cddd4b9bc@haskell.org> References: <049.2af6b30a2d125c78a368294cddd4b9bc@haskell.org> Message-ID: <064.ed5088ee44552fc4003e7245416ae897@haskell.org> #14562: IntRep vs WordRep -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by andrewthad: Old description: > Why do `Int#` and `Word#` have different runtime representations? By this > I mean that: > > {{{#!hs > Int# :: TYPE 'IntRep > Word# :: TYPE 'WordRep > }}} > > To my understanding, they are always the same size and always live in the > same set of registers. The docs for unsafeCoerce# state that it can be > used for: > > > Casting an unboxed type to another unboxed type of the same size (but > not coercions between floating-point and integral types) > > The implies that a cast between `Int#` and `Word#` is acceptable. But if > you're able to unsafeCoerce# between two types, shouldn't they be defined > as having the same representation? > > What I'm suggesting is that it may be better to collapse `IntRep` and > `WordRep` into a single representation (probably named `WordRep`). We > would then get slightly more reusable code in some cases: > > {{{#!hs > > data WordList (x :: TYPE 'WordRep) > = WordListCons x (WordList x) > | WordListNil > > ints :: WordList Int# > ints = WordListCons 5# (WordListCons 8# WordListNil) > > words :: WordList Word# > words = WordListCons 4## (WordListCons 12## WordListNil) > > mapWordList :: forall (x :: TYPE 'WordRep). (x -> x) -> WordList x -> > WordList x > mapWordList _ WordListNil = WordListNil > mapWordList f (WordListCons x xs) = WordListCons (f x) xs > > biggerInts :: WordList Int# > biggerInts = mapWordList (\x -> x +# 3) ints > > biggerWords :: WordList Int# > biggerWords = mapWordList (\x -> plusWord# x 3) ints > }}} New description: Why do `Int#` and `Word#` have different runtime representations? By this I mean that: {{{#!hs Int# :: TYPE 'IntRep Word# :: TYPE 'WordRep }}} To my understanding, they are always the same size and always live in the same set of registers. The docs for unsafeCoerce# state that it can be used for: > Casting an unboxed type to another unboxed type of the same size (but not coercions between floating-point and integral types) The implies that a cast between `Int#` and `Word#` is acceptable. But if you're able to unsafeCoerce# between two types, shouldn't they be defined as having the same representation? What I'm suggesting is that it may be better to collapse `IntRep` and `WordRep` into a single representation (probably named `WordRep`). We would then get slightly more reusable code in some cases: {{{#!hs data WordList (x :: TYPE 'WordRep) = WordListCons x (WordList x) | WordListNil ints :: WordList Int# ints = WordListCons 5# (WordListCons 8# WordListNil) words :: WordList Word# words = WordListCons 4## (WordListCons 12## WordListNil) mapWordList :: forall (x :: TYPE 'WordRep). (x -> x) -> WordList x -> WordList x mapWordList _ WordListNil = WordListNil mapWordList f (WordListCons x xs) = WordListCons (f x) xs biggerInts :: WordList Int# biggerInts = mapWordList (\x -> x +# 3) ints biggerWords :: WordList Int# biggerWords = mapWordList (\x -> plusWord# x 3) ints }}} For additional context, I'd add that, excluding `SumRep` and `TupleRep` (because you can produce different nestings with equivalent representations), coercions between types of different representations are always unsound. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 13:39:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 13:39:48 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.825310fcbd2cf14a4f4356c8a7b8b9ab@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snoyberg): @hsyl20 Thanks for pointing that out. If that was the referenced fix, it's definitely not what I had in mind. I believe this ticket should be reopened. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 14:39:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 14:39:00 -0000 Subject: [GHC] #14554: Core Lint error mixing In-Reply-To: <051.5e0e6c0ed6a121855ea808a25d27d322@haskell.org> References: <051.5e0e6c0ed6a121855ea808a25d27d322@haskell.org> Message-ID: <066.0075c23418efde9acfaf7ded33ab5cd8@haskell.org> #14554: Core Lint error mixing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | PolyKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14556 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's worth noting that what you've posted is a failed `ASSERT`, not a Core Lint error. Nevertheless, you _do_ experience a Core Lint error if you use a build that doesn't have `ASSERT`ions enabled. Here's what I get with GHC 8.2.2: {{{ [1 of 1] Compiling Main ( Bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (after optimization) *** : warning: [in body of letrec with binders $dIP_a2S7 :: HasCallStack] Bad axiom application (check_ki1 D:R:@@TYPETYPEIdSym0a[0] Sym (TY (Sym (Nth:0 cobox)))_N)>_N IK 'X a_a1wo *) D:R:@@TYPETYPEIdSym0a[0] Sym (TY (Sym (Nth:0 cobox)))_N)>_N : warning: [in body of letrec with binders $dIP_a2S7 :: HasCallStack] Bad axiom application (check_ki2 D:R:@@TYPETYPEIdSym0a[0] Sym (TY (Sym (Nth:0 cobox)))_N)>_N IK 'X a_a1wo *) D:R:@@TYPETYPEIdSym0a[0] Sym (TY (Sym (Nth:0 cobox)))_N)>_N : warning: [in body of letrec with binders $dIP_a2S7 :: HasCallStack] Kind application error in coercion ‘((@@) (Sym (D:R:IK[0])) (Sym (D:R:IK[0])) (Trans (Sym (Coh _N (Trans (((,) (Sym (D:R:IK[0])) (Sym (D:R:IK[0])))_N ->_N <*>_N) (Sym (D:R:IK[1] <'X>_N <'X>_N))))) (Sym (Coh (D:R:IT[0]) (D:R:IK[1] <'X>_N <'X>_N)))) (TY (Nth:0 cobox))_N)>_N)_R’ Function kind = forall k k'. (k ~> k') -> k -> k' Arg kinds = [(*, *), (*, *), (IdSym0, (*, *) -> *), (IT (a_a1PD |> (TY (Nth:0 cobox))_N), IK 'X)] *** Offending Program *** zero :: forall (a :: TY 'X). TyRep 'X a -> (IT a |> D:R:IK[0]) [LclIdX] zero = \ (@ (a_a1Pz :: TY 'X)) -> break<1>() \ (ds_d2U1 :: TyRep 'X a_a1Pz) -> join { fail_d2UH :: Void# -> (IT a_a1Pz |> D:R:IK[0]) [LclId[JoinId(1)]] fail_d2UH _ [Occ=Dead, OS=OneShot] = patError @ 'LiftedRep @ (IT a_a1Pz |> D:R:IK[0]) "Bug.hs:(37,8)-(38,27)|case"# } in case ds_d2U1 of { __DEFAULT -> jump fail_d2UH void#; TFnApp @ k_a1PB @ f_a1PC @ a_a1PD cobox_a1PE ds_d2UG _ [Occ=Dead] -> case ds_d2UG of { __DEFAULT -> jump fail_d2UH void#; TID cobox_a1PF cobox_a1PG -> let { $dIP_a2S7 :: HasCallStack [LclId] $dIP_a2S7 = (pushCallStack (unpackCString# "undefined"#, SrcLoc (unpackCString# "main"#) (unpackCString# "Main"#) (unpackCString# "Bug.hs"#) (I# 38#) (I# 19#) (I# 38#) (I# 28#)) ((emptyCallStack `cast` (Sym (N:IP[0] <"callStack">_N _N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint)) ) `cast` (N:IP[0] <"callStack">_N _N :: ((?callStack::CallStack) :: Constraint) ~R# (CallStack :: *))) ) `cast` (Sym (N:IP[0] <"callStack">_N _N) :: (CallStack :: *) ~R# ((?callStack::CallStack) :: Constraint)) } in (break<0>() undefined @ 'LiftedRep @ (IT (a_a1PD |> Sym (TY (Sym (Nth:0 cobox)))_N) |> D:R:IK[0]) $dIP_a2S7) `cast` (Sym (<(IT (a_a1PD |> Sym (TY (Sym (Nth:0 cobox)))_N) |> D:R:IK[0])>_R |> Sym D:R :IK[0]) ; Sub (Sym (D:R:@@TYPETYPEIdSym0a[0] Sym (TY (Sym (Nth:0 cobox)))_N)>_N)) ; ((@@) (Sym (D:R:IK[0])) (Sym (D:R:IK[0])) (Trans (Sym (Coh (Sym _N) (Trans (((,) (Sym (D:R:IK[0])) (Sym (D:R:IK[0])))_N ->_N <*>_N) (Sym (D:R:IK[1] <'X>_N <'X>_N))))) (Sym (Coh (D:R:IT[0]) (D:R:IK[1] <'X>_N <'X>_N)))) (TY (Nth:0 cobox))_N)>_N)_R ; Sub (Sym (D:R:IT[1] <'X>_N <'X>_N <'ID>_N <(a_a1PD |> Sym (TY (Sym (Nth:0 cobox)))_N)>_N)) ; (IT <'X>_N (Trans ('FNAPP <'X>_N (Nth:0 (Sym cobox)) (Trans (Sym (Coh (Sym (Coh <'ID>_N (TY ('FNARR <'X>_N (Nth:1 (Nth:0 (Sym (Kind cobox)))))_ N)_N)) (Sym (Kind cobox)))) (Coh (Sym cobox) (Sym (Kind cobox)))) (Coh _N (TY (Nth:0 cobox))_N))_N (Sym cobox)))_R ; Sym (_R |> D:R:IK[0]) :: ((IT (a_a1PD |> Sym (TY (Sym (Nth:0 cobox)))_N) |> D:R:IK[0]) :: *) ~R# ((IT a1_a1Pz |> D:R:IK[0]) :: *)) } } $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) $krep_a2TJ [InlPrag=[~]] :: KindRep [LclId] $krep_a2TJ = $WKindRepVar (I# 1#) $krep_a2TB [InlPrag=[~]] :: KindRep [LclId] $krep_a2TB = $WKindRepVar (I# 0#) $krep_a2U0 [InlPrag=[~]] :: KindRep [LclId] $krep_a2U0 = KindRepTyConApp $tc(,) (: @ KindRep krep$* (: @ KindRep krep$* ([] @ KindRep))) $krep_a2TZ [InlPrag=[~]] :: KindRep [LclId] $krep_a2TZ = KindRepFun $krep_a2U0 krep$* $krep_a2TK [InlPrag=[~]] :: KindRep [LclId] $krep_a2TK = $WKindRepVar (I# 2#) $krep_a2TN [InlPrag=[~]] :: KindRep [LclId] $krep_a2TN = $WKindRepVar (I# 3#) $tcIdSym0 :: TyCon [LclIdX] $tcIdSym0 = TyCon 1961622809926585738## 3423181666860199358## $trModule (TrNameS "IdSym0"#) 0# $krep_a2TZ $tcKIND :: TyCon [LclIdX] $tcKIND = TyCon 9515352812269918203## 11516430088381478906## $trModule (TrNameS "KIND"#) 0# krep$* $krep_a2TR [InlPrag=[~]] :: KindRep [LclId] $krep_a2TR = KindRepTyConApp $tcKIND ([] @ KindRep) $tc'X :: TyCon [LclIdX] $tc'X = TyCon 5225325308912582631## 14983302646393556978## $trModule (TrNameS "'X"#) 0# $krep_a2TR $krep_a2TE [InlPrag=[~]] :: KindRep [LclId] $krep_a2TE = KindRepTyConApp $tc'X ([] @ KindRep) $krep_a2TQ [InlPrag=[~]] :: KindRep [LclId] $krep_a2TQ = KindRepFun $krep_a2TR krep$* $krep_a2TY [InlPrag=[~]] :: KindRep [LclId] $krep_a2TY = KindRepFun $krep_a2TR $krep_a2TR $krep_a2TX [InlPrag=[~]] :: KindRep [LclId] $krep_a2TX = KindRepFun $krep_a2TR $krep_a2TY $tc'FNARR :: TyCon [LclIdX] $tc'FNARR = TyCon 840343631093516326## 18087347551297534695## $trModule (TrNameS "'FNARR"#) 0# $krep_a2TX $krep_a2TI [InlPrag=[~]] :: KindRep [LclId] $krep_a2TI = KindRepTyConApp $tc'FNARR (: @ KindRep $krep_a2TJ (: @ KindRep $krep_a2TB ([] @ KindRep))) $krep_a2TD [InlPrag=[~]] :: KindRep [LclId] $krep_a2TD = KindRepTyConApp $tc'FNARR (: @ KindRep $krep_a2TE (: @ KindRep $krep_a2TE ([] @ KindRep))) $tcTY :: TyCon [LclIdX] $tcTY = TyCon 11778282896417043628## 9463294164882319066## $trModule (TrNameS "TY"#) 0# $krep_a2TQ $krep_a2TA [InlPrag=[~]] :: KindRep [LclId] $krep_a2TA = KindRepTyConApp $tcTY (: @ KindRep $krep_a2TB ([] @ KindRep)) $krep_a2Tz [InlPrag=[~]] :: KindRep [LclId] $krep_a2Tz = KindRepFun $krep_a2TA krep$* $krep_a2TW [InlPrag=[~]] :: KindRep [LclId] $krep_a2TW = KindRepTyConApp $tcTY (: @ KindRep $krep_a2TJ ([] @ KindRep)) $krep_a2TV [InlPrag=[~]] :: KindRep [LclId] $krep_a2TV = KindRepFun $krep_a2TW $krep_a2TA $krep_a2TU [InlPrag=[~]] :: KindRep [LclId] $krep_a2TU = KindRepTyConApp $tcTY (: @ KindRep $krep_a2TI ([] @ KindRep)) $krep_a2TT [InlPrag=[~]] :: KindRep [LclId] $krep_a2TT = KindRepFun $krep_a2TU $krep_a2TV $tc'FNAPP :: TyCon [LclIdX] $tc'FNAPP = TyCon 7529990373351007495## 105093863811657267## $trModule (TrNameS "'FNAPP"#) 2# $krep_a2TT $krep_a2TP [InlPrag=[~]] :: KindRep [LclId] $krep_a2TP = KindRepTyConApp $tc'FNAPP (: @ KindRep $krep_a2TB (: @ KindRep $krep_a2TJ (: @ KindRep $krep_a2TK (: @ KindRep $krep_a2TN ([] @ KindRep))))) $krep_a2TS [InlPrag=[~]] :: KindRep [LclId] $krep_a2TS = KindRepTyConApp $tcTY (: @ KindRep $krep_a2TD ([] @ KindRep)) $tc'ID :: TyCon [LclIdX] $tc'ID = TyCon 9233083350606244650## 12129174132981040339## $trModule (TrNameS "'ID"#) 0# $krep_a2TS $krep_a2TF [InlPrag=[~]] :: KindRep [LclId] $krep_a2TF = KindRepTyConApp $tc'ID ([] @ KindRep) $tcTyRep :: TyCon [LclIdX] $tcTyRep = TyCon 5846413146588040822## 5032305887285000310## $trModule (TrNameS "TyRep"#) 1# $krep_a2Tz $krep_a2TO [InlPrag=[~]] :: KindRep [LclId] $krep_a2TO = KindRepTyConApp $tcTyRep (: @ KindRep $krep_a2TB (: @ KindRep $krep_a2TP ([] @ KindRep))) $krep_a2TM [InlPrag=[~]] :: KindRep [LclId] $krep_a2TM = KindRepTyConApp $tcTyRep (: @ KindRep $krep_a2TJ (: @ KindRep $krep_a2TN ([] @ KindRep))) $krep_a2TL [InlPrag=[~]] :: KindRep [LclId] $krep_a2TL = KindRepFun $krep_a2TM $krep_a2TO $krep_a2TH [InlPrag=[~]] :: KindRep [LclId] $krep_a2TH = KindRepTyConApp $tcTyRep (: @ KindRep $krep_a2TI (: @ KindRep $krep_a2TK ([] @ KindRep))) $krep_a2TG [InlPrag=[~]] :: KindRep [LclId] $krep_a2TG = KindRepFun $krep_a2TH $krep_a2TL $tc'TFnApp :: TyCon [LclIdX] $tc'TFnApp = TyCon 8894026854411027209## 15109781203596368126## $trModule (TrNameS "'TFnApp"#) 4# $krep_a2TG $krep_a2TC [InlPrag=[~]] :: KindRep [LclId] $krep_a2TC = KindRepTyConApp $tcTyRep (: @ KindRep $krep_a2TD (: @ KindRep $krep_a2TF ([] @ KindRep))) $tc'TID :: TyCon [LclIdX] $tc'TID = TyCon 15519646662091825967## 1580287496060878## $trModule (TrNameS "'TID"#) 0# $krep_a2TC *** End of Offense *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 14:53:47 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 14:53:47 -0000 Subject: [GHC] #14561: Panic on levity polymorphic very unsafe coerce In-Reply-To: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> References: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> Message-ID: <062.74a5dec205b826c5c07a658e20f85776@haskell.org> #14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I strongly prefer the latter. It makes me nervous not to have a true back- door to the type system (which we would lose if we dropped the levity- polymorphism from `unsafeCoerce#`). It should be easy enough to check for saturation in the desugarer. But, actually, there's a third option: * Allow silly uses of `unsafeCoerce#` to cause a panic. The user is clearly taking on the risk of a runtime crash with `unsafeCoerce#`. We could just say they also risk taking on a compile-time crash. In this case, I think the fix (the saturation check) is easy enough, but I don't feel strongly committed to eradicating a hard-to-fix panic if the user abuses the type system with such a low-level operation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 17:40:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 17:40:27 -0000 Subject: [GHC] #14562: IntRep vs WordRep In-Reply-To: <049.2af6b30a2d125c78a368294cddd4b9bc@haskell.org> References: <049.2af6b30a2d125c78a368294cddd4b9bc@haskell.org> Message-ID: <064.3f48a0ad13bf490faa8a76aa8aad2007@haskell.org> #14562: IntRep vs WordRep -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I see sense in this, but I recall lots of to-and-fro about exactly when to distinguish signed (`Int`) from unsigned (`Word`) values. See particularly `Note [Signed vs unsigned]` in `cmm/CmmType`. I'm not arguing on way or another here, just mentioning that the signed/unsigned choice ripples surprisingly far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 17:50:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 17:50:11 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.c3922b34471714cfcde98d6542af3855@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fa29df02a1b0b926afb2525a258172dcbf0ea460/ghc" fa29df02/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fa29df02a1b0b926afb2525a258172dcbf0ea460" Refactor ConDecl: Trac #14529 This patch refactors HsDecls.ConDecl. Specifically * ConDeclGADT was horrible, with all the information hidden inside con_res_ty. Now it's kept separate, as it should be. * ConDeclH98: use [LHsTyVarBndr] instead of LHsQTyVars for the existentials. There is no implicit binding here. * Add a field con_forall to both ConDeclGADT and ConDeclH98 which says if there is an explicit user-written forall. * Field renamings in ConDecl con_cxt to con_mb_cxt con_details to con_args There is an accompanying submodule update to Haddock. Also the following change turned out to remove a lot of clutter: * add a smart constructor for HsAppsTy, namely mkHsAppsTy, and use it consistently. This avoids a lot of painful pattern matching for the common singleton case. Two api-annotation tests (T10278, and T10399) are broken, hence marking them as expect_broken(14529). Alan is going to fix them, probably by changing the con_forall field to con_forall :: Maybe SrcSpan instead of Bool }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 21:24:54 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 21:24:54 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.a9eac68d622b2bf021b8260df5b9cbe9@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I missed something that seems very important: the test failure Carlos describes does ''not'' occur with non-slow `./validate`, presumably because that doesn't enable debugging for the stage2 compiler. Indeed, I believe the problem with T13822 occurs ''without'' Carlos's patch! I'll verify tonight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 23:27:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 23:27:25 -0000 Subject: [GHC] #14563: GHC Panic with TypeInType / levity polymorphism Message-ID: <051.7f7c79248bc900573fbeefcc42311033@haskell.org> #14563: GHC Panic with TypeInType / levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism, TypeInType | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14555 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code is rightfully rejected. {{{#!hs -- {-# Language TypeInType #-} {-# Language RankNTypes, KindSignatures, PolyKinds #-} import GHC.Types (TYPE) import Data.Kind data Lan (g::TYPE rep -> TYPE rep') (h::TYPE rep -> TYPE rep'') a where Lan :: forall xx (g::TYPE rep -> TYPE rep') (h::TYPE rep -> Type) a. (g xx -> a) -> h xx -> Lan g h a }}} But uncomment first line and it panics {{{ $ ghci2 ~/hs/132-bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /home/baldur/hs/132-bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): zonkTcTyVarToVar 'LiftedRep Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcType.hs:1640:17 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} Maybe the same as #14555. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 23:27:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 23:27:46 -0000 Subject: [GHC] #14555: GHC Panic with TypeInType / levity polymorphism In-Reply-To: <051.f3f2f3a78aa3ad60bb5bcdd87ce66417@haskell.org> References: <051.f3f2f3a78aa3ad60bb5bcdd87ce66417@haskell.org> Message-ID: <066.e8ce790e7e12bf977552309f9e338959@haskell.org> #14555: GHC Panic with TypeInType / levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14563 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #14563 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 7 23:50:46 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Dec 2017 23:50:46 -0000 Subject: [GHC] #14561: Panic on levity polymorphic very unsafe coerce In-Reply-To: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> References: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> Message-ID: <062.f5e6ecb5fb4f8291371cda61614e6db0@haskell.org> #14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by andrewthad): * cc: andrewthad (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 01:13:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 01:13:45 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.cefe2f84ad6b9098b664f6920bbd23d1@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by taylorfausak): * status: closed => new * owner: hvr => (none) * resolution: fixed => Comment: Once again, I agree with @snoyberg. The problem is that integer-gmp requires Cabal 2. The fact that `integer-gmp.cabal` did not match what was in the Git repository was a problem (and I'm glad that it's fixed), but all it did was make debugging harder. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 04:59:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 04:59:26 -0000 Subject: [GHC] #14564: CAF isn't floated Message-ID: <050.1af4937b5006defb6915274137e1c026@haskell.org> #14564: CAF isn't floated -------------------------------------+------------------------------------- Reporter: neil.mayhew | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- In the following code, `pattern` isn't floated, and the execution time is 20x slower than it should be: {{{#!hs import Text.Regex.TDFA (Regex, makeRegex, match) main :: IO () main = do entries <- map parseFilename . lines <$> getContents let check (Right (_, t)) = last t == 'Z' check _ = False print $ all check entries parseFilename :: String -> Either String (String, String) parseFilename fn = case (pattern `match` fn :: [[String]]) of [[_, full, _, time]] -> Right $ (full, time) _ -> Left fn where pattern :: Regex pattern = makeRegex "^\\./duplicity-(full|inc|new)(-signatures)?\\.\ \([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9][0-9][0-9][0-9][0-9]Z)\\." }}} Curiously, it is floated when profiling is enabled, so the profiled program ends up being 7x faster than the unprofiled one. I can float the code manually (by taking out `where` and unindenting) and the program then runs at an acceptable speed. I get the same behaviour with 8.0.2, 8.2.1 and 8.2.2 but 7.10.3 is OK. I don't think the OS and architecture makes a difference, but for the record I'm on various flavours of 64-bit Linux. Test input data is [https://gist.github.com/neilmayhew/247a30738c0e294902e7c2830ca2c6f5 here] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 08:51:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 08:51:34 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.9558d6a836ba1af0edb354e89cc82b8a@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If I understand this right: 1. The versions of the library in GHC and the version in Hackage are now consistent; and the cabal files now specify Cabal 2 (which indeed they need). 2. The remaining problem is that GHC now requires a bleeding-edge Cabal 2, and indeed ships with it. But that gives a problem for other downstream clients of GHC which may not have as recent a Cabal. We should resolve (2) for the future. But meanwhile, I think (but I'm not certain) that we are stuck with it for 8.2. Is that right? Re (2), leon, hsyl20, taylorfausak: did you encounter this problem because Stack was (understandably) not using a sufficiently up to date Cabal. Or did you have an independent reason why the change to the cabal file format caused you a problem? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 09:37:06 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 09:37:06 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.46f5081534dcf02520a5e47194585b07@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 refold): IMO this is no longer an issue now that the bug in Stack has been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 09:50:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 09:50:16 -0000 Subject: [GHC] #14564: CAF isn't floated In-Reply-To: <050.1af4937b5006defb6915274137e1c026@haskell.org> References: <050.1af4937b5006defb6915274137e1c026@haskell.org> Message-ID: <065.9a11b60aa61e8d282b1ee7520d150cfa@haskell.org> #14564: CAF isn't floated -------------------------------------+------------------------------------- Reporter: neil.mayhew | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I took a look. Here's what is happening. Just before the full laziness pass (which does the floating) we have {{{ parseFilename = \ (fn_a35P :: String) -> case Text.Regex.Base.Context.$fRegexContextabAllTextMatches9 @ [Char] (Text.Regex.TDFA.String.$fRegexLikeRegex[]_go Text.Regex.TDFA.String.$fRegexContextRegex[][]3 fn_a35P (Text.Regex.TDFA.NewDFA.Engine.execMatch_$sexecMatch3 (case Text.Regex.TDFA.String.$w$cmakeRegexOpts Text.Regex.TDFA.Common.$fRegexOptionsRegexCompOptionExecOption_$cdefaultCompOpt Text.Regex.TDFA.Common.$fRegexOptionsRegexCompOptionExecOption_$cblankExecOpt (GHC.Base.build @ Char (\ (@ b_a5BF) -> GHC.CString.unpackFoldrCString# @ b_a5BF "^\\./duplicity-(full|inc|new)(-signatures)?\\.([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]T[0-9][0-9][0-9][0-9][0-9][0-9]Z)\\."#)) of { (# ww1, ww2, ww3, ww4, ww5, ww6, ww7, ww8, ww9, ww10 #) -> Text.Regex.TDFA.Common.Regex ww1 ww2 ww3 ww4 ww5 ww6 ww7 ww8 ww9 ww10 }) Text.Regex.TDFA.String.$fRegexContextRegex[][]3 Text.Regex.TDFA.String.$fRegexContextRegex[][]2 fn_a35P)) of { ... } }}} Somme inlining has happened, but the constant expression we want to float to top level is the argument to `$sexecMatch3`, namely {{{ (case Text.Regex.TDFA.String.$w$cmakeRegexOpts Text.Regex.TDFA.Common.$fRegexOptionsRegexCompOptionExecOption_$cdefaultCompOpt Text.Regex.TDFA.Common.$fRegexOptionsRegexCompOptionExecOption_$cblankExecOpt (GHC.Base.build @ Char (\ (@ b_a5BF) -> GHC.CString.unpackFoldrCString# @ b_a5BF "blah blah""#)) of { (# ww1, ww2, ww3, ww4, ww5, ww6, ww7, ww8, ww9, ww10 #) -> Text.Regex.TDFA.Common.Regex ww1 ww2 ww3 ww4 ww5 ww6 ww7 ww8 ww9 ww10 }) }}} Alas, if you look at `SetLevels.lvlMFE`, there is a special case for `case` expressions, discussed in `Note [Case MFEs]`. And, since `$sexecMatch3` is strict, the special case fires, and the case-expression is not floated. Now `Note [Case MFEs]` claims that we'll take a sparate decision for the scrutinee (which is where all the work is). But in this case the scrutinee is an unboxed tuple, which also can't float to top level. So we can't flat that either, and we just lose, as Neil discovered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 10:06:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 10:06:03 -0000 Subject: [GHC] #14564: CAF isn't floated In-Reply-To: <050.1af4937b5006defb6915274137e1c026@haskell.org> References: <050.1af4937b5006defb6915274137e1c026@haskell.org> Message-ID: <065.08afc072a4ea432fd1476af3671bdc8b@haskell.org> #14564: CAF isn't floated -------------------------------------+------------------------------------- Reporter: neil.mayhew | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FloatOut Comment: I can think of various ways to improve this * Make the ad-hoc special handling for case-expressions fire only if * The destination level is no top-level (then no extra thunk is created after all) * The scrutinee is lifted (so a separate decision can really be taken for the scrutinee -------------- I note also another problem with `Note [Case MFEs]`. Consider {{{ g y = h y (case (f 3) of Nothing -> True Just x -> expensive s) }}} If we don't float the whole case-expression, we can float `(f 3)` instead. But we won't float `expensive x`; so it will be computed for each call of `g`. Not very clever. Maybe we should just kill off the special case, and put up with a couple of nofib regressions. This needs a bit of careful performance comparison. Any volunteers? I can advise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 10:07:26 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 10:07:26 -0000 Subject: [GHC] #10535: Float out causes major space leak In-Reply-To: <045.805dcb016f0fb85535fb7bc68c72dcaf@haskell.org> References: <045.805dcb016f0fb85535fb7bc68c72dcaf@haskell.org> Message-ID: <060.779bdee0726b2e29788bdbca0f005453@haskell.org> #10535: Float out causes major space leak -------------------------------------+------------------------------------- Reporter: AlexET | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7367 #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FloatOut -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 10:07:45 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 10:07:45 -0000 Subject: [GHC] #7367: float-out causes extra allocation In-Reply-To: <045.fec15abb73687c53fcbc974d115b141d@haskell.org> References: <045.fec15abb73687c53fcbc974d115b141d@haskell.org> Message-ID: <060.7b94e939318d8a78995a72ee3e91f10e@haskell.org> #7367: float-out causes extra allocation -------------------------------------+------------------------------------- Reporter: wurmli | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research | needed Component: Compiler | Version: 7.6.1 Resolution: | Keywords: FloatOut Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FloatOut -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 10:07:58 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 10:07:58 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.504225f688beb94384e95140e1c81485@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FloatOut -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 10:08:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 10:08:24 -0000 Subject: [GHC] #8457: -ffull-laziness does more harm than good In-Reply-To: <044.229777d98aeb2cc7741c2bcf36225fde@haskell.org> References: <044.229777d98aeb2cc7741c2bcf36225fde@haskell.org> Message-ID: <059.1a626b5ab7c7c9423490a748d824b74f@haskell.org> #8457: -ffull-laziness does more harm than good -------------------------------------+------------------------------------- Reporter: errge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9520, #12620 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => FloatOut -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 10:08:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 10:08:37 -0000 Subject: [GHC] #917: -O introduces space leak In-Reply-To: <062.4116b6ef44458082738cb509a6e4cb7c@haskell.org> References: <062.4116b6ef44458082738cb509a6e4cb7c@haskell.org> Message-ID: <077.50b63f6e610129b7a56e440c4c6e121a@haskell.org> #917: -O introduces space leak -------------------------------------+------------------------------------- Reporter: claus.reinke@… | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 6.5 Resolution: | Keywords: FloatOut 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: => FloatOut -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 10:08:49 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 10:08:49 -0000 Subject: [GHC] #1945: Full laziness is sometimes a pessimisation In-Reply-To: <046.9837528e987eb0ecd6876e8d783d0b3c@haskell.org> References: <046.9837528e987eb0ecd6876e8d783d0b3c@haskell.org> Message-ID: <061.d4a52bbc7586e3ad5841bf96cf307efb@haskell.org> #1945: Full laziness is sometimes a pessimisation -------------------------------------+------------------------------------- Reporter: jleedev | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: duplicate | Keywords: FloatOut Operating System: 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: => FloatOut * failure: => None/Unknown -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 10:09:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 10:09:01 -0000 Subject: [GHC] #3273: memory leak due to optimisation In-Reply-To: <043.8d7f62a0a1af41f2de804ebbbba872f7@haskell.org> References: <043.8d7f62a0a1af41f2de804ebbbba872f7@haskell.org> Message-ID: <058.37d5899b2baadbbcf718339367c63e14@haskell.org> #3273: memory leak due to optimisation -------------------------------------+------------------------------------- Reporter: sebf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Resolution: duplicate | Keywords: FloatOut 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: => FloatOut -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 10:09:13 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 10:09:13 -0000 Subject: [GHC] #4276: -O0 runs in constant space, -O1 and -O2 don't In-Reply-To: <044.2c7e7766575fa720bafb9bb8d29a27bb@haskell.org> References: <044.2c7e7766575fa720bafb9bb8d29a27bb@haskell.org> Message-ID: <059.497790df7c918fc5cd5971f7ca5d9d6c@haskell.org> #4276: -O0 runs in constant space, -O1 and -O2 don't -------------------------------------+------------------------------------- Reporter: guest | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 7.4.1 Component: Compiler | Version: 6.12.1 Resolution: duplicate | Keywords: optimization | space leak, FloatOut Operating System: Windows | Architecture: x86 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: optimization space leak => optimization space leak, FloatOut -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 10:09:22 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 10:09:22 -0000 Subject: [GHC] #5729: ForeignPtr leak in ghci In-Reply-To: <045.23b98fcd0ea14f76cea51c6306754fc5@haskell.org> References: <045.23b98fcd0ea14f76cea51c6306754fc5@haskell.org> Message-ID: <060.5b4899c63b426e22a79e3fd460fc2e71@haskell.org> #5729: ForeignPtr leak in ghci ---------------------------------+-------------------------------------- Reporter: judahj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.2.1 Resolution: duplicate | Keywords: FloatOut 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 simonpj): * keywords: => FloatOut -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 10:13:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 10:13:55 -0000 Subject: [GHC] #14529: Refactor ConDecl In-Reply-To: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> References: <046.7e8014be489edb5a93e4613365b6acae@haskell.org> Message-ID: <061.7e31efc1c34e0ef95fae7365bf08c0ee@haskell.org> #14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: alanz (added) * owner: (none) => alanz Comment: OK Alan, over to you for the `con_forall` api-annotation fix. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 13:17:20 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 13:17:20 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.4132b597221767a809c1bdad40c82647@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: (none) => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 14:00:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 14:00:37 -0000 Subject: [GHC] #14565: Memory leak switching from -O1 to -O2 Message-ID: <047.9f19e5183099a904eb9898194bca4b27@haskell.org> #14565: Memory leak switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #14379 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC seems to get stuck at SpecConstr stage when compiling. Cpu and memory usage then sky rocket. I've managed to get the example down to what appears to be minimal but making a number of minor changes makes the compilation go through quickly: * changing `toIdx` to `const 0` * removing one of the `V.forM_` layers. * using "-fno-spec-constr" (unsuprisingly). I can't reproduce it on 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 14:02:14 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 14:02:14 -0000 Subject: [GHC] #14565: Memory leak switching from -O1 to -O2 In-Reply-To: <047.9f19e5183099a904eb9898194bca4b27@haskell.org> References: <047.9f19e5183099a904eb9898194bca4b27@haskell.org> Message-ID: <062.630d27a09db5826bb5151f9a3f4076e1@haskell.org> #14565: Memory leak switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14379 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dbeacham): * Attachment "Example.hs" added. Source file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 14:02:43 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 14:02:43 -0000 Subject: [GHC] #14565: Memory leak switching from -O1 to -O2 In-Reply-To: <047.9f19e5183099a904eb9898194bca4b27@haskell.org> References: <047.9f19e5183099a904eb9898194bca4b27@haskell.org> Message-ID: <062.7312acefc3b0558768bfc887eda9f2a6@haskell.org> #14565: Memory leak switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14379 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dbeacham): * Attachment "minimal.cabal" added. cabal file -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 14:09:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 14:09:05 -0000 Subject: [GHC] #14565: Performance degrades from -O1 to -O2 (was: Memory leak switching from -O1 to -O2) In-Reply-To: <047.9f19e5183099a904eb9898194bca4b27@haskell.org> References: <047.9f19e5183099a904eb9898194bca4b27@haskell.org> Message-ID: <062.8192b7620c604b9eaba8f6dde7812161@haskell.org> #14565: Performance degrades from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14379 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dbeacham: Old description: > GHC seems to get stuck at SpecConstr stage when compiling. Cpu and memory > usage then sky rocket. > > I've managed to get the example down to what appears to be minimal but > making a number of minor changes makes the compilation go through > quickly: > > * changing `toIdx` to `const 0` > * removing one of the `V.forM_` layers. > * using "-fno-spec-constr" (unsuprisingly). > > I can't reproduce it on 8.0.2. New description: GHC seems to get stuck at SpecConstr stage when compiling. I've managed to get the example down to what appears to be minimal but making a number of minor changes makes the compilation go through quickly: * changing `toIdx` to `const 0` * removing one of the `V.forM_` layers. * using "-fno-spec-constr" (unsuprisingly). I can't reproduce it on 8.0.2. In larger examples I was able to get memory and cpu to sky rocket quite quickly but I appear to have lost some of that behaviour when paring down the example. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 14:09:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 14:09:09 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.4aec2da91e1bc81df0f8750bbfe6aba7@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 mgsloan): @simonpj The versions of the library in GHC and the version in Hackage are not currently consistent. If I download ghc-8.2.1 from https://www.haskell.org/ghc/download_ghc_8_2_1.html and unpack it, the cabal file at `libraries/integer-gmp/integer-gmp.cabal` has `build- depends: ghc-prim`. However, the cabal file on hackage has `build- depends: ghc-prim ^>= 0.5.1.0`. It seems quite illogical that the versions of the packages would match, but their metadata would be different. It also is extremely puzzling why a new and experimental Cabal syntax feature, which is essentially syntax sugar, is being used in a core package. In the general case, usage of this operator will break builds for anyone using older versions of build tools, whether it is stack or cabal. So, I would not say that the discrepancy has been resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 14:14:09 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 14:14:09 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.20f870fbce1bcfbb59e1971426ef2277@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 taylorfausak): (1) is correct. As far as I can tell, the Cabal files on Hackage match the Cabal files in the GHC repository. This is good and I'm happy that it happened, but it's not why I opened this ticket. (2) is also correct. GHC and its built-in libraries require Cabal 2. This is obviously fine for GHC itself, but any downstream clients using GHC < 8.2 or Cabal < 2 are broken by this. (For example: https://github.com/tfausak/grawlix/commit/861f0f9d3f19ae9d94ce11b52311459e5a656534#commitcomment-25680505.) I don't think we are stuck with this problem for 8.2. As far as Stack < 1.6.1 is concerned, revising the `integer-gmp-1.0.1.0` release or releasing a new version of `integer-gmp` would fix things. Specifically, removing the caret constraint (and relaxing the `cabal-version`) would allow older versions of Cabal and Stack to successfully parse `integer- gmp.cabal`. The patch is pretty small: https://github.com/ghc/ghc/commit/82aae8c81f5380af5f5ab9c381b1d296104696f4 For what it's worth, I ran into this problem because Stack 1.5.1 ships with Cabal 1.24. I have fixed this problem for myself by upgrading to Stack 1.6.1. Anybody still using Stack < 1.6.1 will be broken if they try to use a snapshot with GHC >= 8.2. This includes anyone using the Haskell Platform, which bundles Stack 1.5.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 14:35:27 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 14:35:27 -0000 Subject: [GHC] #14565: Performance degrades from -O1 to -O2 In-Reply-To: <047.9f19e5183099a904eb9898194bca4b27@haskell.org> References: <047.9f19e5183099a904eb9898194bca4b27@haskell.org> Message-ID: <062.c174bfa693f1676943503fd3d45c9ae9@haskell.org> #14565: Performance degrades from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: dbeacham | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14379 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => SpecConstr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 14:45:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 14:45:16 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.c93d8e53c426445455963bcbf20acbde@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 leon): Yes, I encountered this using stack-1.5.1, (at that time the latest stable version I believe). And I only encountered the same issue in base because I (tried to) setup my own hackage mirror to workaround this issue. Now using stack-1.6.1 it all works again. But the big surprise was that this upload of integer-gmp to hackage broke stack's promise of reproducible builds. (Even using snapshots dated well before the upload of integer-gmp) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 14:59:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 14:59:33 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.ad21ee2b0832e5566ca886663d0891d2@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * cc: mgsloan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 15:30:30 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 15:30:30 -0000 Subject: [GHC] #14566: LiberateCase improvements Message-ID: <046.ee7d4a3e552f7d26630177953cc4f6f7@haskell.org> #14566: LiberateCase improvements -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was looking at the result of compiling `base:Data/Typeable/Internal`. It has a fairly large top-level recursive group of functions, involving `mkTrApp`. In doing so I noticed that `LiberateCase` was duplicating the entire top-level blob at a call of a function that was actually just a call to `error`. Totally nuts. This ticket tracks the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 15:37:32 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 15:37:32 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.094b25bb2a3df2a015831d8d3cd85ab2@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Phyx-): > But the big surprise was that this upload of integer-gmp to hackage broke stack's promise of reproducible builds. (Even using snapshots dated well before the upload of integer-gmp) Is this not a problem of stack? Should it not have been the one to guarantee that if it can't parse a package it does not enter it's system? If it makes such a guarantee it's up to it validate changes to preserve such guarantee. I don't understand how a new package can break LTS releases. It's unrealistic to expect GHC to never change. We can guarantee backwards compatibility but not forward compatibility. What I am missing here is why this is such a big deal. Yes the change was made by GHC upstream, yes it broke stack nightlies. But is it not the the purpose of nightlies to test the bleeding edge anyway? This isn't the last time the format will change. Let's fix the tools to actually adhere to what is in the `cabal-version` fields and move on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 15:38:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 15:38:55 -0000 Subject: [GHC] #14567: OccAnal loop-breaker scoring for NOINLINE things Message-ID: <046.71fcea1cacb8fc2ed19b5e3195d4aff7@haskell.org> #14567: OccAnal loop-breaker scoring for NOINLINE things -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When working on #14566 I found a case where the occurrence analyser generated {{{ Rec { {-# NOINLINE f #-} f = e1[g] ; g {-# LOOPBREAKER #-} = e2[f] } }}} That is, even though `f` is marked `NOINLINE` we chose `g` to be the loop breaker. Stupid! If `f` is marked `NOINLINE` it would be a much better loop breaker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 16:58:07 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 16:58:07 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.fa5e48f26e30d41d15e292d336ee2021@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Tehnix): * cc: tehnix (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 17:20:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 17:20:56 -0000 Subject: [GHC] #14567: OccAnal loop-breaker scoring for NOINLINE things In-Reply-To: <046.71fcea1cacb8fc2ed19b5e3195d4aff7@haskell.org> References: <046.71fcea1cacb8fc2ed19b5e3195d4aff7@haskell.org> Message-ID: <061.73792d2a366f5609753857115f375e9e@haskell.org> #14567: OccAnal loop-breaker scoring for NOINLINE things -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5695f462f604fc63cbb45a7f3073bc114f9b475f/ghc" 5695f462/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5695f462f604fc63cbb45a7f3073bc114f9b475f" Occurrrence analysis improvements for NOINLINE functions This patch fixes #14567. The idea is simple: if a function is marked NOINLINE then it makes a great candidate for a loop breaker. Implementation is easy too, but it needs a little extra plubming, notably the occ_unf_act field in OccEnv }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 17:20:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 17:20:56 -0000 Subject: [GHC] #14566: LiberateCase improvements In-Reply-To: <046.ee7d4a3e552f7d26630177953cc4f6f7@haskell.org> References: <046.ee7d4a3e552f7d26630177953cc4f6f7@haskell.org> Message-ID: <061.89e7c9b72c4a6d59b6ced59373ff8ffb@haskell.org> #14566: LiberateCase improvements -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"800009d9b78a9b2877e7efc889e8a0b21873990d/ghc" 800009d9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="800009d9b78a9b2877e7efc889e8a0b21873990d" Improve LiberateCase This patch, which fixes Trac #14566, makes LiberateCase a little more conservative. In particular: * In libCaseBind, treat a recursive group as a whole, rather than binding-by-binding, allowing the group to be duplicated only if - the bindings /considered together/ are smaller than the liberate-case threshold (which is large by default) - none of them are thunks - none of them are guaranteed-diverging The latter condidtion is new, and happens to apply in the case of Data/Typeable/Internal.mkTrApp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 17:28:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 17:28:42 -0000 Subject: [GHC] #14567: OccAnal loop-breaker scoring for NOINLINE things In-Reply-To: <046.71fcea1cacb8fc2ed19b5e3195d4aff7@haskell.org> References: <046.71fcea1cacb8fc2ed19b5e3195d4aff7@haskell.org> Message-ID: <061.9c36648883631041b38888ceb4782000@haskell.org> #14567: OccAnal loop-breaker scoring for NOINLINE things -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 17:28:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 17:28:50 -0000 Subject: [GHC] #14566: LiberateCase improvements In-Reply-To: <046.ee7d4a3e552f7d26630177953cc4f6f7@haskell.org> References: <046.ee7d4a3e552f7d26630177953cc4f6f7@haskell.org> Message-ID: <061.1ac87ca1c6175c430fb526a7344f0bf6@haskell.org> #14566: LiberateCase improvements -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 18:13:36 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 18:13:36 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.462f7114199a355d0360b07d06f61008@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 refold): IMO if Stack doesn't support the version of Cabal that ships with a certain version of GHC, it shouldn't claim that it supports that version of GHC. The same applies to `cabal-install` as well -- in the past, upgrading to a new version of GHC often required upgrading to a new version of `cabal-install`. There perhaps should be a warning on the GHC 8.2 download page that installing that version of GHC will require you to also upgrade Stack to 1.6.1+, like the download page warnings we had for `cabal-install` in the same situation in the past. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 18:46:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 18:46:21 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.39f2120fedfa048241c80bea0d65ba8f@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Comment (by kavon): Replying to [comment:32 George]: > Is the plan to remove proc-point splitting for 8.4.1? It's more likely for 8.6 or later. We have to align with the release cycle for LLVM as the removal depends on which version of LLVM the patch lands in. I'll put together a Trac ticket to track progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 18:50:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 18:50:02 -0000 Subject: [GHC] #440: parse error way too late In-Reply-To: <043.176fce8bbaac0b9ae1dc43ccc7060005@haskell.org> References: <043.176fce8bbaac0b9ae1dc43ccc7060005@haskell.org> Message-ID: <058.41d93d2ed4325d5eacd148cd550a3820@haskell.org> #440: parse error way too late -------------------------------------+-------------------- Reporter: as49 | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Parser) | Version: 6.2.2 Resolution: None | Keywords: Type of failure: None/Unknown | -------------------------------------+-------------------- Changes (by Ben Gamari ): * failure: => None/Unknown Comment: In [changeset:"7733e44dd4ba7e7a0a9f3456e6ddc32decbcf5a3/ghc" 7733e44d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7733e44dd4ba7e7a0a9f3456e6ddc32decbcf5a3" Rip out hadrian subtree Sadly subtrees haven't worked quite as well as we would have liked for developers. See Hadrian #440. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 19:35:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 19:35:44 -0000 Subject: [GHC] #14538: forkprocess01 fails occassionally on with multiple ACQUIRE_LOCK panic In-Reply-To: <046.6179459a606dda455f09a96c2a4bfb98@haskell.org> References: <046.6179459a606dda455f09a96c2a4bfb98@haskell.org> Message-ID: <061.fc6b61a15fc1cf11a1fecd0abcca594b@haskell.org> #14538: forkprocess01 fails occassionally on with multiple ACQUIRE_LOCK panic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 20:03:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 20:03:23 -0000 Subject: [GHC] #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs In-Reply-To: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> References: <042.e54472a7f0f2a529a27b8305f52eff87@haskell.org> Message-ID: <057.93735f78e56b84bc6cfa03afb274ea3d@haskell.org> #14192: Change to 1TB VIRT allocation makes it impossible to core-dump Haskell programs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.2 Resolution: fixed | Keywords: gdb, | debugging Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9706 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I can confirm that with this patch, `generate-core-file` works fine. For a simple 2-line application, it generates me a ~8 MB core file, and I can re-load that core file into gdb and look at the backtrace successfully. Nice work! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 8 23:17:56 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Dec 2017 23:17:56 -0000 Subject: [GHC] #14568: Uncurried Parameter to n-ary Function in Type Signature Causes Crash Message-ID: <043.787567ed9a955c32f001326ec110b870@haskell.org> #14568: Uncurried Parameter to n-ary Function in Type Signature Causes Crash -------------------------------------+------------------------------------- Reporter: nixy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you uncomment the arrow, everything's fine; GHC crashes as-is. {{{#!hs f :: (a -> b) {- -> -} a -> c f = undefined }}} Apparently GHC incorrectly parses any n-ary function parameter followed by another uncurried parameter in type signatures. System Info: GHC v8.2.1 GCC v5.4.0 Linux Mint (Linux 4.8.0-53-generic #56~16.04.1-Ubuntu SMP x86_64) ghc -v -dcore-lint: {{{ Glasgow Haskell Compiler, Version 8.2.1, stage 2 booted by GHC version 8.0.2 Using binary package database: /usr/local/haskell/ghc-8.2.1-x86_64/lib/ghc-8.2.1/package.conf.d/package.cache Using binary package database: /home/nic/.ghc/x86_64-linux-8.2.1/package.conf.d/package.cache package flags [] loading package database /usr/local/haskell/ghc-8.2.1-x86_64/lib/ghc-8.2.1/package.conf.d loading package database /home/nic/.ghc/x86_64-linux-8.2.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. package flags [] loading package database /usr/local/haskell/ghc-8.2.1-x86_64/lib/ghc-8.2.1/package.conf.d loading package database /home/nic/.ghc/x86_64-linux-8.2.1/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.1.0 wired-in package integer-gmp mapped to integer-gmp-1.0.1.0 wired-in package base mapped to base-4.10.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.12.0.0 wired-in package ghc mapped to ghc-8.2.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *bug.hs !!! Chasing dependencies: finished in 1.14 milliseconds, allocated 0.207 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2017-12-08 23:11:58.321654412 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file bug.hs *** Checking old interface for Main (use -ddump-hi-diffs for more details): [1 of 1] Compiling Main ( bug.hs, bug.o ) *** Parser [Main]: !!! Parser [Main]: finished in 0.13 milliseconds, allocated 0.090 megabytes *** Renamer/typechecker [Main]: *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: ghc: panic! (the 'impossible' happened) (GHC version 8.2.1 for x86_64-unknown-linux): repSplitAppTys a_anL[sk:1] b_anM[sk:1] [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:808:9 in ghc:Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 00:38:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 00:38:02 -0000 Subject: [GHC] #14568: Uncurried Parameter to n-ary Function in Type Signature Causes Crash In-Reply-To: <043.787567ed9a955c32f001326ec110b870@haskell.org> References: <043.787567ed9a955c32f001326ec110b870@haskell.org> Message-ID: <058.1086d06bc04ec0b9d130ec9f2f842d73@haskell.org> #14568: Uncurried Parameter to n-ary Function in Type Signature Causes Crash -------------------------------------+------------------------------------- Reporter: nixy | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Thanks for reporting this. A quick search for `repSplitAppTys` sugggests that this is a dup of #13819 and a number of other similar ones. Happily it's fixed in 8.2.2 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 03:34:39 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 03:34:39 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.e2636ce215e2a5165d0a89de3f7fc2c8@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 taylorfausak): Clearly there was a bug in Stack. I'm not denying that. There was a bug in Stack, and it has been fixed. The solution for Stack users is to upgrade Stack. The core of my complaint and this ticket is: > it's frustrating that a core library is using a bleeding edge feature for basically no reason It is demonstrably simple and easy to avoid using `^>=` constraints in core libraries. Doing so would ensure that the core libraries could be parsed with the greatest variety of tools. I think that is self-evidently good. As a thought experiment, consider what would happen if someone uploaded a `text-1.2.2.3` which was identical to `text-1.2.2.2` except that it specified `cabal-version: >= 2.0.1.1` instead of `cabal-version: >= 1.8`. Obviously the maintainers are well within their rights to make such a change. I am trying to argue that making a change like that is unnecessary and irresponsible. If such a change was made, I would encourage the maintainers to revert it. That's what I'm doing here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 07:31:10 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 07:31:10 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.030979d48b5e75ef7f81426b60d3d078@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 refold): If it was something like `text` or `directory` (which comes with GHC), or even `Cabal` itself, where it makes sense to upgrade them if you're running an old GHC version, I'd be against that as well. But in the case of a small number of wired-in non-upgradeable libraries like `base` and `integer-gmp`, an additional obstacle like this is actually a ''good'' thing. The solver in `cabal-install` also [https://github.com/haskell/cabal/blob/master/cabal- install/Distribution/Solver/Modular/Solver.hs#L127 goes out of its way] to prevent users from trying to reinstall `base` and `integer-gmp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 09:42:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 09:42:29 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.e53f4d36c7a3481778c5f60afbc64477@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Phyx-): I wouldn't even care if it was `text` or `directory`. I have a pretty clear stance on this to prevent hampering our ability to make progress in the future. If you have a technical merit for the reasons you don't like `^>=` than that is something we would listen to. However because you don't see the use of it doesn't mean it's wrong to use it. Using `^>=` has a clear benefit, and maintainers are free to use any features that's in the cabal file. Secondly like `refold` said, `integer-gmp` is a special build-in in that it requires build system support for systems using in-tree gmp. So there is a number of configurations that would break if you were to try to install the `integer-gmp` package. If you follow the dependency chain you'll notice it depends on `GHC-prim` which is compiler specific, which further depends on the `rts` package, which will soon also be a cabal package. Their presence on Hackage as far as I am aware are only for resolvers. You can't actually install them short of getting a new GHC version. Because of this, it is perfectly reasonable to use new bleeding edge features in these packages. As they are literally tied to GHC, and you should not be swapping them out/mixing and matching them. We don't guarantee ABI stability for them at all. I think we should learn from this experience. There was a non backwards compatible change in the cabal format. It may have been the first, but it won't be the last. Let's constructively find a way to prevent things from breaking in the future. Arguing about whether a library is allowed to use the bleeding edge isn't useful, the tools should handle this gracefully. and unless I'm mistaken, don't both `stack` and `cabal-install` do this now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 14:17:26 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 14:17:26 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.505dc5a59d30b1b1ab7f28c3b3696eb2@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Replying to [comment:26 Phyx-]: > [...] Using `^>=` has a clear benefit, and maintainers are free to use any features that's in the cabal file. [...] What is that "clear benefit"? It surely can't be saving roughly ten keystrokes. As I understand it, it is just (IMHO superfluous) syntactic sugar. If it's not, there should be a big announcement with some clarifications and the underlying rationale somewhere on the Haskell mailing lists. The cabal file syntax is at the core of the Haskell ecosystem, so everybody involved should have a clear understanding of its semantics. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 16:10:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 16:10:23 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.5227be51fe262b9bd193beff82701afd@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Phyx-): Replying to [comment:27 svenpanne]: > What is that "clear benefit"? It surely can't be saving roughly ten keystrokes. As I understand it, it is just (IMHO superfluous) syntactic sugar. If it's not, there should be a big announcement with some clarifications and the underlying rationale somewhere on the Haskell mailing lists. The cabal file syntax is at the core of the Haskell ecosystem, so everybody involved should have a clear understanding of its semantics. It was announced, about 3 months ago, http://coldwa.st/e/blog/2017-09-09-Cabal-2-0.html along with the future intention of this syntax and how it differs from the strong bounded versions: New caret-style version range operator ^>= (#3705) that is equivalent to >= intersected with an automatically inferred major upper bound. For example, foo ^>= 1.3.1 is equivalent to foo >= 1.3.1 && < 1.4. Besides being a convenient syntax sugar, ^>= allows to distinguish “strong” and “weak” upper bounds: foo >= 1.3.1 && < 1.4 means “I know for sure that my package doesn’t work with foo-1.4”, while foo ^>= 1.3.1 means “I don’t know whether foo-1.4, which is not out yet, will break my package, but I want to be cautious and follow PVP”. In the future, this feature will allow to implement automatic version bounds relaxation in a formally sound way (work on this front is progressing on matrix.hackage.haskell.org). See this section of the manual for more information. It was designed and approved in public https://github.com/haskell/cabal/pull/3705 it was publicly posted on reddit https://www.reddit.com/r/haskell/comments/6z2gja/whats_new_in_cabalcabalinstall_20_improved/ And the migration plan was outlined https://github.com/haskell/cabal/issues/4899. Could it be that perhaps a lot of people here don't read Cabal release information? Or follow Cabal development? At least taylorfausak can't possibly be surprised by it because he was even fighting with hvr about it in the reddit thread. FYI, it's also in the package changelog https://www.haskell.org/cabal/release/cabal-2.0.1.1/changelog which is linked to from https://www.haskell.org/cabal/download.html . The post never made it to the homepage due to some bikeshedding https://github.com/haskell/cabal-website/issues/3. It was also announced on twitter https://twitter.com/refold/status/906547449329831936 So I fail to see how any of this could have come at such a big surprise to anyone. The fact is, the change was not done in secret, the feature not developed in secret. The change was communicated well ahead of time and on channels that lots of you frequent. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 16:21:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 16:21:17 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.5449e99d1f5152baac614e3e92ce0264@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Phyx-): And I want to make this absolutely clear. In case there is any doubt at all. While I am not a user of stack, I have nothing against stack. It solves a problem many people have. However if you depend on an upstream project, it is your responsibility to keep track of it's development. There are plenty of ways to do so. Just like there were plenty of times before this where stack people could have worked together with Cabal people to form a migration plan. After the announcement would have been one such occasion. However as far as I can see, no one did so. If we don't get any feedback, we will assume there is no objection. The problem is this us vs you mentality that has somehow evolved. My changes to GHC at no time involve thinking about how to break stack. Despite all the assertion that our free time, which many of us willingly donate to help GHC is spent actively trying to sabotage another project. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 17:41:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 17:41:30 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.0c930ed06a4943fe0f9e897ea97da259@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 taylorfausak): Come on y'all. I'm trying to avoid turning this into an us versus them argument for all values of us and them. The problem described in this ticket affects people trying to install GHC >= 8.2 with Stack < 1.6.1. It also affects people like me who want to parse the package descriptions of the core libraries without depending on bleeding edge Cabal features. I'm also trying to avoid arguing about the `^>=` operator itself. We have a new operator, it's been talked to death, people are going to use it. Currently `^>= x.y.z` is syntactic sugar for `>= x.y.z && < x.(y+1)`. In the future, Hackage trustees may be able to make changes to `^>=` constraints because they are "soft". That brings me once again to the crux of this ticket: > it's frustrating that a core library is using a bleeding edge feature for basically no reason Is there a compelling reason for `integer-gmp` to use `^>=`? It has already been demonstrated that using `^>=` causes problems. I will happily close the ticket and be on my merry way if someone can say: "Yes, `integer-gmp` (or any core library) needs `^>=` (or any Cabal 2 feature) because //X//." I have not heard such a reason yet. It seems to me that the GHC developers are refusing to make a simple fix that will solve a problem for a large number of users. Also I'm having a hard time wrapping my head around why the `^>=` operator would ever be necessary for core libraries. As many people have pointed out in this ticket, `integer-gmp` cannot be reinstalled. So any revisions to its package description are essentially ignored. The whole point of `^>=`, as far as I can tell, is to allow Hackage trustees to revise the bounds if new valid build plans are discovered. That means using `^>=` in `integer-gmp` only saves a few keystrokes at best. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 21:34:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 21:34:40 -0000 Subject: [GHC] #14569: refutable let bindings produce "irrefutable pattern failed" errors Message-ID: <044.8464d6345485258705bd110865737bdc@haskell.org> #14569: refutable let bindings produce "irrefutable pattern failed" errors -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- In ghc-8.2.2 (probably since ghc-8.0.1), strict pattern matches in let bindings produce "Irrefutable pattern failed" errors. {{{#!hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Prelude> :set -XBangPatterns Prelude> let ![] = [1] in 1 *** Exception: :2:5-13: Irrefutable pattern failed for pattern [] }}} In ghc-7.10.2, normal pattern match failures were produced. {{{#!hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> :set -XBangPatterns Prelude> let ![] = [1] in 1 *** Exception: :3:5-13: Non-exhaustive patterns in pattern binding }}} To my mind, the latter error makes much more sense; the effect of the ! is to make the pattern an ordinary, refutable one. Could the old behavior be restored? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 21:37:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 21:37:47 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.4e43117f9831694f55ec146841910f92@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Replying to [comment:28 Phyx-]: > It was announced, about 3 months ago, http://coldwa.st/e/blog/2017-09-09-Cabal-2-0.html > along with the future intention of this syntax and how it differs from the strong bounded versions: [...] Hmmm, this is still confusing: On the one hand it is said (https://www.haskell.org/cabal/users-guide/developing- packages.html?highlight=caret#pkg-field-build-depends) that the new syntax is ''exactly'' equivalent to the old syntax using `>=` and `<`. OTOH, http://coldwa.st/e/blog/2017-09-09-Cabal-2-0.html states that it has different semantics. Furthermore, I still don't get the difference between the new `^>=` operator and leaving out the upper bound completely. Surely the latter can't really mean "I promise I work with every following version", in the absence of clairvoyant abilities this would be a lie. So using only `>=` without an upper bound seems to be equivalent to the new operator, I fail to see another sensible interpretation. > [...] It was designed and approved in public https://github.com/haskell/cabal/pull/3705 it was publicly posted on reddit https://www.reddit.com/r/haskell/comments/6z2gja/whats_new_in_cabalcabalinstall_20_improved/ > > And the migration plan was outlined https://github.com/haskell/cabal/issues/4899. Perhaps I'm getting a little bit old, but I consider neither reddit nor twitter as a source of serious information. Nothing was posted on the haskell, haskell-cafe or ghc-dev mailing lists about it. The only thing I was able to find was a Haskell Weekly issue pointing to the blog, having the feature buried in the middle of a multi-page item list, which is a bit indirect IMHO. > Could it be that perhaps a lot of people here don't read Cabal release information? Or follow Cabal development? [...] Serious non-aggressive question: As a developer using ''only'' stack, why should I read the Cabal release information or even follow Cabal development? Note that I am not hostile towards the project or something like that, it's just that I am not interested in it anymore because stack is a much better fit for my work. My expectation from a library developer POV would be some explicit hint about changes in the ecosystem, not about changes in some tool I don't use. > [...] The fact is, the change was not done in secret, the feature not developed in secret. The change was communicated well ahead of time and on channels that lots of you frequent. As mentioned above, I think it would have been great if this had been posted on one of the Haskell mailing lists, which I still consider ''the'' channel to get information from. Not everybody has the time and energy to read all those various (and most of the time uninformative and time sucking) communication channels which beg for your attention... :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 21:56:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 21:56:53 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.23b91e91b5af0a7f2be757f0f494b055@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 refold): I'm feeling like we're starting to go in circles here. If the only remaining concern is better UX for the users of a legacy version of Stack trying to force it into an unsupported configuration, then I can suggest the following steps: * Write a patch for Stack that makes it print a warning when a user tries to use it with a version of GHC that is not in the whitelist of supported and properly tested versions. In general, using a version of GHC with a version of Cabal earlier than the one that ships with that GHC release is not a good idea and has been known to break in the past. * Cut a new release from the 1.5 branch that includes this patch. * Add a warning to the GHC download page that tells the users of Stack < 1.6 that they should upgrade. Otherwise I fear there's a high chance that this situation will repeat itself when the users of legacy versions of Stack will try to use it with GHC 8.4 or 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 21:59:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 21:59:55 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.ba34ed3178521df5990f7fcda490f22d@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 refold): > It also affects people like me who want to parse the package descriptions of the core libraries without depending on bleeding edge Cabal features. By the same logic, `base` and `integer-gmp` shouldn't be allowed to use the latest GHC features because you might want to parse them with `haskell-src-exts`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 9 23:36:00 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Dec 2017 23:36:00 -0000 Subject: [GHC] #12372: bug: documentation for Control.Monad.guard not useful after AMP In-Reply-To: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> References: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> Message-ID: <058.e922460287d5889cef9a370f9dc65383@haskell.org> #12372: bug: documentation for Control.Monad.guard not useful after AMP -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ntc2): Fix here: https://phabricator.haskell.org/D4258 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 08:52:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 08:52:19 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.ca6d266bcb4a219d8d51199c914e8860@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 dpwiz): Replying to [comment:21 Phyx-]: > Is this not a problem of stack? Oh my... This is *exactly* the line line of reasoning that gets firebrand shaming from Linus Torvalds on LKML. I wish we were to follow it in spirit if not in, ahem, letter. No, this is not a problem of "stack" (or any other cabal-parsing tool out there). It's a problem of trust and communication. "Not my problem" is how we get into all this and still can't get out. > What I am missing here is why this is such a big deal. Even a fringe library author should constantly ask themselves: "How many people this change would affect? Am I communicating this adequately?". And here we get major revision in core libraries. > Let's fix the tools to actually adhere to what is in the `cabal-version` fields and move on. You can't just go and "fix" tools that are already deployed. Switching package version is a no-brainer for a hobby project, but will require major intervention at a company level. And that requires not only downloading a tarball, but examining all the changelogs and open issues. This is how Docker people are getting sneered upon in their "all right, a new version. go do the upgrade dance, everyone!". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 09:08:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 09:08:40 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.dcee6ae83cf599ad88ae79dd8939edad@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 refold): > You can't just go and "fix" tools that are already deployed. If legacy version users apparently are able to upgrade to new versions of GHC, why is it so hard for them to run `stack upgrade`? Already deployed stable configurations should continue to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 09:46:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 09:46:59 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.1f1a1b45c9da5371de274dfaf3463e7d@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 snoyberg): > Already deployed stable configurations should continue to work. Unfortunately that's not the case. There were two issues that popped up in parallel here: 1. The cabal file uploaded to Hackage differed from the one in the GHC release tag, and broke compat with Cabal 1.24 2. The cabal file was uploaded months after that GHC version was in circulation Any installation using GHC 8.2.1 and Stack 1.5.1 was broken when this upload occurred on December 4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 09:56:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 09:56:52 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.24260b2b04e50d33cbc333facdbb8d07@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 refold): OK, but then you want a Hackage revision and not a patch for the upstream repo? I think the former can be arranged, but then its off-topic for the GHC bug tracker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 10:47:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 10:47:29 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.6b70aeff4a9c4143eeabdd7535f7302f@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 refold): > > Already deployed stable configurations should continue to work. > Unfortunately that's not the case. And as Phyx mentioned above, GHC 8.2 is not a part of any LTS release, so IMO that statement of mine remains correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 11:55:15 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 11:55:15 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.73741a5bfc7db7b61a91ea5482ac044f@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 snoyberg): > I think the former can be arranged, but then it's off-topic for the GHC bug tracker. Where would be the right place to file issues like this? Since integer-gmp is part of GHC, I would have guessed that this is the best place to report. Perhaps the integer-gmp.cabal file needs to be modified to include an issue tracker URL? > And as Phyx mentioned above, GHC 8.2 is not a part of any LTS release, so IMO that statement of mine remains correct. I disagree; Stackage Nightly is not intended to have the same level of stability as an LTS release, but: 1. We strive for a high level of stability, and 2. In this case, a cabal file was uploaded to Hackage months after the release of GHC, which caused problems down the line. I'd like to understand the process that allowed this situation to occur, and ideally ensure that it doesn't happen in the future. We're not that far away from an LTS release including GHC 8.2. If the upload occurred in February instead, we may have been facing this bug with an LTS release. To quote myself from above: > Can you clarify how this has been resolved? The file on Hackage and in 01-index.tar.gz both appear to still have cabal-version: 2.0, preventing Stack 1.5 from building with GHC 8.2. Also, it would be helpful to know what steps have been taken to ensure it won't happen in the future, and what led to this situation in the first place. There's still not been any real answer to any of these points; Herbert simply stated that the issue has resolved and won't occur in the future. We're assuming that by resolved he means that the file was updated in the Git repo (though it doesn't address the tagged release), and still don't know what "we've taken steps that will ensure this won't be an issue in the future anymore" means. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 12:04:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 12:04:13 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.0ef8d8d50dbc14bf84503682264d6ec9@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed Comment: Thanks for everyone's feedback on this issue. However, at this point the discussion is starting to go in circles and maybe we'll just have to agree to disagree; so I'll try to summarise what I consider ''technically'' relevant for the issue at hand and deliberately ignore the politically motivated aspects^(Those can be discussed those elsewhere as the GHC issue tracker is obviously not the right venue)^ and close this ticket: - GHC 8.2.x goes together with Cabal 2.0.x (which both have been released 5 months ago, which I hardly consider bleeding edge) - The compability story of GHC/Cabal has traditionally build upon the principle that the build tool fully supports the lib:Cabal version bundled with GHC; everything else is not an officially supported configuration. period. As such, Stack-1.5.1 does not deserve the label "supports GHC 8.2". - Similarly, it's not reasonable to expect to be able to parse `.cabal` files destined for the latest GHC release with an older lib:Cabal version than the one co-developed with that GHC release, as we cannot easily predict the future. - As pointed out, this merely affects the unstable branch, i.e. Stackage Nightlies, not the stable "Long Term Support" snapshots - The issue at hand doesn't impede Stack-1.5.1 users from conveniently upgrade via `stack --upgrade` and get Stack-1.6.1 which is the first Stack release that can honestly claim to "supports GHC 8.2" (even if it took merely 5 months to get there) - Stack-1.5.1 is a lost cause anyway modern as `.cabal` files will inevitably enter the package index - Going forward, we now have https://github.com/haskell/cabal/issues/4899 in place which will prevent this from repeating in the future. This way we don't have to hold back Hackage/GHC/Cabal's development for tooling to catch up; in fact, 3rd party tooling can catch up at their own convenience, even if it takes half a year, which is not uncommon in the OSS world. I'm aware that we may have to agree to disagree on some aspects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 12:06:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 12:06:40 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.701d11ec9e8a89a3e3ca01270874fc8d@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): If you want a Hackage revision for `integer-gmp`, I think the right place to discuss that is the `hackage-trustees` bug tracker. On the topic of what steps were taken to prevent tarballs on Hackage from differing with official releases, I'll leave it to Herbert to answer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 12:13:29 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 12:13:29 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.0846b1be0a4e6f833581ea0adfd06f1a@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): BTW, can Stack < 1.6 users also work around this by reverting to a pre-Dec 04 nightly snapshot? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 14:27:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 14:27:09 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.359a0a790dca121b5f8dc46b027304ad@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by taylorfausak): Once again I am sad to see this ticket closed without any fix put in place. I am also disappointed in the behavior of GHC developers who appear to be breaking downstream tools and making absolutely no concessions to them. Needless to say, this entire experience has not been positive. I'll leave you with some assorted thoughts: - As has been stated repeatedly in this thread, one of the problems is that build plans that used to work have stopped working. Anybody trying to use a GHC >= 8.2 snapshot with Stack < 1.6.1 will be unable to do so. - `integer-gmp` does not have its own bug tracker. As I said when I opened this ticket: "I was not able to find an issue tracker for integer-gmp. Someone suggested that I open an issue here instead." I asked @hvr on Twitter where to report `integer-gmp` bugs and he said I should report them to him directly. https://twitter.com/taylorfausak/status/938243186237083649 - In my opinion, Stacakge nightlies aren't "unstable". Furthermore, knowingly breaking them is at best inconsiderate and at worst hostile. - It did not take Stack 5 months to support GHC >= 8.2. I have been using Stack with GHC 8.2 since the release candidates. Stack's support of GHC 8.2 was broken by @hvr's package uploads on December 4. - `integer-gmp`'s Cabal file has been updated on the `ghc-8.2` branch of the GHC repository, but it has not been updated on the `ghc-8.4` branch. Perhaps we'll end up in a situation where the repo doesn't match Hackage again. I find myself once again repeating the crux of this ticket: > it's frustrating that a core library is using a bleeding edge feature for basically no reason I haven't seen anyone even attempt to explain why `integer-gmp` needs to use `^>=` bounds. The argument seems to be that it can, so why not? I think "not breaking other tools" is a pretty compelling reason not to. Apparently GHC developers think breaking other tools is an acceptable price to pay for saving 8 characters in a single Cabal file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 14:42:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 14:42:47 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.368f88b78fde35a9c1798783a881e69f@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): @taylorfausak > Once again I am sad to see this ticket closed without any fix put in place. If you want a Hackage revision for `integer-gmp-1.0.1.0`, I suggested a path forward. Is there any other fix that can be applied to provide better UX for users of Stack < 1.6.1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 14:44:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 14:44:49 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.8359faba75dd17dd9e0d9f542877fe28@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by taylorfausak): Indeed, I opened a Hackage trustees issue: https://github.com/haskell- infra/hackage-trustees/issues/120 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 14:49:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 14:49:13 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.9974de861399d91222a312c829a147e9@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Great! I'm glad that we've finally found a way forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 14:54:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 14:54:45 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.6ca007de081729b879618856cedbfefa@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): > BTW, can Stack < 1.6 users also work around this by reverting to a pre- Dec 04 nightly snapshot? @taylorfausak answered that question in the `hackage-trustees`: apparently old snapshots also break. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 17:39:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 17:39:56 -0000 Subject: [GHC] #14570: Untouchable error arises from type equality, but not equivalent program with fundeps Message-ID: <050.b3eb3b2e82fc1ebf9259f6ac8f9d5ce9@haskell.org> #14570: Untouchable error arises from type equality, but not equivalent program with fundeps -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given some type definitions: {{{#!hs data A data B (f :: * -> *) data X (k :: *) }}} …and this typeclass: {{{#!hs class C k a | k -> a }}} …these (highly contrived for the purposes of a minimal example) function definitions typecheck: {{{#!hs f :: forall f. (forall k. (C k (B f)) => f k) -> A f _ = undefined g :: (forall k. (C k (B X)) => X k) -> A g = f }}} However, if we use a type family instead of a class with a functional dependency: {{{#!hs type family F (k :: *) }}} …then the equivalent function definitions fail to typecheck: {{{#!hs f :: forall f. (forall k. (F k ~ B f) => f k) -> A f _ = undefined g :: (forall k. (F k ~ B X) => X k) -> A g = f }}} {{{ • Couldn't match type ‘f0’ with ‘X’ ‘f0’ is untouchable inside the constraints: F k ~ B f0 bound by a type expected by the context: F k ~ B f0 => f0 k Expected type: f0 k Actual type: X k • In the expression: f In an equation for ‘g’: g = f }}} I read Section 5.2 of the OutsideIn(X) paper, which describes touchable and untouchable type variables, and I ''sort of'' understand what’s going on here. If I add an extra argument to `f` that pushes the choice of `f` outside the inner `forall`, then the program typechecks: {{{#!hs f :: forall f a. f a -> (forall k. (F k ~ B f) => f k) -> A f _ _ = undefined g :: forall a. X a -> (forall k. (F k ~ B X) => X k) -> A g = f }}} I don’t know if this is actually a bug—it seems entirely reasonable to me that I don’t fully understand what is going on here—but I’m stumped as to ''why'' GHC rejects this program but accepts the one involving functional dependencies. I would expect it to either accept or reject both programs, given they ''seem'' equivalent. Is this just an unfortunate infelicity of the differences between how functional dependencies and type equalities are internally solved? Or is there a deeper difference between these two programs? ,,(Note: This ticket is adapted from [https://stackoverflow.com/q/47734825/465378 this Stack Overflow question].),, -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 10 17:43:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Dec 2017 17:43:16 -0000 Subject: [GHC] #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled In-Reply-To: <050.4f7b341f8e72d76f8691291adb62b498@haskell.org> References: <050.4f7b341f8e72d76f8691291adb62b498@haskell.org> Message-ID: <065.d8604a7c2692f4d3f152203c5a5e8dac@haskell.org> #14471: Certain do blocks cause TH to barf when ApplicativeDo is enabled -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo 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 lexi.lambda): * keywords: => ApplicativeDo -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 09:05:51 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 09:05:51 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.1eae6781e7c39c373223aca3f6e72cdf@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: akio Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11706 | Differential Rev(s): Phab:D1219 Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * owner: agibiansky => akio Comment: The proposal has been approved. I'll work on the implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 09:07:40 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 09:07:40 -0000 Subject: [GHC] #14561: Panic on levity polymorphic very unsafe coerce In-Reply-To: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> References: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> Message-ID: <062.da7e8d9c5e03b371063500682111df03@haskell.org> #14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): There are lots of `unsafeCoerce#` in the GHCi debugger (`RtClosureInspect`) where we need to coerce unknown but pointed types into unpointed types like `MutVar#`. There's another instance of this kind of coercion in `newStablePtrPrimMVar` in base. I don't know of any places where we legitimately coerce between boxed and unboxed types, but I think it would be nice if we could retain the ability to do so, for debugging (e.g. printing out pointer values) & general hacking purposes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 09:19:49 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 09:19:49 -0000 Subject: [GHC] #10843: Allow do blocks without dollar signs as arguments In-Reply-To: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> References: <049.979a39a09d7a881598f53a6a6ce9bbe3@haskell.org> Message-ID: <064.1616c7a536dcd53601775260858aae77@haskell.org> #10843: Allow do blocks without dollar signs as arguments -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: akio Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11706 | Differential Rev(s): Phab:D1219, Wiki Page: | Phab:D4260 -------------------------------------+------------------------------------- Changes (by akio): * status: new => patch * differential: Phab:D1219 => Phab:D1219, Phab:D4260 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 09:45:43 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 09:45:43 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.b242d6c06beb6335dc0d1deed4f7c0e7@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: hvr => (none) * status: closed => new * resolution: fixed => Comment: For me, an important principle is this: * '''GHC should strive to make life as easy as possible for downstream tools''' One way to make life easy is never to make any changes: eternal backward-compatibility. No one is asking for that. But once we leave that extreme there's a continuous spectrum of choices, and we have to strike a balance. For example, in the language design, and library changes, we go to much effort to avoid breaking downstream libraries and tools, except when there is no alternative -- and even then we try to offer plenty of notice and workarounds. I'm not familiar with all the technical issues on this thread, but I can see that there is at least a perception by some that we have caused unnecessary breakage --- breakage that I didn't even know GHC ''could'' cause. Far from making no concessions, I think the GHC developers should be very open to making concessions to better support GHC's user community. I'll have a chat with Ben, Simon, Herbert and others, to see how best to move forward. But meanwhile I wanted to state the principle explicitly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 09:49:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 09:49:24 -0000 Subject: [GHC] #14561: Panic on levity polymorphic very unsafe coerce In-Reply-To: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> References: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> Message-ID: <062.2a86fda0fcc0a2c188cf6814188d6a5d@haskell.org> #14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't want "silly uses" of `unsafeCoerce#` to cause a panic. GHC should never panic. This ticket is about an un-saturated use of `unsafeCoerce#`; we can easily check for that. Simon M raises the question of coercing between boxed and unboxed types. That seems very dodgy: the GC now won't see that pointer. But I suppose if you want to print an address there is no other way to do so. Regardless, it's a separate point to the saturation one, which is the point of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 11:23:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 11:23:35 -0000 Subject: [GHC] #14570: Untouchable error arises from type equality, but not equivalent program with fundeps In-Reply-To: <050.b3eb3b2e82fc1ebf9259f6ac8f9d5ce9@haskell.org> References: <050.b3eb3b2e82fc1ebf9259f6ac8f9d5ce9@haskell.org> Message-ID: <065.d46f05cda0e178391b47852a33b07e0f@haskell.org> #14570: Untouchable error arises from type equality, but not equivalent program with fundeps -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Consider {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleContexts, GADTs, FunctionalDependencies #-} class C k a | k -> a data T a where MkT :: (a ~ Bool) => a -> T a data S a where MkS :: (C Bool a) => a -> S a f1 (MkT x) = x f2 (MkS x) = x }}} Here, `f2` typechecks fine, yielding `f2 :: S a -> a`. But `f1` is rejected with an untouchable-tyvar error. But, as in your emample, one has a fundep and the other has a type equality. Reason: fundeps affect only type inference, causing more unifications to happen. They do not carry evidence, and are not reflected in GHC's internal language System FC. Schrijvers et al have [https://people.cs.kuleuven.be/~tom.schrijvers/portfolio/haskell2017a.html a paper about this in at HS'17]. I haven't unpicked your example precisely but I wanted to give you a simple case in which fundeps and type equalities behave differently, by design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 11:29:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 11:29:46 -0000 Subject: [GHC] #14571: RFE: Make template-haskell cabal package require a specific version of GHC Message-ID: <047.a90f4950e390ec46d6a0551855ba57aa@haskell.org> #14571: RFE: Make template-haskell cabal package require a specific version of GHC ----------------------------------------+--------------------------- Reporter: atodorov | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------- Following a conversation on another bug tracker: https://github.com/bos/math-functions/issues/52 it looks like template-haskell is very dependent on the version of GHC being used (although the test matrix is all green at present). In the above case we're trying to use template-haskell 2.12.0.0 with GHC 8.0.2 to build another package and that fails. One of the problems is that on Fedora template-haskell is shipped separately from GHC while on Debian or with source installations it comes bundled with GHC. Is it possible to specify a requirement on the GHC version inside .cabal files? This will make it easier to track down why something isn't able to compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 11:43:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 11:43:37 -0000 Subject: [GHC] #14569: refutable let bindings produce "irrefutable pattern failed" errors In-Reply-To: <044.8464d6345485258705bd110865737bdc@haskell.org> References: <044.8464d6345485258705bd110865737bdc@haskell.org> Message-ID: <059.983316b8b31fa6d4c201862448028045@haskell.org> #14569: refutable let bindings produce "irrefutable pattern failed" errors -------------------------------------+------------------------------------- Reporter: int-e | 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: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I rather agree. Actually even 7.10 had this behaviour. Try {{{ main = let [x] = [] in print (x::Int) }}} and you get the runtime crash (with 7.10) {{{ run: T14569.hs:3:12-19: Irrefutable pattern failed for pattern [x] }}} The real point is: this talk of "irrefutable" patterns is confusing, especially since this one is manifestly refutable. Suggestion: uniformly replace the "Irrefutable pattern failed" message with "Non-exhaustive patterns in pattern binding". To do this * Kill off `Control.Exception.Base.irrefutPatError` * Kill off `MkCore.iRREFUT_PAT_ERROR_ID` and its `Name`, unique, etc. * Use `pAT_ERROR_ID` wherever we currently use `iRREFUT_PAT_ERROR_ID`. Ben, if everyone is happy, would you like to execute on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 11:49:38 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 11:49:38 -0000 Subject: [GHC] #14571: RFE: Make template-haskell cabal package require a specific version of GHC In-Reply-To: <047.a90f4950e390ec46d6a0551855ba57aa@haskell.org> References: <047.a90f4950e390ec46d6a0551855ba57aa@haskell.org> Message-ID: <062.9337b23b87f3fbf6cbe7dc7e493ca883@haskell.org> #14571: RFE: Make template-haskell cabal package require a specific version of GHC -------------------------------------+------------------------------------- Reporter: atodorov | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Indeed, upgrading `template-haskell` is almost always a bad idea. That's why `cabal-install`'s solver [considers `template-haskell` to be a non- upgradeable package]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 11:55:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 11:55:52 -0000 Subject: [GHC] #14571: RFE: Make template-haskell cabal package require a specific version of GHC In-Reply-To: <047.a90f4950e390ec46d6a0551855ba57aa@haskell.org> References: <047.a90f4950e390ec46d6a0551855ba57aa@haskell.org> Message-ID: <062.7000388612ef44781e2133b51737328b@haskell.org> #14571: RFE: Make template-haskell cabal package require a specific version of GHC -------------------------------------+------------------------------------- Reporter: atodorov | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Here's some more backstory: - https://github.com/haskell/cabal/pull/4185 - https://github.com/haskell/cabal/issues/4098 Long story short, if use a recent enough `cabal-install` this shouldn't be a problem. More generally, one long-standing idea was to have either `ghc` or `ghc- pkg` expose the information of whether a package is reinstallable dynamically to cabal, but in the past that would have been merely an aesthetical improvement, as Cabal has to encode special knowledge about GHC anyway. Also, the small set of non-reinstallable packages has been very stable over the years; so there was little incentive to do anything about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 12:32:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 12:32:31 -0000 Subject: [GHC] #14569: refutable let bindings produce "irrefutable pattern failed" errors In-Reply-To: <044.8464d6345485258705bd110865737bdc@haskell.org> References: <044.8464d6345485258705bd110865737bdc@haskell.org> Message-ID: <059.fc83f9b922f5432aacf80c5f3b55ed22@haskell.org> #14569: refutable let bindings produce "irrefutable pattern failed" errors -------------------------------------+------------------------------------- Reporter: int-e | 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: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:1 simonpj]: > I rather agree. Actually even 7.10 had this behaviour. Try > {{{ > main = let [x] = [] > in print (x::Int) > }}} > and you get the runtime crash (with 7.10) > {{{ > run: T14569.hs:3:12-19: Irrefutable pattern failed for pattern [x] > }}} The difference here is that here the pattern is actually (implicitly) irrefutable as per the Haskell 2010 language report. However, > The real point is: this talk of "irrefutable" patterns is confusing, especially since this one is manifestly refutable. This is a good point, the nomenclature is quite confusing, not just for beginners, but for anyone who isn't intimately familiar with the section on pattern matching in the Haskell report. I wouldn't be sad to see those errors replaced by ordinary incomplete pattern match errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 13:24:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 13:24:08 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.9e0cd6620339bbf9fc9c4f182857ab66@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): How much of a goal is performance at -O1? I have quite a few examples where we gain performance at -O1 but most of these disappear at -O2. Similarly tree matching improves Strict code much more than regular lazy code. However Strict code is reasonably rare so here also not sure how to rate the tradeoff. Code of the sort `nf (sum . map (\(a,b,c) -> (Aug.gen_func_1 a b c)))` where f is a random pattern mapping Enums to Ints is 2%-3% faster (average and median) when applying it to all possible enum combinations. (At -O2) with a bigger difference at -O1 or if I make the code strict. Benchmarking/Finding "normal" code where it makes a difference turned out quite hard though. * It requires a minimum complexity of the pattern to make a difference. (At least two strict arguments, and it has to be advantageous to swap the evaluation order). * Pattern matching often contributes just a fraction of the total time making it more difficult to benchmark the difference. * (Speculation): Code where patterns are performance sensitive already accounts for the current algorithm. * Most of hackage doesn't build without modification on HEAD making it very time consuming to get benchmarks building at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 13:36:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 13:36:26 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.6f4ff5abeea9bb5f8740012cfa7bbe73@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 taylorfausak): Thank you @simonpj! I am very happy to hear that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 15:30:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 15:30:39 -0000 Subject: [GHC] #14520: GHC panic (TypeInType) In-Reply-To: <051.e31c3c48e10a5a880c2a9982e47d2da1@haskell.org> References: <051.e31c3c48e10a5a880c2a9982e47d2da1@haskell.org> Message-ID: <066.2c4f311529e68f4191b14756273ff050@haskell.org> #14520: GHC panic (TypeInType) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8b36ed129652df07af22b5e2a2e57b1df8cfbbc9/ghc" 8b36ed1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8b36ed129652df07af22b5e2a2e57b1df8cfbbc9" Build only well-kinded types in type checker During type inference, we maintain the invariant that every type is well-kinded /without/ zonking; and in particular that typeKind does not fail (as it can for ill-kinded types). But TcHsType.tcInferApps was not guaranteeing this invariant, resulting in Trac #14174 and #14520. This patch fixes it, making things better -- but it does /not/ fix the program in Trac #14174 comment:5, which still crashes. So more work to be done. See Note [Ensure well-kinded types] in TcHsType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 15:30:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 15:30:39 -0000 Subject: [GHC] #14174: GHC panic with TypeInType and type family In-Reply-To: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> References: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> Message-ID: <060.6d7b8bdf5a30cfcff1fd26af664daeb2@haskell.org> #14174: GHC panic with TypeInType and type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8b36ed129652df07af22b5e2a2e57b1df8cfbbc9/ghc" 8b36ed1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8b36ed129652df07af22b5e2a2e57b1df8cfbbc9" Build only well-kinded types in type checker During type inference, we maintain the invariant that every type is well-kinded /without/ zonking; and in particular that typeKind does not fail (as it can for ill-kinded types). But TcHsType.tcInferApps was not guaranteeing this invariant, resulting in Trac #14174 and #14520. This patch fixes it, making things better -- but it does /not/ fix the program in Trac #14174 comment:5, which still crashes. So more work to be done. See Note [Ensure well-kinded types] in TcHsType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 15:50:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 15:50:50 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.1501e8a71d1b9404aec459c95846b787@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: angerman Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Changes (by George): * cc: george (removed) * cc: George (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 15:58:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 15:58:54 -0000 Subject: [GHC] #14520: GHC panic (TypeInType) In-Reply-To: <051.e31c3c48e10a5a880c2a9982e47d2da1@haskell.org> References: <051.e31c3c48e10a5a880c2a9982e47d2da1@haskell.org> Message-ID: <066.c807cf5e90302b4bf9772fc705ed9c1b@haskell.org> #14520: GHC panic (TypeInType) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T14520.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T14520.hs * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 15:59:52 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 15:59:52 -0000 Subject: [GHC] #14174: GHC panic with TypeInType and type family In-Reply-To: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> References: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> Message-ID: <060.b91cdf788a70873b514d0e7b8ca2e455@haskell.org> #14174: GHC panic with TypeInType and type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T14174.hs, T14174a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T14174.hs, T14174a Comment: Still open because I need to fix the example in comment:5 (which is `T14174a`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 17:02:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 17:02:04 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.47151380a790c2c117a232f090ee6b9b@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 gershomb): It should be noted btw that the issue on hackage-trustees was resolved with a revision of the file in question. So if this ticket is kept open for tracking broader questions then that's one thing -- but the concrete immediate issue raised seems to have been satisfactorily resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 17:06:22 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 17:06:22 -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.b779560fc167cb597d15764558f019ba@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: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Interestingly, the original program no longer panics on GHC HEAD, but the program in comment:2 still panics, this time with a slightly different panic: {{{ GHCi, version 8.5.20171205: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:56:28: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20171205 for x86_64-unknown-linux): No skolem info: [a1_a1yY[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2892:5 in ghc:TcErrors Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Is it worth adding a regression test for the original program, or should I wait until the program in comment:2 has been fixed as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 17:29:21 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 17:29:21 -0000 Subject: [GHC] #14570: Untouchable error arises from type equality, but not equivalent program with fundeps In-Reply-To: <050.b3eb3b2e82fc1ebf9259f6ac8f9d5ce9@haskell.org> References: <050.b3eb3b2e82fc1ebf9259f6ac8f9d5ce9@haskell.org> Message-ID: <065.851ceaca541a440c0dc4cf81bf027ca5@haskell.org> #14570: Untouchable error arises from type equality, but not equivalent program with fundeps -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lexi.lambda): Thanks, that’s helpful. I’m content with this ticket being closed, though I am a little interested in the fact that you say they behave differently “by design”. I have two small followup questions: 1. Is there a description of this design choice in existing literature somewhere? I imagine the difference is because fundeps are more restricted than type families, so some generality is traded away for better type inference, but I’m not ''entirely'' sure if that’s true. 2. I have not yet read the paper you linked in detail, though I will—it seems quite interesting. However, more generally, if functional dependencies ''are'' elaborated in a way similar to how type families are, will this design difference be maintained? Or will they act more similarly? I think the conversation in #11534 is likely highly relevant to my root problem here—I had some code that used functional dependencies and ended up with an ''enormous'' number of type variables that needed to be propagated around, despite the fact that many of them were determined by other type variables via functional dependency. I tried switching to type families to eliminate the need to carry around so many variables, and my program stopped typechecking (giving the untouchable error). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 17:35:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 17:35:30 -0000 Subject: [GHC] #14555: GHC Panic with TypeInType / levity polymorphism In-Reply-To: <051.f3f2f3a78aa3ad60bb5bcdd87ce66417@haskell.org> References: <051.f3f2f3a78aa3ad60bb5bcdd87ce66417@haskell.org> Message-ID: <066.9f2909004125904ab79141c1e10d33d2@haskell.org> #14555: GHC Panic with TypeInType / levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14563 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8361b2c5a9f7a00f0024f44a43b851998ae41e33/ghc" 8361b2c5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8361b2c5a9f7a00f0024f44a43b851998ae41e33" Fix SigTvs at the kind level This patch fixes two bugs in the treatment of SigTvs at the kind level: - We should always generalise them, never default them (Trac #14555, #14563) - We should check if they get unified with each other (Trac #11203) Both are described in TcHsType Note [Kind generalisation and SigTvs] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 17:35:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 17:35:30 -0000 Subject: [GHC] #14563: GHC Panic with TypeInType / levity polymorphism In-Reply-To: <051.7f7c79248bc900573fbeefcc42311033@haskell.org> References: <051.7f7c79248bc900573fbeefcc42311033@haskell.org> Message-ID: <066.736d32f48318857e2af973497d4c1d1f@haskell.org> #14563: GHC Panic with TypeInType / levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14555 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8361b2c5a9f7a00f0024f44a43b851998ae41e33/ghc" 8361b2c5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8361b2c5a9f7a00f0024f44a43b851998ae41e33" Fix SigTvs at the kind level This patch fixes two bugs in the treatment of SigTvs at the kind level: - We should always generalise them, never default them (Trac #14555, #14563) - We should check if they get unified with each other (Trac #11203) Both are described in TcHsType Note [Kind generalisation and SigTvs] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 17:35:30 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 17:35:30 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.1377418a5ad5b4332c9005a80c560dfe@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8361b2c5a9f7a00f0024f44a43b851998ae41e33/ghc" 8361b2c5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8361b2c5a9f7a00f0024f44a43b851998ae41e33" Fix SigTvs at the kind level This patch fixes two bugs in the treatment of SigTvs at the kind level: - We should always generalise them, never default them (Trac #14555, #14563) - We should check if they get unified with each other (Trac #11203) Both are described in TcHsType Note [Kind generalisation and SigTvs] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 19:26:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 19:26:31 -0000 Subject: [GHC] #14545: -prof causes -N to default to 1 In-Reply-To: <046.7d4ffefef4202d01a6900c8ce3a34ece@haskell.org> References: <046.7d4ffefef4202d01a6900c8ce3a34ece@haskell.org> Message-ID: <061.46e5aba9d68778eec81bf8212ea21be7@haskell.org> #14545: -prof causes -N to default to 1 -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4245 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4bfff7a507b5807736e9c6ce9814a9cfa60faeff/ghc" 4bfff7a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4bfff7a507b5807736e9c6ce9814a9cfa60faeff" rts: Don't default to single capability when profiled This was presumably a vestige of the days when the profiled RTS couldn't run threaded. Fixes #14545. Test Plan: simonmar Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14545 Differential Revision: https://phabricator.haskell.org/D4245 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 19:26:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 19:26:31 -0000 Subject: [GHC] #12372: bug: documentation for Control.Monad.guard not useful after AMP In-Reply-To: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> References: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> Message-ID: <058.5b49abc2cf097681747e20cde14253d4@haskell.org> #12372: bug: documentation for Control.Monad.guard not useful after AMP -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6847c6bf5777eaf507f1cef28c1fc75a2c68bdef/ghc" 6847c6b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6847c6bf5777eaf507f1cef28c1fc75a2c68bdef" Improve Control.Monad.guard and Control.Monad.MonadPlus docs This fixes Issue #12372: documentation for Control.Monad.guard not useful after AMP. Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4258 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 19:26:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 19:26:31 -0000 Subject: [GHC] #13296: stat() calls can block Haskell runtime In-Reply-To: <042.f957a412d3d44b27155966b76103fe42@haskell.org> References: <042.f957a412d3d44b27155966b76103fe42@haskell.org> Message-ID: <057.faa2542fb64d1069454cea5941cfe08c@haskell.org> #13296: stat() calls can block Haskell runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cafe98345cb5d4b11f2059d60d2f20e976ef4f2a/ghc" cafe9834/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cafe98345cb5d4b11f2059d60d2f20e976ef4f2a" Always use the safe open() call open() can sometimes take a long time, for example on NFS or FUSE filesystems. We recently had a case where open() was taking multiple seconds to return for a (presumably overloaded) FUSE filesystem, which blocked GC and caused severe issues. Test Plan: validate Reviewers: niteria, bgamari, nh2, hvr, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13296 Differential Revision: https://phabricator.haskell.org/D4239 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 19:26:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 19:26:31 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.16f54f86c7e11282367adb0e14f6046a@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: dfeuer Type: bug | Status: patch Priority: highest | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4123 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"708ed9ca4dbf372817fe84a2fe486940123bddfb/ghc" 708ed9c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="708ed9ca4dbf372817fe84a2fe486940123bddfb" Allow users to ignore optimization changes * Add a new flag, `-fignore-optim-changes`, allowing them to avoid recompilation if the only changes are to the `-O` level or to flags controlling optimizations. * When `-fignore-optim-changes` is *off*, recompile when optimization flags (e.g., `-fno-full-laziness`) change. Previously, we ignored these unconditionally when deciding whether to recompile a module. Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: duog, carter, simonmar, rwbarton, thomie GHC Trac Issues: #13604 Differential Revision: https://phabricator.haskell.org/D4123 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 19:56:37 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 19:56:37 -0000 Subject: [GHC] #14545: -prof causes -N to default to 1 In-Reply-To: <046.7d4ffefef4202d01a6900c8ce3a34ece@haskell.org> References: <046.7d4ffefef4202d01a6900c8ce3a34ece@haskell.org> Message-ID: <061.6f0fd6902ef130d88f22f3e20b6d0186@haskell.org> #14545: -prof causes -N to default to 1 -------------------------------------+------------------------------------- Reporter: gelisam | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4245 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 19:59:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 19:59:19 -0000 Subject: [GHC] #13296: stat() calls can block Haskell runtime In-Reply-To: <042.f957a412d3d44b27155966b76103fe42@haskell.org> References: <042.f957a412d3d44b27155966b76103fe42@haskell.org> Message-ID: <057.e5fc0146bcc5da8daa696e2035e82be2@haskell.org> #13296: stat() calls can block Haskell runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): We still need to do this for the remaining syscalls. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 20:00:24 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 20:00:24 -0000 Subject: [GHC] #13604: ghci no longer loads dynamic .o files by default if they were built with -O In-Reply-To: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> References: <045.626a6b40d9101c93e2935653ef7e4668@haskell.org> Message-ID: <060.61a68d1d734d84ba21f057e2087c3d0e@haskell.org> #13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: dfeuer Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1-rc1 Resolution: fixed | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4123 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.2.3 => 8.4.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 11 20:42:36 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Dec 2017 20:42:36 -0000 Subject: [GHC] #12001: RFC: Add pattern synonyms to base In-Reply-To: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> References: <051.a75667959d8601b2c7daa93e0c0a6683@haskell.org> Message-ID: <066.2f7881c7e6c82e01bcbe5902604a138a@haskell.org> #12001: RFC: Add pattern synonyms to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > Since we have pattern synonyms it's worth considering if some belong in > base: > > [https://hackage.haskell.org/package/lens-4.14/docs/Data-Complex- > Lens.html Data.Complex.Lens] contains patterns that could be defined in > base, here are some more suggestions: > > === Data.Array === > {{{#!hs > pattern ArrayIx :: Ix i => (i, i) -> [(i, e)] -> Array i e > pattern ArrayIx low'high xs <- ((\arr -> (bounds arr, assocs arr)) -> > (low'high, xs)) > where ArrayIx low'high xs = array low'high xs > }}} > > === Data.Bits === > {{{#!hs > pattern ZeroBits :: (Eq a, Bits a) => a > pattern ZeroBits <- ((== zeroBits) -> True) > where ZeroBits = zeroBits > > pattern BitSize :: Bits a => Int -> a > pattern BitSize n <- (bitSizeMaybe -> Just n) > > pattern Signed :: Bits a => a > pattern Signed <- (isSigned -> True) > > pattern Unsigned :: Bits a => a > pattern Unsigned <- (isSigned -> False) > > pattern PopCount :: Bits a => Int -> a > pattern PopCount n <- (popCount -> n) > }}} > > === Data.Char === > {{{#!hs > pattern ControlChar :: Char > pattern ControlChar <- (isControl -> True) > > pattern SpaceChar :: Char > pattern SpaceChar <- (isSpace -> True) > }}} > > === Data.Complex === > {{{#!hs > import Data.Complex (Complex, conjugate, polar, mkPolar) > import qualified Data.Complex as C > > pattern Conjugate :: Num a => Complex a -> Complex a > pattern Conjugate a <- (conjugate -> a) > where Conjugate a = conjugate a > > pattern Polar :: RealFloat a => a -> a -> Complex a > pattern Polar m theta <- (polar -> (m, theta)) > where Polar m theta = mkPolar m theta > > -- See https://github.com/ekmett/lens/issues/653 > pattern Real :: Num a => a -> Complex a > pattern Real r <- r C.:+ _ > where Real r = r C.:+ 0 > > pattern Imaginary :: Num a => a -> Complex a > pattern Imaginary i <- _ C.:+ i > where Imaginary i = 0 C.:+ i > > pattern (:+) :: a -> a -> Complex a > pattern (:+) { realPart, imagPart } = realPart C.:+ imagPart > }}} > > === GHC.Float === > {{{#!hs > pattern NegativeZero :: RealFloat a => a > pattern NegativeZero <- (isNegativeZero -> True) > where NegativeZero = -0 > > pattern Denormalized :: RealFloat a => a > pattern Denormalized <- (isDenormalized -> True) > > pattern NaN :: RealFloat a => a > pattern NaN <- (isNaN -> True) > where NaN = 0 / 0 > > -- How ever negative infinity is handled > pattern Infinity :: RealFloat a => a > pattern Infinity <- ((== 1 / 0) -> True) > where Infinity = 1 / 0 > }}} New description: Since we have pattern synonyms it's worth considering if some belong in base: [https://hackage.haskell.org/package/lens-4.14/docs/Data-Complex-Lens.html Data.Complex.Lens] contains patterns that could be defined in base, here are some more suggestions: === Data.Array === {{{#!hs pattern ArrayIx :: Ix i => (i, i) -> [(i, e)] -> Array i e pattern ArrayIx low'high xs <- ((\arr -> (bounds arr, assocs arr)) -> (low'high, xs)) where ArrayIx low'high xs = array low'high xs }}} === Data.Bits === {{{#!hs pattern ZeroBits :: (Eq a, Bits a) => a pattern ZeroBits <- ((== zeroBits) -> True) where ZeroBits = zeroBits pattern BitSize :: Bits a => Int -> a pattern BitSize n <- (bitSizeMaybe -> Just n) pattern Signed :: Bits a => a pattern Signed <- (isSigned -> True) pattern Unsigned :: Bits a => a pattern Unsigned <- (isSigned -> False) pattern PopCount :: Bits a => Int -> a pattern PopCount n <- (popCount -> n) }}} === Data.Char === {{{#!hs pattern ControlChar :: Char pattern ControlChar <- (isControl -> True) pattern SpaceChar :: Char pattern SpaceChar <- (isSpace -> True) }}} === Data.Complex === {{{#!hs import Data.Complex (Complex, conjugate, polar, mkPolar) import qualified Data.Complex as C pattern Conjugate :: Num a => Complex a -> Complex a pattern Conjugate a <- (conjugate -> a) where Conjugate a = conjugate a pattern Polar :: RealFloat a => a -> a -> Complex a pattern Polar m theta <- (polar -> (m, theta)) where Polar m theta = mkPolar m theta -- See https://github.com/ekmett/lens/issues/653 pattern Real :: Num a => a -> Complex a pattern Real r <- r C.:+ _ where Real r = r C.:+ 0 pattern Imaginary :: Num a => a -> Complex a pattern Imaginary i <- _ C.:+ i where Imaginary i = 0 C.:+ i pattern (:+) :: a -> a -> Complex a pattern (:+) { realPart, imagPart } = realPart C.:+ imagPart }}} === GHC.Float === {{{#!hs pattern NegativeZero :: RealFloat a => a pattern NegativeZero <- (isNegativeZero -> True) where NegativeZero = -0 pattern Denormalized :: RealFloat a => a pattern Denormalized <- (isDenormalized -> True) pattern NaN :: RealFloat a => a pattern NaN <- (isNaN -> True) where NaN = 0 / 0 -- How ever negative infinity is handled pattern Infinity :: RealFloat a => a pattern Infinity <- (isInfinite -> True) where Infinity = 1 / 0 }}} Used [https://github.com/cchalmers/optical/blob/a85484ad23a7f4d6b5da1dcb78781ea9c488a246/src/Optical/Patterns.hs#L37 here] -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 00:54:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 00:54:17 -0000 Subject: [GHC] #9669: Long compile time/high memory usage for modules with many deriving clauses In-Reply-To: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> References: <047.d2e05ff2cf33283bc3e60e65402ecabf@haskell.org> Message-ID: <062.ad0690075ba40cc46c925bccbdce6a4c@haskell.org> #9669: Long compile time/high memory usage for modules with many deriving clauses -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: deriving-perf Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by steshaw): * cc: steshaw (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 02:06:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 02:06:12 -0000 Subject: [GHC] #12372: bug: documentation for Control.Monad.guard not useful after AMP In-Reply-To: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> References: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> Message-ID: <058.6143305d6ec9e1a2f94a6e7658096ee4@haskell.org> #12372: bug: documentation for Control.Monad.guard not useful after AMP -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * status: infoneeded => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 02:43:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 02:43:36 -0000 Subject: [GHC] #14570: Untouchable error arises from type equality, but not equivalent program with fundeps In-Reply-To: <050.b3eb3b2e82fc1ebf9259f6ac8f9d5ce9@haskell.org> References: <050.b3eb3b2e82fc1ebf9259f6ac8f9d5ce9@haskell.org> Message-ID: <065.36b857097b011e989c00fc4b8ffe06a8@haskell.org> #14570: Untouchable error arises from type equality, but not equivalent program with fundeps -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) Comment: At the least, this is a rather poor error message. I don't think it's terribly reasonable to expect users to read and understand near-cutting- edge papers about type inference in order to understand what they've done wrong and how they might fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 09:08:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 09:08:09 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.40242614d1f3f0d369bf43b56388ea40@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): When evaluating when it's okay to replace one exception by another, it might be worth considering the ideas laid out in Exceptions/PreciseExceptions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 09:08:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 09:08:27 -0000 Subject: [GHC] #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" In-Reply-To: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> References: <047.8c12540f1c55383efff9bbd37be2e217@haskell.org> Message-ID: <062.df180602e1e45b78905be026cf1cd139@haskell.org> #14201: Implement ideas from "Compiling Pattern Matching to Good Decision Trees" -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 09:11:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 09:11:38 -0000 Subject: [GHC] #14569: refutable let bindings produce "irrefutable pattern failed" errors In-Reply-To: <044.8464d6345485258705bd110865737bdc@haskell.org> References: <044.8464d6345485258705bd110865737bdc@haskell.org> Message-ID: <059.85b55a6c07d15a38e38f92607e364e2c@haskell.org> #14569: refutable let bindings produce "irrefutable pattern failed" errors -------------------------------------+------------------------------------- Reporter: int-e | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => dfeuer Comment: This sounds like something I can probably manage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 09:19:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 09:19:48 -0000 Subject: [GHC] #14569: refutable let bindings produce "irrefutable pattern failed" errors In-Reply-To: <044.8464d6345485258705bd110865737bdc@haskell.org> References: <044.8464d6345485258705bd110865737bdc@haskell.org> Message-ID: <059.8ad8660024ffa4c36f4a875f4abe302e@haskell.org> #14569: refutable let bindings produce "irrefutable pattern failed" errors -------------------------------------+------------------------------------- Reporter: int-e | Owner: dfeuer Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4261 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D4261 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 09:29:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 09:29:14 -0000 Subject: [GHC] #14563: GHC Panic with TypeInType / levity polymorphism In-Reply-To: <051.7f7c79248bc900573fbeefcc42311033@haskell.org> References: <051.7f7c79248bc900573fbeefcc42311033@haskell.org> Message-ID: <066.dadc0ed2cce664008b34c53f4abb8a15@haskell.org> #14563: GHC Panic with TypeInType / levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/polykinds/T14563 Blocked By: | Blocking: Related Tickets: #14555 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => testsuite/tests/polykinds/T14563 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 09:30:22 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 09:30:22 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.eceed8b5fbd78a7946e3fdaa9ace026d@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11203 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T11203 * resolution: => fixed Comment: Finally fixed! {{{ T11203.hs:7:24: error: • Couldn't match ‘k1’ with ‘k2’ • In the data declaration for ‘Q’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 09:30:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 09:30:52 -0000 Subject: [GHC] #14555: GHC Panic with TypeInType / levity polymorphism In-Reply-To: <051.f3f2f3a78aa3ad60bb5bcdd87ce66417@haskell.org> References: <051.f3f2f3a78aa3ad60bb5bcdd87ce66417@haskell.org> Message-ID: <066.d50f199f3dce87a4e712b20079afd2b8@haskell.org> #14555: GHC Panic with TypeInType / levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T14555 Blocked By: | Blocking: Related Tickets: #14563 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T14555 * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 09:33:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 09:33:56 -0000 Subject: [GHC] #14558: Unable to parse integer-gmp's Cabal file In-Reply-To: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> References: <051.e08a5dbae429c208eedde91fcae4fd7a@haskell.org> Message-ID: <066.5d5cf736c7d8d19e3c1d4164495ef6d8@haskell.org> #14558: Unable to parse integer-gmp's Cabal file -------------------------------------+------------------------------------- Reporter: taylorfausak | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 dpwiz): What if there was a dedicated place for announcing breaking changes, gathering feedback, stating blockers and prompting to hurry? I read a lot of arguments on the net stating "they said; no we didn't; yes but..." etc. Maybe a public audit trail for decisions like this will help to prevent good portion of the drama. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 10:08:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 10:08:09 -0000 Subject: [GHC] #14572: Document for writing GHC-based compiler Message-ID: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> #14572: Document for writing GHC-based compiler -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 10:41:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 10:41:43 -0000 Subject: [GHC] #14573: runtimeRepPrimRep panic when building GHC 8.2.2 with -fprof-auto-exported Message-ID: <044.33b01da6aa352a38de3a4fb870652e7d@haskell.org> #14573: runtimeRepPrimRep panic when building GHC 8.2.2 with -fprof-auto-exported -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building GHC 8.2.2 with the following options in `build.mk`, the stage1 compiler panics when building `StgCmmMonad.p_o` {{{ SRC_HC_OPTS = -O -H64m GhcStage1HcOpts = -O GhcStage2HcOpts = -O2 -fprof-auto-exported GhcLibHcOpts = -O2 -fprof-auto-exported BUILD_PROF_LIBS = YES }}} {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (a_12 :: TYPE k0_10) k0_10 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} (tested on x86_64 linux with GHC 8.0.2 as bootstrap compiler) The GHC 8.4 branch doesn't appear to do this, but I'm not sure if the underlying problem has been fixed. Compiling only the `StgCmmMonad` module with `-fprof-auto-exported` does not trigger the panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 11:12:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 11:12:01 -0000 Subject: [GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble Message-ID: <044.13612547bcec0532b940b49a41a2177d@haskell.org> #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- 64 bit GHC has 64 bit Unique values, but they don't fit in a `template- haskell` `NameU` when cross-compiling to a 32 bit target. In theory we can support Template Haskell in this situation with `-fexternal-interpreter` (and the earlier GHCJS implementation), but when the target cannot represent GHC's uniques in an `Int`, things go wrong: from `Language.Haskell.TH.Syntax`: {{{#!hs type Uniq = Int }}} I think we can fix this for now by changing the synonym to `type Uniq = Int64` (or even `type Uniq = Integer`), making the `template-haskell` `Uniq` at least as big as the GHC `Unique` in practice. This requires a change in `DsMeta`. the uses of `Int` below should really be changed to `Uniq` {{{#!hs data NameFlavour = NameS -- ^ An unqualified name; dynamically bound | NameQ ModName -- ^ A qualified name; dynamically bound | NameU !Int -- ^ A unique local name | NameL !Int -- ^ Local name bound outside of the TH AST | NameG NameSpace PkgName ModName -- ^ Global name bound outside of the TH AST: -- An original name (occurrences only, not binders) -- Need the namespace too to be sure which -- thing we are naming deriving ( Data, Eq, Ord, Show, Generic ) }}} {{{#!hs -- Global variable to generate unique symbols counter :: IORef Int {-# NOINLINE counter #-} counter = unsafePerformIO (newIORef 0) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 12:24:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 12:24:08 -0000 Subject: [GHC] #14575: ghc: panic! (the 'impossible' happened) Message-ID: <044.af526f67dba2de1bc69f8e26cf6df5f5@haskell.org> #14575: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Pauly | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.2 Keywords: template | Operating System: Linux haskell | Architecture: x86_64 | Type of failure: GHC doesn't work (amd64) | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I got: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] spec_a86Q :: t_a86P[tau:1] (CHoleCan: spec)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This happens after adding of this call in test file (called SimpleTaggingSpec.hs): {{{#!hs $(shrinkEnumTag AnyJT) }}} Implementation of this ''shrinkEnumTag'' looks: {{{#!hs shrinkEnumTag :: forall a. (Data a, IsTag a) => a -> Q [Dec] shrinkEnumTag enm = do let dt = dataTypeOf enm ty = mkName $ dataTypeName dt tickAdd = (++"'") nameWith f = mkName . f . show derivs' = ConT . mkName <$> ["Eq", "Ord", "Enum"] mkShow tn tn' = [d|instance Show $(conT tn') where show a = show $ (toEnum $ fromEnum a :: $(conT tn))|] AlgRep algCs <- pure $ dataTypeRep dt let algCs' = [mkName $ show c | c <- algCs, fromConstr c /= (anyTag::a)] newCs = [NormalC (nameWith tickAdd n) [] | n <- algCs'] TyConI tyCon <- reify ty decs <- case tyCon of DataD _cxt _nm tyVars _mbKind _cs _derivs -> do let ty' = nameWith tickAdd ty when (null newCs) $ fail "Can't find normal constructors" showInst <- mkShow ty ty' return $ [DataD [] ty' tyVars Nothing newCs derivs'] ++ showInst _ -> fail "expected Enum-like data type" return decs }}} If I add this call in not-test module, all is good, compilation is fine, application works. I use GHC 8.0.2, this happened with LTS-8.13 and LTS-9.18. Project uses stack tool. OS is Linux OpenSUSE Tumbleweed. I updated stack to the last version (1.6.1) but this did not help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 12:31:01 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 12:31:01 -0000 Subject: [GHC] #14575: ghc: panic! (the 'impossible' happened) In-Reply-To: <044.af526f67dba2de1bc69f8e26cf6df5f5@haskell.org> References: <044.af526f67dba2de1bc69f8e26cf6df5f5@haskell.org> Message-ID: <059.81bfb65a6b076a6c3888828cc0d3f35b@haskell.org> #14575: ghc: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Pauly | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: template | haskell Operating System: Linux | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: Thanks. Almost certainly a dup of #13106; fixed in 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 12:34:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 12:34:11 -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.6b7b84a7bb6da75b9b656e77b949a8ca@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire Comment: By all means add a regression test, thanks. The more the better. Richard is actively working on a "solveEqualities" patch that will (I hope) fix this bug among many others (e.g. #14066) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 15:20:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 15:20:23 -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.28cb2db5f1b258a8c1112825a41bd9ca@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13877 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"be1ca0e439e9d26107c7d82fe6e78b64ee6320a9/ghc" be1ca0e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be1ca0e439e9d26107c7d82fe6e78b64ee6320a9" Add regression test for #14040 This adds a regression test for the original program in #14040. This does not fix #14040 entirely, though, as the program in https://ghc.haskell.org/trac/ghc/ticket/14040#comment:2 still panics, so there is more work to be done there. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 15:52:36 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 15:52:36 -0000 Subject: [GHC] #13210: Can't run terminfo code in GHCi on Windows In-Reply-To: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> References: <050.4b925adbb480c97661debe69ca3ada51@haskell.org> Message-ID: <065.db20063de5f824179efbff71bb21b2bd@haskell.org> #13210: Can't run terminfo code in GHCi on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3154 Wiki Page: | Phab:D3155 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.2.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 15:55:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 15:55:57 -0000 Subject: [GHC] #14573: runtimeRepPrimRep panic when building GHC 8.2.2 with -fprof-auto-exported In-Reply-To: <044.33b01da6aa352a38de3a4fb870652e7d@haskell.org> References: <044.33b01da6aa352a38de3a4fb870652e7d@haskell.org> Message-ID: <059.cb6e7ea07dd6a873e9e43a416d3f7379@haskell.org> #14573: runtimeRepPrimRep panic when building GHC 8.2.2 with -fprof-auto-exported -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13233 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13233 Comment: Indeed. Now that I bother to search Trac, it looks like this was already reported as #13233, so I'll close this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 15:56:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 15:56:45 -0000 Subject: [GHC] #13233: typePrimRep panic while compiling GHC with profiling In-Reply-To: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> References: <046.6aee0fed3c9ac84b9f07b89c83d69fc3@haskell.org> Message-ID: <061.40cb0fdfb297872d2fcc91da72bb8429@haskell.org> #13233: typePrimRep panic while compiling GHC with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | codeGen/should_fail/T13233 Blocked By: | Blocking: Related Tickets: #14123, #14573 | Differential Rev(s): Phab:D3490 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #14123 => #14123, #14573 Comment: luite reports in #14573 that this doesn't happen on the GHC 8.4 branch... has this been fixed somehow? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 15:59:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 15:59:27 -0000 Subject: [GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble In-Reply-To: <044.13612547bcec0532b940b49a41a2177d@haskell.org> References: <044.13612547bcec0532b940b49a41a2177d@haskell.org> Message-ID: <059.291143fe291de5982c869ea3fb560ac9@haskell.org> #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That seems like a reasonable proposal. Out of curiosity, when you say: Replying to [ticket:14574 luite]: > but when the target cannot represent GHC's uniques in an `Int`, things go wrong: Do you mean "things go wrong" when trying to build a program that uses Template Haskell? And if so, do you have an example demonstrating what goes wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 17:05:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 17:05:47 -0000 Subject: [GHC] #14572: Document for writing GHC-based compiler In-Reply-To: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> References: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> Message-ID: <059.f0a4181391038b64ad3fa56e92500741@haskell.org> #14572: Document for writing GHC-based compiler -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Does wiki:Commentary/Compiler/API help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 17:07:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 17:07:26 -0000 Subject: [GHC] #14409: Split GHC(-API) into multiple packages In-Reply-To: <046.310c45ec4dd3ba940f204de806999eed@haskell.org> References: <046.310c45ec4dd3ba940f204de806999eed@haskell.org> Message-ID: <061.468c649f6a9e87c72c8c6fe980d4bb56@haskell.org> #14409: Split GHC(-API) into multiple packages -------------------------------------+------------------------------------- Reporter: Lemming | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record: [[ImplementingTreesThatGrow|Trees That Grow]] can be viewed as a first step in this direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 18:04:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 18:04:06 -0000 Subject: [GHC] #14126: Two Failing Test Cases in HEAD In-Reply-To: <050.7306a564dab2bd2e8535311b3eb31a2e@haskell.org> References: <050.7306a564dab2bd2e8535311b3eb31a2e@haskell.org> Message-ID: <065.38ed1b05857ebdbe46fd5abaf2b6dd49@haskell.org> #14126: Two Failing Test Cases in HEAD -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14024 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #14024 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 18:05:13 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 18:05:13 -0000 Subject: [GHC] #14126: Two Failing Test Cases in HEAD In-Reply-To: <050.7306a564dab2bd2e8535311b3eb31a2e@haskell.org> References: <050.7306a564dab2bd2e8535311b3eb31a2e@haskell.org> Message-ID: <065.107d77d5dea2264c38435fbf18b49a69@haskell.org> #14126: Two Failing Test Cases in HEAD -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14024 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => duplicate Comment: This looks like a duplicate of #14024. If you disagree, feel free to reopen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 12 18:12:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Dec 2017 18:12:05 -0000 Subject: [GHC] #14024: typechecker tests T13594 T13822 tc269 T13780c failing in devel2 flavour In-Reply-To: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> References: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> Message-ID: <058.9552568ca33c4e87f99c76c361d9fecb@haskell.org> #14024: typechecker tests T13594 T13822 tc269 T13780c failing in devel2 flavour -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I just finished bisecting the T13822 failure. It appears to have been introduced by 1eec1f21268af907f59b5d5c071a9a25de7369c7 (Another major constraint-solver refactoring). In #14126 (which I just closed as a duplicate of this ticket), Richard indicates that T13822 is fixed by Phab:D3848 (Fix #12919 by making the flattener homogeneous). I wouldn't have bothered bisecting if I'd seen that note before ... oh well. Perhaps Richard can comment on the status of that differential. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 00:33:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 00:33:07 -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.3a330a332b0d1320ad911a9d41be0f0f@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 pggiarrusso): > Type synonyms are top level/global because all types and classes are. Otherwise type solving might be incoherent. -1 from me. Type synonyms can be expanded, and using a synonym or its expansion should not affect coherence of type class resolution (what’s solving?). > Please explain why you couldn't declare the synonym at top level, as usual. Do you want the synonym to work wherever this module gets imported into? How will that go if it's nested? > Please provide a more focussed example. Line 202 of 707. Do you really need 707 lines to explain the need? Looking at lines 189 to 207: the RHS of the type synonym refers to lexically scoped variables, so the poster has to lambda-lift the type synonym. That’s similarly annoying to any other use of lambda-lifting. Arguably, the poster is just asking for something with the semantics of let, but for types (ignoring the difference between let and where). I’d guess you’d want both, and you’ll probably get both in general in DependentHaskell. A local type synonym should arguably be expanded, and only be in scope in its where clause, or in general in the lexical scope of the declaration. Probably the synonym should be expanded when exiting the synonym’s scope, so that error messages for type errors in the block use the synonym and not its expansion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 01:07:42 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 01:07:42 -0000 Subject: [GHC] #14409: Split GHC(-API) into multiple packages In-Reply-To: <046.310c45ec4dd3ba940f204de806999eed@haskell.org> References: <046.310c45ec4dd3ba940f204de806999eed@haskell.org> Message-ID: <061.950888e3779c60c251371e7a1ba58088@haskell.org> #14409: Split GHC(-API) into multiple packages -------------------------------------+------------------------------------- Reporter: Lemming | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): [https://github.com/ghc-proposals/ghc-proposals/pull/57 Hierarchical modules] too -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 01:22:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 01:22:53 -0000 Subject: [GHC] #14448: CircleCI can't build on OS X In-Reply-To: <046.1aebf3557dc17190496a1d6ce081057b@haskell.org> References: <046.1aebf3557dc17190496a1d6ce081057b@haskell.org> Message-ID: <061.57046bb2df4ae6f3f5a164317df3fb1e@haskell.org> #14448: CircleCI can't build on OS X -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 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 chak): * status: new => closed * resolution: => fixed Comment: This has been fixed now by CircleCI. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 04:09:50 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 04:09:50 -0000 Subject: [GHC] #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints In-Reply-To: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> References: <050.ec57930d289b450ca4924847bd0d6061@haskell.org> Message-ID: <065.d8f3928baa363b9798ef23cbc4a59f84@haskell.org> #14273: Typed holes' "valid substitutions" suggestions are oblivious to type class constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #9091, #9479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mentheta): * cc: mentheta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 04:10:23 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 04:10:23 -0000 Subject: [GHC] #9091: print and/or apply constraints when showing info for typed holes In-Reply-To: <047.d95c0766523b082befd3b58cd013d678@haskell.org> References: <047.d95c0766523b082befd3b58cd013d678@haskell.org> Message-ID: <062.a945d4e94955ccb4c00d57da37ee484e@haskell.org> #9091: print and/or apply constraints when showing info for typed holes -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9479, #14273 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mentheta): * cc: mentheta (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 04:52:31 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 04:52:31 -0000 Subject: [GHC] #14024: typechecker tests T13594 T13822 tc269 T13780c failing in devel2 flavour In-Reply-To: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> References: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> Message-ID: <058.188fbd3ee4e779d79234e916e73dc1dd@haskell.org> #14024: typechecker tests T13594 T13822 tc269 T13780c failing in devel2 flavour -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It's held up by significant performance issues that have not had time to be worked out. I could rebase and commit, but the patch causes a 10%-ish compile-time slowdown to type-family-heavy code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 07:23:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 07:23:39 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.3987f9ac05db4d2e2767cca51dacc31b@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johndoe): Well, I tried to modify `specs` directly, but project failed to build: I've got messagebox that `setup.exe` crashed. That was on my local machine, but the same you can see on appveyor: https://ci.appveyor.com/project/johnd0e/pandoc/build/1.0.79 I am not sure, maybe my `specs` file is not good: https://github.com/johnd0e/pandoc/blob/master/specs But it worked well with other project (not GHC). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 07:30:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 07:30:21 -0000 Subject: [GHC] #14576: Internal error when compiling TH code with profiling on Windows Message-ID: <044.c2e93e4cd6fa3bc5d229bcd4603864fa@haskell.org> #14576: Internal error when compiling TH code with profiling on Windows -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using the GHC API with this minimal example, compiled with profiling enabled: {{{#!hs module Main where import GHC import GHC.Paths ( libdir ) main = runGhc (Just libdir) $ do env <- getSession dflags <- getSessionDynFlags setSessionDynFlags dflags target <- guessTarget "A.hs" Nothing setTargets [target] load LoadAllTargets }}} Invoking the main executable: {{{ testprof }}} While A.hs contains a TH splice: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module A where $(return []) }}} The compiler crashes: {{{ testprof.exe: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 10e6109d0 for .text (GHC version 8.2.1 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} The walkaround is to use -fexternal-interpreter, in that case, the crash does not happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 07:34:32 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 07:34:32 -0000 Subject: [GHC] #14576: Internal error when compiling TH code with profiling on Windows In-Reply-To: <044.c2e93e4cd6fa3bc5d229bcd4603864fa@haskell.org> References: <044.c2e93e4cd6fa3bc5d229bcd4603864fa@haskell.org> Message-ID: <059.833f06fb837d0ed1fd157937b768a23d@haskell.org> #14576: Internal error when compiling TH code with profiling on Windows -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.1 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 lazac): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 07:38:41 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 07:38:41 -0000 Subject: [GHC] #14577: Internal error when linker is initialized with -fexternal-interpreter set when compiling TH code with profiling Message-ID: <044.189288697c314b3d5444ddfc9acdb97b@haskell.org> #14577: Internal error when linker is initialized with -fexternal-interpreter set when compiling TH code with profiling -------------------------------------+------------------------------------- Reporter: lazac | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14576 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When using the GHC API with this minimal example, using the -fexternal- interpreter option, compiled with profiling enabled: {{{#!hs import GHC import Control.Monad.IO.Class import GHC.Paths ( libdir ) import DynFlags import Linker main = runGhc (Just libdir) $ do env <- getSession dflags <- getSessionDynFlags liftIO $ initDynLinker env setSessionDynFlags (setGeneralFlag' Opt_ExternalInterpreter dflags) target <- guessTarget "A.hs" Nothing setTargets [target] load LoadAllTargets }}} Invoking the main executable: {{{ testprof }}} While A.hs contains a TH splice: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module A where $(return []) }}} The compiler crashes: {{{ Access violation in generated code when writing 0000000000000024 }}} Probably I'm misusing the API in this example, but the way it crashes is suspicious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 09:40:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 09:40:56 -0000 Subject: [GHC] #14556: Core Lint error: Ill-kinded result in coercion In-Reply-To: <051.0e355f10cac8235c3846ef7abeef362e@haskell.org> References: <051.0e355f10cac8235c3846ef7abeef362e@haskell.org> Message-ID: <066.3b9c78643b6c6e8d1a889d6d58da358f@haskell.org> #14556: Core Lint error: Ill-kinded result in coercion -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14554 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think this is another example of the bugs surrounding "flattened types have flattened kinds". What is happening is this. In the RHS of `zero` we get a constraint {{{ [W} (alpha :: TYPE r) ~ TyRep X a -> (IT a |> ax_IK) where ax_IK :: IK X ~ Type -- Just an axiom for IK }}} which should strainghtforwardly unify. But before we do that we flatten `(IT a |> ax_IK)`, but alas we get just {{{ (fuv :: IK X) where fuv = IT a -- CFunEqCan }}} The cast has disappeared. This happens in `TcFlatten`: {{{ flatten_one (CastTy ty g) }}} I'm pretty sure it's just another manifestation of our existing set of bugs around flattening (Trac #12919). Richard has a mostly- finished patch that cures this --- it'd be great to get it finished! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 09:41:26 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 09:41:26 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.047b735c98addad71e200dbb1a83a2ff@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: 14441 Related Tickets: #13643 | Differential Rev(s): Phab:D3848 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): #14556 is also blocked on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 11:52:14 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 11:52:14 -0000 Subject: [GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble In-Reply-To: <044.13612547bcec0532b940b49a41a2177d@haskell.org> References: <044.13612547bcec0532b940b49a41a2177d@haskell.org> Message-ID: <059.4cb76cbedf177216bf009656054e2b47@haskell.org> #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): Replying to [comment:1 RyanGlScott]: > Do you mean "things go wrong" when trying to build a program that uses Template Haskell? And if so, do you have an example demonstrating what goes wrong? Yes, when building a program that uses Template Haskell, GHC complains that a name is not in scope, when the real reason is that the `Unique` has been truncated (when using a 64 bit GHC) The following test case was reported on the GHCJS tracker as giving a "not in scope" error with 64 bit GHCJS, but working ok with 32 bit GHCJS ( https://github.com/ghcjs/ghcjs/issues/617 ): {{{#!hs {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE QuasiQuotes #-} module QQBug ( test ) where import qualified NeatInterpolation import Data.Text -- txt = "test1" test :: Text test = [NeatInterpolation.text|$txt|] where txt = "test" }}} {{{ QQBug.hs:13:8: error: • The exact Name ‘txt_XN’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the quasi-quotation: [NeatInterpolation.text|$txt|] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 12:57:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 12:57:09 -0000 Subject: [GHC] #14561: Panic on levity polymorphic very unsafe coerce In-Reply-To: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> References: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> Message-ID: <062.25013ab401de02bdb78192577096ae31@haskell.org> #14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"321b420f4582d103ca7b304867b916a749712e9f/ghc" 321b420/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="321b420f4582d103ca7b304867b916a749712e9f" Tidy up of wired-in names Two things here: * While debugging Trac #14561 I found it hard to understand ghcPrimIds and magicIds in MkId. This patch adds more structure and comments. * I also discovered that ($) no longer needs to be a wiredInId because we now have levity polymorphism. So I took dollarId out of MkId; and gave it a levity-polymorphic type in GHC.Base }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 12:57:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 12:57:09 -0000 Subject: [GHC] #14561: Panic on levity polymorphic very unsafe coerce In-Reply-To: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> References: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> Message-ID: <062.f395662627dad01fb2f90685d8488d9b@haskell.org> #14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e40db7b1676627f5291b463405338e7b69fa3f69/ghc" e40db7b1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e40db7b1676627f5291b463405338e7b69fa3f69" Detect levity-polymorphic uses of unsafeCoerce# This bug was shown up by Trac #14561. The deguarer carefully detects unsaturated and levity-polymorphic uses of primops, but not of things like unsafeCoerce#. The fix is simple: see Note [Levity-polymorphic Ids] in Id. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 12:58:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 12:58:47 -0000 Subject: [GHC] #14561: Panic on levity polymorphic very unsafe coerce In-Reply-To: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> References: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> Message-ID: <062.95403c71084c0ddaeaf507fee6f53aa4@haskell.org> #14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T14561 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T14561 * resolution: => fixed Comment: The fix was easier than I thought: see comment:6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 13:42:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 13:42:37 -0000 Subject: [GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble In-Reply-To: <044.13612547bcec0532b940b49a41a2177d@haskell.org> References: <044.13612547bcec0532b940b49a41a2177d@haskell.org> Message-ID: <059.a4110736b3ef8d595cceae8c46f012c2@haskell.org> #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks. Have you confirmed that your proposed patch fixes this issue? If so, I propose just going ahead and submitting the patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 14:03:35 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 14:03:35 -0000 Subject: [GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble In-Reply-To: <044.13612547bcec0532b940b49a41a2177d@haskell.org> References: <044.13612547bcec0532b940b49a41a2177d@haskell.org> Message-ID: <059.3f7d396da697dacc3215f07dd5ae9449@haskell.org> #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): I don't have a complete patch yet, but I'll make one soon and submit (or report back here if things turn out to be more complicated) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 15:13:52 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 15:13:52 -0000 Subject: [GHC] #14578: Incorrect parenthesization of types in -ddump-deriv Message-ID: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> #14578: Incorrect parenthesization of types in -ddump-deriv -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this program on GHC 8.2 or later: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# OPTIONS_GHC -ddump-deriv #-} module Bug where import Control.Applicative import Data.Functor.Compose import Data.Semigroup newtype App f a = MkApp (f a) deriving (Functor, Applicative) instance (Applicative f, Semigroup a) => Semigroup (App f a) where (<>) = liftA2 (<>) newtype Wat f g a = MkWat (App (Compose f g) a) deriving Semigroup }}} Will result in some incorrectly pretty-printed types in the `-ddump-deriv` output: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs -dsuppress-uniques GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance (Data.Semigroup.Semigroup a, GHC.Base.Applicative g, GHC.Base.Applicative f) => Data.Semigroup.Semigroup (Bug.Wat f g a) where (Data.Semigroup.<>) = GHC.Prim.coerce @(Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(Bug.Wat f g a -> Bug.Wat f g a -> Bug.Wat f g a) (Data.Semigroup.<>) Data.Semigroup.sconcat = GHC.Prim.coerce @(Data.List.NonEmpty.NonEmpty Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(Data.List.NonEmpty.NonEmpty Bug.Wat f g a -> Bug.Wat f g a) Data.Semigroup.sconcat Data.Semigroup.stimes = GHC.Prim.coerce @(forall (b :: TYPE GHC.Types.LiftedRep). GHC.Real.Integral b => b -> Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(forall (b :: TYPE GHC.Types.LiftedRep). GHC.Real.Integral b => b -> Bug.Wat f g a -> Bug.Wat f g a) Data.Semigroup.stimes }}} Notice that is shows `Bug.App Data.Functor.Compose.Compose f g a`, which is wrong. It should be `Bug.App (Data.Functor.Compose.Compose f g) a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 15:15:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 15:15:57 -0000 Subject: [GHC] #14578: Incorrect parenthesization of types in -ddump-deriv In-Reply-To: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> References: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> Message-ID: <065.b0bcaa1ae0c47fe5e92b57d01e27452f@haskell.org> #14578: Incorrect parenthesization of types in -ddump-deriv -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > Compiling this program on GHC 8.2 or later: > > {{{#!hs > {-# LANGUAGE GeneralizedNewtypeDeriving #-} > {-# OPTIONS_GHC -ddump-deriv #-} > module Bug where > > import Control.Applicative > import Data.Functor.Compose > import Data.Semigroup > > newtype App f a = MkApp (f a) > deriving (Functor, Applicative) > > instance (Applicative f, Semigroup a) => Semigroup (App f a) where > (<>) = liftA2 (<>) > > newtype Wat f g a = MkWat (App (Compose f g) a) > deriving Semigroup > }}} > > Will result in some incorrectly pretty-printed types in the `-ddump- > deriv` output: > > {{{ > $ /opt/ghc/8.2.2/bin/ghci Bug.hs -dsuppress-uniques > GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/rgscott/.ghci > [1 of 1] Compiling Bug ( Bug.hs, interpreted ) > > ==================== Derived instances ==================== > Derived class instances: > > > > instance (Data.Semigroup.Semigroup a, GHC.Base.Applicative g, > GHC.Base.Applicative f) => > Data.Semigroup.Semigroup (Bug.Wat f g a) where > (Data.Semigroup.<>) > = GHC.Prim.coerce > @(Bug.App Data.Functor.Compose.Compose f g a > -> Bug.App Data.Functor.Compose.Compose f g a > -> Bug.App Data.Functor.Compose.Compose f g a) > @(Bug.Wat f g a -> Bug.Wat f g a -> Bug.Wat f g a) > (Data.Semigroup.<>) > Data.Semigroup.sconcat > = GHC.Prim.coerce > @(Data.List.NonEmpty.NonEmpty Bug.App > Data.Functor.Compose.Compose f g a > -> Bug.App Data.Functor.Compose.Compose f g a) > @(Data.List.NonEmpty.NonEmpty Bug.Wat f g a -> Bug.Wat f g a) > Data.Semigroup.sconcat > Data.Semigroup.stimes > = GHC.Prim.coerce > @(forall (b :: TYPE GHC.Types.LiftedRep). > GHC.Real.Integral b => > b > -> Bug.App Data.Functor.Compose.Compose f g a > -> Bug.App Data.Functor.Compose.Compose f g a) > @(forall (b :: TYPE GHC.Types.LiftedRep). > GHC.Real.Integral b => b -> Bug.Wat f g a -> Bug.Wat f g a) > Data.Semigroup.stimes > }}} > > Notice that is shows `Bug.App Data.Functor.Compose.Compose f g a`, which > is wrong. It should be `Bug.App (Data.Functor.Compose.Compose f g) a`. New description: Compiling this program on GHC 8.2 or later: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# OPTIONS_GHC -ddump-deriv #-} module Bug where import Control.Applicative import Data.Functor.Compose import Data.Semigroup newtype App f a = MkApp (f a) deriving (Functor, Applicative) instance (Applicative f, Semigroup a) => Semigroup (App f a) where (<>) = liftA2 (<>) newtype Wat f g a = MkWat (App (Compose f g) a) deriving Semigroup }}} Will result in some incorrectly pretty-printed types in the `-ddump-deriv` output: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs -dsuppress-uniques GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance (Data.Semigroup.Semigroup a, GHC.Base.Applicative g, GHC.Base.Applicative f) => Data.Semigroup.Semigroup (Bug.Wat f g a) where (Data.Semigroup.<>) = GHC.Prim.coerce @(Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(Bug.Wat f g a -> Bug.Wat f g a -> Bug.Wat f g a) (Data.Semigroup.<>) Data.Semigroup.sconcat = GHC.Prim.coerce @(Data.List.NonEmpty.NonEmpty Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(Data.List.NonEmpty.NonEmpty Bug.Wat f g a -> Bug.Wat f g a) Data.Semigroup.sconcat Data.Semigroup.stimes = GHC.Prim.coerce @(forall (b :: TYPE GHC.Types.LiftedRep). GHC.Real.Integral b => b -> Bug.App Data.Functor.Compose.Compose f g a -> Bug.App Data.Functor.Compose.Compose f g a) @(forall (b :: TYPE GHC.Types.LiftedRep). GHC.Real.Integral b => b -> Bug.Wat f g a -> Bug.Wat f g a) Data.Semigroup.stimes }}} Notice that it shows `Bug.App Data.Functor.Compose.Compose f g a` within the visible type applications, which is wrong. It should be `Bug.App (Data.Functor.Compose.Compose f g) a`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 15:20:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 15:20:53 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.96efeed15ba90e63d32b9e414a1f2acd@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: AndreasK Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4218 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => patch Comment: I have a patch up on Phab but it increases allocations. (Phab:D4218) This seems to be caused by desugaring of derived constants. While the constants should be safe I don't see a way to differentiate them from user written constants. So I would appreciate input on the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 15:23:18 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 15:23:18 -0000 Subject: [GHC] #14578: Incorrect parenthesization of types in -ddump-deriv In-Reply-To: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> References: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> Message-ID: <065.7e68ac81298c65fb36fcbffcd45fbe7f@haskell.org> #14578: Incorrect parenthesization of types in -ddump-deriv -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 15:57:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 15:57:07 -0000 Subject: [GHC] #14561: Panic on levity polymorphic very unsafe coerce In-Reply-To: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> References: <047.2f33ba6cede1478e38dcde40d3f23f7d@haskell.org> Message-ID: <062.a70ac4f8ded663e06c7f02bd38ac4a0f@haskell.org> #14561: Panic on levity polymorphic very unsafe coerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T14561 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"aef4dee8d2b2bffdaa955a65e967bfe9f07a8d0c/ghc" aef4dee8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aef4dee8d2b2bffdaa955a65e967bfe9f07a8d0c" Add missing stderr for Trac #14561 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 16:02:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 16:02:55 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code Message-ID: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: deriving | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program //should// compile: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy newtype Wat (x :: Proxy (a :: Type)) = MkWat (Maybe a) deriving Eq newtype Glurp a = MkGlurp (Wat ('Proxy :: Proxy a)) deriving Eq }}} After all, it //should// produce this `Eq (Glurp a)` instance, which compiles without issue: {{{#!hs instance Eq a => Eq (Glurp a) where (==) = coerce @(Wat ('Proxy :: Proxy a) -> Wat ('Proxy :: Proxy a) -> Bool) @(Glurp a -> Glurp a -> Bool) (==) }}} But despite my wishful thinking, GHC does not actually do this. In fact, the code that GHC tries to generate for an `Eq (Glurp a)` instance is completely wrong: {{{ $ /opt/ghc/8.2.2/bin/ghci -ddump-deriv Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance forall a (x :: Data.Proxy.Proxy a). GHC.Classes.Eq a => GHC.Classes.Eq (Bug.Wat x) where (GHC.Classes.==) = GHC.Prim.coerce @(GHC.Base.Maybe a_a2wE -> GHC.Base.Maybe a_a2wE -> GHC.Types.Bool) @(Bug.Wat x_a2wF -> Bug.Wat x_a2wF -> GHC.Types.Bool) (GHC.Classes.==) (GHC.Classes./=) = GHC.Prim.coerce @(GHC.Base.Maybe a_a2wE -> GHC.Base.Maybe a_a2wE -> GHC.Types.Bool) @(Bug.Wat x_a2wF -> Bug.Wat x_a2wF -> GHC.Types.Bool) (GHC.Classes./=) instance GHC.Classes.Eq a => GHC.Classes.Eq (Bug.Glurp a) where (GHC.Classes.==) = GHC.Prim.coerce @(Bug.Wat Data.Proxy.Proxy -> Bug.Wat Data.Proxy.Proxy -> GHC.Types.Bool) @(Bug.Glurp a_a1vT -> Bug.Glurp a_a1vT -> GHC.Types.Bool) (GHC.Classes.==) (GHC.Classes./=) = GHC.Prim.coerce @(Bug.Wat Data.Proxy.Proxy -> Bug.Wat Data.Proxy.Proxy -> GHC.Types.Bool) @(Bug.Glurp a_a1vT -> Bug.Glurp a_a1vT -> GHC.Types.Bool) (GHC.Classes./=) Derived type family instances: Bug.hs:12:12: error: • Couldn't match representation of type ‘a0’ with that of ‘a’ arising from a use of ‘GHC.Prim.coerce’ ‘a’ is a rigid type variable bound by the instance declaration at Bug.hs:12:12-13 • In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) In an equation for ‘==’: (==) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) When typechecking the code for ‘==’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Eq (Glurp a)’ • Relevant bindings include (==) :: Glurp a -> Glurp a -> Bool (bound at Bug.hs:12:12) | 12 | deriving Eq | ^^ Bug.hs:12:12: error: • Could not deduce (Eq a0) arising from a use of ‘==’ from the context: Eq a bound by the instance declaration at Bug.hs:12:12-13 The type variable ‘a0’ is ambiguous These potential instances exist: instance forall k (s :: k). Eq (Proxy s) -- Defined in ‘Data.Proxy’ instance Eq Ordering -- Defined in ‘GHC.Classes’ instance Eq Integer -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ ...plus 25 others ...plus 9 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the third argument of ‘GHC.Prim.coerce’, namely ‘(==)’ In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) In an equation for ‘==’: (==) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) When typechecking the code for ‘==’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv | 12 | deriving Eq | ^^ Bug.hs:12:12: error: • Couldn't match representation of type ‘a1’ with that of ‘a’ arising from a use of ‘GHC.Prim.coerce’ ‘a’ is a rigid type variable bound by the instance declaration at Bug.hs:12:12-13 • In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) In an equation for ‘/=’: (/=) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) When typechecking the code for ‘/=’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Eq (Glurp a)’ • Relevant bindings include (/=) :: Glurp a -> Glurp a -> Bool (bound at Bug.hs:12:12) | 12 | deriving Eq | ^^ Bug.hs:12:12: error: • Could not deduce (Eq a1) arising from a use of ‘/=’ from the context: Eq a bound by the instance declaration at Bug.hs:12:12-13 The type variable ‘a1’ is ambiguous These potential instances exist: instance forall k (s :: k). Eq (Proxy s) -- Defined in ‘Data.Proxy’ instance Eq Ordering -- Defined in ‘GHC.Classes’ instance Eq Integer -- Defined in ‘integer-gmp-1.0.1.0:GHC.Integer.Type’ ...plus 25 others ...plus 9 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the third argument of ‘GHC.Prim.coerce’, namely ‘(/=)’ In the expression: GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) In an equation for ‘/=’: (/=) = GHC.Prim.coerce @(Wat Proxy -> Wat Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (/=) When typechecking the code for ‘/=’ in a derived instance for ‘Eq (Glurp a)’: To see the code I am typechecking, use -ddump-deriv | 12 | deriving Eq | ^^ }}} Yikes. To see what went wrong, let's zoom in a particular part of the `-ddump-deriv` output (cleaned up a bit for presentation purposes): {{{#!hs instance Eq a => Eq (Glurp a) where (==) = coerce @(Wat 'Proxy -> Wat 'Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) }}} Notice that it's `Wat 'Proxy`, and not `Wat ('Proxy :: Proxy a)`! And no, that's not just a result of GHC omitting the kind information—you will see the exact same thing if you compile with `-fprint-explicit-kinds`. What's going on here? As it turns out, the types inside of those visible type applications aren't `Type`s, but rather `HsType GhcRn`s (i.e., source syntax). So what is happening is that GHC is literally producing `@(Wat 'Proxy -> Wat 'Proxy -> Bool)` //as source syntax//, not as a `Type`. This means that `'Proxy` has an underspecified kind, resulting in the numerous `The type variable ‘a0’ is ambiguous` errors you see above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 16:08:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 16:08:45 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.ad69e1d6be7ddb15fcd2b2e40ad8af7e@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hm... look at `TcGenDeriv.nlHsAppType`. Presumably you want to add the necessary kind signatures when doing `typeToHsType`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 16:45:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 16:45:27 -0000 Subject: [GHC] #14174: GHC panic with TypeInType and type family In-Reply-To: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> References: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> Message-ID: <060.1d5014927dabf1b5d5afe07e393518f6@haskell.org> #14174: GHC panic with TypeInType and type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T14174.hs, T14174a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0a12d92a8f65d374f9317af2759af2b46267ad5c/ghc" 0a12d92a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0a12d92a8f65d374f9317af2759af2b46267ad5c" Further improvements to well-kinded types The typechecker has the invariant that every type should be well-kinded as it stands, without zonking. See Note [The well-kinded type invariant] in TcType. That invariant was not being upheld, which led to Trac #14174. I fixed part of it, but T14174a showed that there was more. This patch finishes the job. * See Note [The tcType invariant] in TcHsType, which articulates an invariant that was very nearly, but not quite, true. One place that falisified it was the HsWildCardTy case of tc_hs_type, so I fixed that. * mkNakedCastTy now makes no attempt to eliminate casts; indeed it cannot lest it break Note [The well-kinded type invariant]. The prior comment suggested that it was crucial for performance but happily it seems not to be. The extra Refls are eliminated by the zonker. * I found I could tidy up TcHsType.instantiateTyN and instantiateTyUntilN by eliminating one of its parameters. That led to a cascade of minor improvements in TcTyClsDecls. Hooray. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 16:48:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 16:48:09 -0000 Subject: [GHC] #14174: GHC panic with TypeInType and type family In-Reply-To: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> References: <045.87c0508a41a6d0d9834ba40ef8506297@haskell.org> Message-ID: <060.3eab99b01ee54a3040e6f02652b5f2a7@haskell.org> #14174: GHC panic with TypeInType and type family -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T14174.hs, T14174a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: OK, finally fixed I believe. Hurrah. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 16:48:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 16:48:19 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.639f4b51ac17abfaf669b200762ea4ed@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: linker Operating System: 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): * cc: George (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 17:10:56 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 17:10:56 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.87a54876e4148b873d94b762aa7f7742@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4264 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 17:28:27 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 17:28:27 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.1ad3ea45459f8ad098da2550b03309a1@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What change to `typeToHsType` do we want? The problem is to specify the invisible kind arguments to occurrences of poly-kinded type-constructor applications. Eg {{{ instance Eq a => Eq (Glurp a) where (==) = coerce @(Wat 'Proxy -> Wat 'Proxy -> Bool) @(Glurp a -> Glurp a -> Bool) (==) }}} The problem is the invisible kind arguments to the poly-kinded `'Proxy` occurrences. If we had visible kind application we could use that, but we don't. Solution: add a kind signature, as in the Description: {{{ instance Eq a => Eq (Glurp a) where (==) = coerce @(Wat ('Proxy :: Proxy a) -> Wat ('Proxy :: Proxy a) -> Bool) @(Glurp a -> Glurp a -> Bool) (==) }}} When do we need a kind signature? * (a) When we have an application of a type constructor with invisible arguments * (b) And the invisible arguments are not fixed by the kinds of the visible arguments. Probably just using (a) is enough to reduce the noise of redundant kind signatures to reasonable levels. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 17:34:22 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 17:34:22 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.71e2cf6a99539408fedf35c51ca4e67b@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Is there any reason we can't say {{{#!hs typeToLHsType = noLoc . HsCoreTy }}} ? That certainly seems to save a lot of huffing and puffing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 17:37:02 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 17:37:02 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.9e1c597fccd8c421c7a7d4f014572ea1@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good thought. But these types have free type variables, bound by the instance decl. I'm far from sure they'd line up right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 18:23:13 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 18:23:13 -0000 Subject: [GHC] #14564: CAF isn't floated In-Reply-To: <050.1af4937b5006defb6915274137e1c026@haskell.org> References: <050.1af4937b5006defb6915274137e1c026@haskell.org> Message-ID: <065.5b86402a76a9f77bf2a127ff004306ff@haskell.org> #14564: CAF isn't floated -------------------------------------+------------------------------------- Reporter: neil.mayhew | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: FloatOut Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14519 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * related: => #14519 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 18:24:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 18:24:10 -0000 Subject: [GHC] #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA In-Reply-To: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> References: <043.92c07e3e0209c31f0a0f195fa98d301c@haskell.org> Message-ID: <058.4a6de4e3647ba9453e88f72bd886c100@haskell.org> #14519: Exponential runtime performance regression in GHC 8.2 + Data.Text.Lazy + Text.RE.TDFA -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: tdammers Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | https://github.com/ntc2/ghc-8.2.1 | -regex-lazy-text- | bug/tree/07b7bb32c6e90e8f2d2eada4b59943f37e632d53 Blocked By: | Blocking: Related Tickets: #13745, #14564 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * related: #13745 => #13745, #14564 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 18:25:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 18:25:34 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.fde6f0a3ed1bd3e2634b2c4f861a9cd6@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): simonpj's hunch appears to be right—I just attempted to compile GHC with goldfire's suggested change, and wound up face-first in panictown: {{{ libraries/base/GHC/Generics.hs:811:13: error:ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.5.20171213 for x86_64-unknown-linux): No skolem info: [p3_a3Jl] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:2892:5 in ghc:TcErrors }}} I'll try simonpj's suggested refactoring in comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 18:56:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 18:56:39 -0000 Subject: [GHC] #14578: Incorrect parenthesization of types in -ddump-deriv In-Reply-To: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> References: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> Message-ID: <065.2148a997602126d6f2c3168a3a69d85b@haskell.org> #14578: Incorrect parenthesization of types in -ddump-deriv -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): And here is why: the type `App (Compose f g) a` is produced by the function [http://git.haskell.org/ghc.git/blob/0a12d92a8f65d374f9317af2759af2b46267ad5c:/compiler/hsSyn/HsUtils.hs#l620 typeToLHsType]. Here is the line of code that's responsible: {{{#!hs go (TyConApp tc args) = nlHsTyConApp (getRdrName tc) (map go args') where args' = filterOutInvisibleTypes tc args }}} Notice that this does not attempt to put the appropriate `HsParTy`s in place. I think an appropriate way to fix this would be to adopt the same trick that alanz has used elsewhere: apply the [http://git.haskell.org/ghc.git/blob/0a12d92a8f65d374f9317af2759af2b46267ad5c:/compiler/hsSyn/Convert.hs#l1324 mk_apps] function to `tc` and `args'`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 13 19:37:45 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Dec 2017 19:37:45 -0000 Subject: [GHC] #14578: Incorrect parenthesization of types in -ddump-deriv In-Reply-To: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> References: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> Message-ID: <065.cf356645b9442e744e96868ab9d8946c@haskell.org> #14578: Incorrect parenthesization of types in -ddump-deriv -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4266 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4266 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 00:28:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 00:28:11 -0000 Subject: [GHC] #9364: GHCi (or haskeline?) confused by non-single-width characters In-Reply-To: <046.188450f148764a8992314b4689d05445@haskell.org> References: <046.188450f148764a8992314b4689d05445@haskell.org> Message-ID: <061.3caef78090fc51f7c6c0576277c4af84@haskell.org> #9364: GHCi (or haskeline?) confused by non-single-width characters -------------------------------------+------------------------------------- Reporter: cheater | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: linux, | terminal, colour, color, prompt Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #5850 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by cheater): * status: closed => new * resolution: wontfix => Comment: The issue persists for multi-line prompts. Here is the relevant report in Haskeline: https://github.com/judah/haskeline/issues/72 once this is fixed in Haskeline and this is merged into ghci, this and the bug does not exist for single or multiline prompts, this issue may be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 02:54:43 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 02:54:43 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.43bd86068fca9a38c53f9e49e3326aa5@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | 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 ron): I am new to GHC dev and working on a patch for #393 as a way to learn my way around the codebase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 04:45:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 04:45:50 -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.62703db2c0ec9be2042c80cdf603c8f0@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 ezyang): Yeah, local type synonyms are probably the least controversial of "make global things possible locally" proposals. There are pretty clear semantics for how it works in all cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 07:16:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 07:16:12 -0000 Subject: [GHC] #14580: GHC panic (TypeInType) (the 'impossible' happened) Message-ID: <051.d1906a3ffd883a9a4f4e87bd3beda825@haskell.org> #14580: GHC panic (TypeInType) (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 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: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci GHCi, version 8.3.20171208: http://www.haskell.org/ghc/ :? for help Prelude> import Data.Kind Prelude Data.Kind> :set -XPolyKinds -XDataKinds -XTypeInType -XTypeOperators Prelude Data.Kind> type Cat ob = ob -> ob -> Type Prelude Data.Kind> data ISO' :: Cat i -> i -> i -> Type Prelude Data.Kind> type ISO cat a b = ISO' cat a b -> Type Prelude Data.Kind> type (a <--> b) iso cat = ISO (iso :: cat a b) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171208 for x86_64-unknown-linux): piResultTy k_a1x1[tau:1] a_a1wU[sk:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1144:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:951:35 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude Data.Kind> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 08:53:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 08:53:27 -0000 Subject: [GHC] #14581: coerce String type in annotations with OverloadedStrings enabled Message-ID: <046.747811206b0738ba80800edbce018c21@haskell.org> #14581: coerce String type in annotations with OverloadedStrings enabled -------------------------------------+------------------------------------- Reporter: mgmeier | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the following snippet fails with the error message for not being able to resolve the constraint IsString for the given annotation (I've chosen some random HLint annotation here): {{{#!hs {-# LANGUAGE OverloadedStrings #-} module Foo where {-# ANN module "HLint: ignore Use <$>" #-} }}} Stating the type explicitly works fine, changing the annotation like this: {{{#!hs {-# ANN module ("HLint: ignore Use <$>" :: String) #-} }}} Note: this is actually only a minor annoyance which may or may not be confusing to newcomers. However since annotations use the String type, wouldn't it be possible to resolve the constraint in this case / coerce the value when inside an annotation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 09:00:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 09:00:11 -0000 Subject: [GHC] #14581: coerce String type in annotations with OverloadedStrings enabled In-Reply-To: <046.747811206b0738ba80800edbce018c21@haskell.org> References: <046.747811206b0738ba80800edbce018c21@haskell.org> Message-ID: <061.a577bb269f79e1adf2786655e31085f5@haskell.org> #14581: coerce String type in annotations with OverloadedStrings enabled -------------------------------------+------------------------------------- Reporter: mgmeier | Owner: (none) Type: feature request | Status: new 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mgmeier): Addendum: or is the general idea of annotations that you should be ably to annotate some definition with *any* Haskell value? In this case, the behavior would make sense and my request wouldn't, so you can close it :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 10:55:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 10:55:49 -0000 Subject: [GHC] #481: Recompilation check fails for TH In-Reply-To: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> References: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> Message-ID: <061.57977604f14ec0e6eb4305400d5af3a5@haskell.org> #481: Recompilation check fails for TH -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: TH_recompile Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I don't think there's any perf impact, the stability check is already being done. The problem you're most likely seeing is that the recompilation check for TH is more conservative than we need in many cases, because the compiler doesn't know what your TH code depends on so it has to assume the worst. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 11:39:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 11:39:49 -0000 Subject: [GHC] #14580: GHC panic (TypeInType) (the 'impossible' happened) In-Reply-To: <051.d1906a3ffd883a9a4f4e87bd3beda825@haskell.org> References: <051.d1906a3ffd883a9a4f4e87bd3beda825@haskell.org> Message-ID: <066.d3d85e70e18af776df8b9cab920eccf9@haskell.org> #14580: GHC panic (TypeInType) (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6f6d1050d96e6697cc4559eb54d03959efe28de1/ghc" 6f6d1050/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6f6d1050d96e6697cc4559eb54d03959efe28de1" Add test for Trac #14580 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 11:40:13 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 11:40:13 -0000 Subject: [GHC] #14580: GHC panic (TypeInType) (the 'impossible' happened) In-Reply-To: <051.d1906a3ffd883a9a4f4e87bd3beda825@haskell.org> References: <051.d1906a3ffd883a9a4f4e87bd3beda825@haskell.org> Message-ID: <066.8662d5e92eecf798c02fc91094865e47@haskell.org> #14580: GHC panic (TypeInType) (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T14580 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T14580 * resolution: => fixed Comment: HEAD gives {{{ Prelude Data.Kind> type (a <--> b) iso cat = ISO (iso :: cat a b) :7:31: error: • Expected kind ‘Cat a’, but ‘(iso :: cat a b)’ has kind ‘cat a b’ • In the first argument of ‘ISO’, namely ‘(iso :: cat a b)’ In the type ‘ISO (iso :: cat a b)’ In the type declaration for ‘<-->’ }}} probably as a result of the patches I pushed yesterday. Hurrah. I've added a regression test, to be on the safe side. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 13:03:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 13:03:00 -0000 Subject: [GHC] #14581: coerce String type in annotations with OverloadedStrings enabled In-Reply-To: <046.747811206b0738ba80800edbce018c21@haskell.org> References: <046.747811206b0738ba80800edbce018c21@haskell.org> Message-ID: <061.07ca81ed29d12924fe226302e90c3159@haskell.org> #14581: coerce String type in annotations with OverloadedStrings enabled -------------------------------------+------------------------------------- Reporter: mgmeier | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Replying to [comment:1 mgmeier]: > Addendum: or is the general idea of annotations that you should be able to annotate some definition with ''any'' Haskell value? Yes. [https://downloads.haskell.org/~ghc/8.2.2/docs/html/users_guide/extending_ghc.html?highlight=ann #annotating-values Per the users' guide:] > Any expression that has both `Typeable` and `Data` instances may be attached to a top-level value binding using an `ANN` pragma. Thus both `String` and `Text` could be used in an `ANN` pragma, so you'd need to resolve the ambiguity yourself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 13:28:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 13:28:06 -0000 Subject: [GHC] #14554: Core Lint error mixing In-Reply-To: <051.5e0e6c0ed6a121855ea808a25d27d322@haskell.org> References: <051.5e0e6c0ed6a121855ea808a25d27d322@haskell.org> Message-ID: <066.816b9ec74ec29e2bec8911481f9e612d@haskell.org> #14554: Core Lint error mixing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | PolyKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14556 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b1ea0475894713b9fc753bf288589e0dc3175083/ghc" b1ea047/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b1ea0475894713b9fc753bf288589e0dc3175083" Fix an outright bug in the unflattener Trac #14554 showed up an outright bug in the unflattening code in TcFlatten. I was filling in a coercion with the wrong coercion (a Syn in the wrong place). Result: "Bad coercion hole" assertion failures, and Core Lint Errors. Easily fixed, and the code is simpler too. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 13:28:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 13:28:50 -0000 Subject: [GHC] #14554: Core Lint error mixing In-Reply-To: <051.5e0e6c0ed6a121855ea808a25d27d322@haskell.org> References: <051.5e0e6c0ed6a121855ea808a25d27d322@haskell.org> Message-ID: <066.16353706dee875b4021b8835e4de968c@haskell.org> #14554: Core Lint error mixing -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: TypeInType, | PolyKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T14554 Blocked By: | Blocking: Related Tickets: #14556 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => indexed-types/should_compile/T14554 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 13:44:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 13:44:03 -0000 Subject: [GHC] #14552: GHC panic on pattern synonym In-Reply-To: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> References: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> Message-ID: <066.faa02e7a6b709a034d46925d32a7a85f@haskell.org> #14552: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms, TypeInType, | ViewPatterns Operating System: 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): If you don't have a build with `ASSERT`ions enabled, then you can also trigger a Core Lint with this program as well: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs -dcore-lint GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (after optimization) *** : warning: In the type ‘forall (r :: TYPE rep) (a :: [*]) b (aa :: k). Exp a b -> (forall k1 (f :: k1 --> *). (b :: *) ~# (Limit' f :: *) => Exp a (f @@ aa) -> r) -> (Void# -> r) -> r’ @ k_a1K2[ssk:3] is out of scope *** Offending Program *** $mFOO :: forall (r :: TYPE rep) (a :: [*]) b (aa :: k). Exp a b -> (forall k1 (f :: k1 --> *). (b :: *) ~# (Limit' f :: *) => Exp a (f @@ aa) -> r) -> (Void# -> r) -> r [LclIdX] $mFOO = \ (@ (rep_a1Kn :: RuntimeRep)) (@ (r_a1Ko :: TYPE rep_a1Kn)) (@ (a_a1K0 :: [*])) (@ b_a1K1) (@ (aa_a1Kc :: k_a1K2[ssk:3])) (scrut_a1Kq :: Exp a_a1K0 b_a1K1) (cont_a1Kr :: forall k1 (f :: k1 --> *). (b_a1K1 :: *) ~# (Limit' f :: *) => Exp a_a1K0 (f @@ aa_a1Kc) -> r_a1Ko) _ [Occ=Dead] -> break<0>(scrut_a1Kq,cont_a1Kr) case scrut_a1Kq of { TLam' @ k_a1K2 @ f_a1K3 cobox_a1K4 ds_d1Lm ds_d1Ln -> case ds_d1Lm of { Proxy -> cont_a1Kr @ k_a1K2 @ f_a1K3 @~ (cobox_a1K4 :: (b_a1K1 :: *) ~# (Limit' f_a1K3 :: *)) ((\ (ds_d1Lp [OS=OneShot] :: Proxy aa_a1Kc -> Exp a_a1K0 (f_a1K3 @@ aa_a1Kc)) -> $ @ 'LiftedRep @ (Proxy aa_a1Kc) @ (Exp a_a1K0 (f_a1K3 @@ aa_a1Kc)) ds_d1Lp (Proxy @ k_a1K2 @ aa_a1Kc)) (ds_d1Ln @ aa_a1Kc)) } } $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) $krep_a1Lc [InlPrag=[~]] :: KindRep [LclId] $krep_a1Lc = KindRepTyConApp $tc[] (: @ KindRep krep$* ([] @ KindRep)) $krep_a1Lb [InlPrag=[~]] :: KindRep [LclId] $krep_a1Lb = KindRepFun $krep_a1Lc krep$*Arr* $krep_a1Lg [InlPrag=[~]] :: KindRep [LclId] $krep_a1Lg = $WKindRepVar (I# 0#) $krep_a1Lh [InlPrag=[~]] :: KindRep [LclId] $krep_a1Lh = KindRepFun $krep_a1Lg krep$* $krep_a1Lf [InlPrag=[~]] :: KindRep [LclId] $krep_a1Lf = KindRepTyConApp $tc(,) (: @ KindRep $krep_a1Lg (: @ KindRep krep$* ([] @ KindRep))) $krep_a1Le [InlPrag=[~]] :: KindRep [LclId] $krep_a1Le = KindRepFun $krep_a1Lf krep$* $krep_a1Ld [InlPrag=[~]] :: KindRep [LclId] $krep_a1Ld = KindRepFun $krep_a1Le krep$* $krep_a1Lj [InlPrag=[~]] :: KindRep [LclId] $krep_a1Lj = $WKindRepVar (I# 1#) $tcSing :: TyCon [LclIdX] $tcSing = TyCon 18130532723012807500## 591365583239837277## $trModule (TrNameS "Sing"#) 0# krep$*Arr* $tcProxy :: TyCon [LclIdX] $tcProxy = TyCon 637564349063008466## 16772998216715059205## $trModule (TrNameS "Proxy"#) 1# $krep_a1Lh $krep_a1Li [InlPrag=[~]] :: KindRep [LclId] $krep_a1Li = KindRepTyConApp $tcProxy (: @ KindRep $krep_a1Lg (: @ KindRep $krep_a1Lj ([] @ KindRep))) $tc'Proxy :: TyCon [LclIdX] $tc'Proxy = TyCon 10313009608267148799## 11340514327723585599## $trModule (TrNameS "'Proxy"#) 2# $krep_a1Li $tcLimit' :: TyCon [LclIdX] $tcLimit' = TyCon 15980210257158400910## 15895439795101193324## $trModule (TrNameS "Limit'"#) 1# $krep_a1Ld $tcExp :: TyCon [LclIdX] $tcExp = TyCon 14856342479466933336## 11891426334869696372## $trModule (TrNameS "Exp"#) 0# $krep_a1Lb *** End of Offense *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 13:54:19 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 13:54:19 -0000 Subject: [GHC] #14582: Review and improve the Typeable API Message-ID: <046.5612146f2311ba7293047a422efaef45@haskell.org> #14582: Review and improve the Typeable API -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: Typeable | 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 is to track improvements in the `Typeable` API There are a number of points I'm uncomfortable about * `Data.Typable` is presumably meant to be the public API, and is fairly small. But `Data.Typeable.Internal` has a much larger API, which includes pattern synonyms and suchlike that appear to be for the benefit of clients, not just internal use. * The `Typeable` API has `type TypeRep = I.SomeTypeRep` which is different to the type-indexed `data TypeRep a` defined in `Data.Typeable.Internals`. This is exteremly confusing. Perhaps this is intended to be temporary, while we are moving over to the new type-indexed representation. But then what's the transition plan? * I cordially dislike this stuff about `IsApplication` in `Internals` ([https://git.haskell.org/ghc.git/commitdiff/1acb922bb1186662919c1dbc0af596584e5db3ac this commit]). It's hard for me to understand what's going on. I believe that the two pattern synonyms `App` and `Con` are supposed to be exhaustive -- if so, let's just write a COMPLETE pragma. * The code has many uses of `unsafeCoerce`, whereas the drive of our "Typed reflection in Haskell" paper was to reduced the size of the trusted code base. I'd like to see a comment on each of those uses of `unsafeCoerce` to explain. * Do we really need `Con'` as well as `Con`? * The API could do with some careful documentation, in Haddock, but perhaps also an accomanying wiki page. It's tricky stuff. Here's the [wiki:Typeable Typeable wiki page] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 14:06:53 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 14:06:53 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.bce06a1161d734e9e45d454b866e19f9@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I thus claim that bringing existentials into scope in pattern synonyms is indeed useful. I disagree. If you try to do this there is nothing to stop you using the existential variable in place where it really isn't in scope. Eg. {{{ pattern Q :: () => forall a. C a => Int -> G a -> (Int,Ex) pattern Q y x <- (y::a, MkEx _ (meth @a -> x)) }}} Now this is a bit stupid because `y::Int`, but it really should not be possible to refer to the existential `a` except underneath the appropriate pattern match. There may be many, possibly nested or possibly peer, existential patterns in a single pattern synonym. Moreover in terms we are content to be stuck with the choice of {{{ f x = case x of { MkEx (_ :: Proxy a) (meth @a -> x) -> ... } }}} Again we can only bring `a` into scope under the match. Maybe we'll add visible (existential) type application in patterns like this {{{ f x = case x of { MkEx @a _ (meth @a -> x) -> ... } }}} in which case that'll work in both cases. No no no. The more I think about this the more I'm convinced that the existentials absolutely should not scope, contrary to my original comment:1. Richard, do you agree? Then we can implement it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 15:44:18 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 15:44:18 -0000 Subject: [GHC] #14582: Review and improve the Typeable API In-Reply-To: <046.5612146f2311ba7293047a422efaef45@haskell.org> References: <046.5612146f2311ba7293047a422efaef45@haskell.org> Message-ID: <061.97a8ef18f68aa4979cb2b81625d6deca@haskell.org> #14582: Review and improve the Typeable API -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 15:49:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 15:49:45 -0000 Subject: [GHC] #14580: GHC panic (TypeInType) (the 'impossible' happened) In-Reply-To: <051.d1906a3ffd883a9a4f4e87bd3beda825@haskell.org> References: <051.d1906a3ffd883a9a4f4e87bd3beda825@haskell.org> Message-ID: <066.92417bc0ca33a40c6e166333fab10422@haskell.org> #14580: GHC panic (TypeInType) (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T14580 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Excellent, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 15:59:27 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 15:59:27 -0000 Subject: [GHC] #14416: CI with CircleCI In-Reply-To: <043.af09c8504e7db798b11a186aefc2b2d5@haskell.org> References: <043.af09c8504e7db798b11a186aefc2b2d5@haskell.org> Message-ID: <058.512c7a1f9c280e83f7c220a5d6083cc9@haskell.org> #14416: CI with CircleCI -------------------------------------+------------------------------------- Reporter: chak | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.4.1 Component: Continuous | Version: Integration | 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: | ContinuousIntegration | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * component: Build System => Continuous Integration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 17:48:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 17:48:16 -0000 Subject: [GHC] #14582: Review and improve the Typeable API In-Reply-To: <046.5612146f2311ba7293047a422efaef45@haskell.org> References: <046.5612146f2311ba7293047a422efaef45@haskell.org> Message-ID: <061.9a82740b077c982688095b6ea0068b60@haskell.org> #14582: Review and improve the Typeable API -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > `Data.Typable` is presumably meant to be the public API, and is fairly small. But `Data.Typeable.Internal` has a much larger API, which includes pattern synonyms and suchlike that appear to be for the benefit of clients, not just internal use. As noted in its documentation, `Data.Typeable` is the home of the old, non-type-indexed `Typeable` mechanism whereas the new mechanism lives in `Type.Reflection`. The goal of this design was to preserve compatibility with existing programs by minimizing the changes in `Data.Typeable`. All of the new bits, including the pattern synonyms (which are really only useful with the type-indexed variant), are exposed in `Type.Reflection`. > This is exteremly confusing. Perhaps this is intended to be temporary, while we are moving over to the new type-indexed representation. But then what's the transition plan? My original intent was for this to be permanent. While working on the new `Typeable` implementation I viewed `Data.Typeable` and `Type.Reflection` as two mechanisms that, which while they happened to share implementation, serve rather different purposes. However, the name `TypeRep` seems to be quite applicable in both cases. I can see how the naming may be confusing and ideally the quantified variant would be called `SomeTypeRep` but I'm skeptical that deprecating the `Data.Typeable.TypeRep` synonym is worth the breakage that it would cause. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 17:49:17 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 17:49:17 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.7911ffdaec7a7b0371874238b57f0c0a@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"16c7d9dc9ea7505256e0792c958cab8ae7c8a5c4/ghc" 16c7d9dc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="16c7d9dc9ea7505256e0792c958cab8ae7c8a5c4" Fix #14135 by validity checking matches We filter the complete patterns given in a COMPLETE set to only those that subsume the type we are matching. Otherwise we end up introducing an ill- typed equation into the overlap checking, provoking a crash. This was the cause of Trac #14135. Reviewers: austin, bgamari, mpickering, gkaracha, simonpj, RyanGlScott, carlostome Reviewed By: bgamari Subscribers: carter, dfeuer, RyanGlScott, goldfire, rwbarton, thomie GHC Trac Issues: #14135 Differential Revision: https://phabricator.haskell.org/D3981 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 19:06:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 19:06:07 -0000 Subject: [GHC] #12372: bug: documentation for Control.Monad.guard not useful after AMP In-Reply-To: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> References: <043.bd49d884aa9da8caf539111086601a3f@haskell.org> Message-ID: <058.f9669946eb0a25f02bd494a4a332de47@haskell.org> #12372: bug: documentation for Control.Monad.guard not useful after AMP -------------------------------------+------------------------------------- Reporter: ntc2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.4.1 Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 19:14:09 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 19:14:09 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.bc10d430f7ad2f91e4a641307956f8c9@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I agree with comment:16 and retract my comment:15. I guess what I really want is [https://github.com/ghc-proposals/ghc-proposals/pull/96 Proposal 96], but that's (rightly) separate from this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 19:14:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 19:14:39 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.194b5bb57659ec7f7c74f29439650de1@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler (Type | Version: None checker) | 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 bgamari): ron, is there a specification for your change written down somewhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 20:03:22 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 20:03:22 -0000 Subject: [GHC] #14552: GHC panic on pattern synonym In-Reply-To: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> References: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> Message-ID: <066.04ee403be6f8840333a8a159a5aa13d4@haskell.org> #14552: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms, TypeInType, | ViewPatterns Operating System: 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): Simon asked me to take a look at this pattern synonym, as there are deeper issues here. Here is a much simpler scenario with similar issues: {{{#!hs data T where T :: (forall a. Int -> a -> a) -> T pattern PT x <- T (($ 3) -> x) }}} What type should `PT` have? Here are two possibilities: (renaming for clarity, but both have the same definition) {{{#!hs pattern PT1 :: forall a. (a -> a) -> T pattern PT2 :: (forall a. a -> a) -> T }}} These synonyms correspond to the following two matchers: {{{#!hs matcher1 :: forall r a. T -> ((a -> a) -> r) -> r matcher1 (T f) k = k (f 3) matcher2 :: forall r. T -> ((forall a. a -> a) -> r) -> r matcher2 (T f) k = k (f 3) }}} Both type-check. The second is more general than the first, even though the first is what GHC infers for the definition if given the chance. So, which matcher should we generate for `PT`? However, I've just played a trick on you. Notice that I inlined the use of `($)` in my matchers. Interestingly, `matcher2` does not type check without this inlining: {{{#!hs matcher2 (T (($ 3) -> x)) k = k x -- does not type-check }}} This fails because it contains an unsaturated use of `($)`, and unsaturated uses of `($)` do not get the pseudo-impredicative magic that saturated uses of `($)` get. So, really, `matcher1` is the only possibility. (Indeed, GHC infers a pattern type of `forall a. (a -> a) -> T` for `PT`.) In the original program, the question above (where to generalize) isn't properly formed. That's because the equivalent of the `a` here (called `aa` in the example) has an existentially-bound kind, so it can't possibly scope over the whole matcher type. (In other words, it can't be like `matcher1`.) As I've already argued, it also can't be like `matcher2` (because `($)` isn't impredicative in this scenario). So, it must be like `matcher3`: {{{#!hs matcher3 :: forall r. T -> ((Any -> Any) -> r) -> r matcher3 (T (($ 3) -> x)) k = k x }}} This is a bit silly, but it's the best we can do if we can't generalize over `a`. In the original program, this is really {{{#!hs matcher :: Exp xs t -> (forall k (f :: k --> Type). Exp xs (f @@ Any) -> r) -> r matcher (TLam (Proxy :: Proxy this_f) (($ (Proxy @Any)) -> z)) k = k @_ @this_f z }}} Probably not what the user wanted, but I don't see how we can do better without an impredicative unsaturated `($)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 20:07:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 20:07:50 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.0c83e9a9e4f3e803164a99260caa73b0@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ryan's visit to panictown notwithstanding, I'm still not convinced by comment:5. comment:5 seems to be suggesting that we need the generated code to pass through the renamer, so that the type variables can be captured. This is a reasonable guess. But `typeToLHsType`, as currently written (and working), uses `Exact` names, so the journey through the renamer doesn't capture anything. Perhaps the panic is actually caused by these lines in !RnTypes: {{{#!hs rnHsTyKi _ (HsCoreTy ty) = return (HsCoreTy ty, emptyFVs) -- The emptyFVs probably isn't quite right -- but I don't think it matters }}} Maybe it matters. Or maybe I'm missing something more fundamental. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 20:11:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 20:11:11 -0000 Subject: [GHC] #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) In-Reply-To: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> References: <050.a39b92c3108f361708a6e28740f79fdc@haskell.org> Message-ID: <065.bd5ed5c28c6f07f6d9882f4d37f4b956@haskell.org> #14135: PatternSynonyms regression in GHC HEAD (expectJust mkOneConFull) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: dfeuer Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3981 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 20:41:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 20:41:33 -0000 Subject: [GHC] #14373: Introduce PTR-tagging for big constructor families In-Reply-To: <048.fd4e2364f8515bbd8b92613edf1e7763@haskell.org> References: <048.fd4e2364f8515bbd8b92613edf1e7763@haskell.org> Message-ID: <063.12b16940d9f96d72f80065e14b776589@haskell.org> #14373: Introduce PTR-tagging for big constructor families -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): https://phabricator.haskell.org/D4267 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 20:42:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 20:42:14 -0000 Subject: [GHC] #14373: Introduce PTR-tagging for big constructor families In-Reply-To: <048.fd4e2364f8515bbd8b92613edf1e7763@haskell.org> References: <048.fd4e2364f8515bbd8b92613edf1e7763@haskell.org> Message-ID: <063.8e777dc1071593cfa6aa55fb91e1dea2@haskell.org> #14373: Introduce PTR-tagging for big constructor families -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * owner: (none) => heisenbug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 20:43:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 20:43:32 -0000 Subject: [GHC] #13861: Take more advantage of STG representation invariance (follows up #9291) In-Reply-To: <048.651e325a747e822318af666cede88e81@haskell.org> References: <048.651e325a747e822318af666cede88e81@haskell.org> Message-ID: <063.35732cd2dfbcccf043b2d24cfe97a6be@haskell.org> #13861: Take more advantage of STG representation invariance (follows up #9291) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * owner: (none) => heisenbug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 20:49:29 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 20:49:29 -0000 Subject: [GHC] #13861: Take more advantage of STG representation invariance (follows up #9291) In-Reply-To: <048.651e325a747e822318af666cede88e81@haskell.org> References: <048.651e325a747e822318af666cede88e81@haskell.org> Message-ID: <063.5d7e019ae877699577f174616b4ef885@haskell.org> #13861: Take more advantage of STG representation invariance (follows up #9291) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Now that #14373 is up for review, it is time to revisit this one. It turns out that coercion between small and big families is not an issue any more (provided that wip/T14373 gets merged). From big family with ptr-tag 7 we anyway only can go to small family ptr-tag 7 if the tags in the info table match, so everything is okay. My conservative 1..6 assessment above is not needed. We can safely have 1..7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 20:57:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 20:57:16 -0000 Subject: [GHC] #14552: GHC panic on pattern synonym In-Reply-To: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> References: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> Message-ID: <066.2bfacf7987609e82db8d49faffef40ee@haskell.org> #14552: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms, TypeInType, | ViewPatterns Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This is crazy. Does it make a difference if `($ 3)` got expanded `(\f -> f 3)`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 22:16:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 22:16:39 -0000 Subject: [GHC] #14411: `make fasttest` exits successfully even in presence of failures In-Reply-To: <047.a89ff3751f3bb0ca676c5fa509a7a698@haskell.org> References: <047.a89ff3751f3bb0ca676c5fa509a7a698@haskell.org> Message-ID: <062.15215d12948f3bf44faaba2d5ffe3672@haskell.org> #14411: `make fasttest` exits successfully even in presence of failures -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4268 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D4268 * milestone: => 8.4.1 Comment: This is because the testsuite driver always exits successfully. Tthe `validate` script is the only thing that checks for failed tests. I fix this in Phab:D4268. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 22:17:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 22:17:02 -0000 Subject: [GHC] #13205: Run `validate --slow` during CI at least sometimes. In-Reply-To: <047.9b52b4440ebca44d5a2343fbe8a3a428@haskell.org> References: <047.9b52b4440ebca44d5a2343fbe8a3a428@haskell.org> Message-ID: <062.cdabc110d078b5ae75ed1fa1cd728847@haskell.org> #13205: Run `validate --slow` during CI at least sometimes. -------------------------------------+------------------------------------- Reporter: dobenour | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.0.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => bgamari * component: Compiler => Continuous Integration -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 22:30:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 22:30:24 -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.342257cd4d8b736a4f4ff5bc523a3c43@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.4.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: 13716 Related Tickets: | Differential Rev(s): Phab:D4039 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have had to revert comment:5 due to #14392. I'm just going to focus on make this doable from Hadrian in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 22:57:45 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 22:57:45 -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.35a73f30074019b7274f7ade2a85fb7e@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 AntC): Replying to [comment:17 pggiarrusso]: > A local type synonym should arguably be expanded, and only be in scope in its where clause, or in general in the lexical scope of the declaration. Probably the synonym should be expanded when exiting the synonym’s scope, so that error messages for type errors in the block use the synonym and not its expansion. GHC constantly strives to provide error messages that pinpoint a problem as closely as possible. Consider {{{ x :: String x = "hello" y :: [Char] y = "world" xy = x + y -- error: no instance for (Num String) yx = y + x -- error: no instance for (Num [Char]) }}} So the error message uses the declared type/synonym where it can. (I imagine that's rather fragile.) It doesn't look for a synonym that would be equivalent to some type. Why not: declare the synonym at top level, as usual; omit it from the module's export list so its scope is only the module; if you want a let- bound var declared with the synonym you can, and error messages will use that. Yes, lambda-lift for lexically scoped type vars. I'm not seeing that's a big burden. But if it is, perhaps it'll spur someone to put in a properly explained proposal on github. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 14 23:10:40 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Dec 2017 23:10:40 -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.076e8385674662c9d3116165ae27e97b@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 AntC): Replying to [comment:18 ezyang]: > Yeah, local type synonyms are probably the least controversial Thanks Edward, but I see no controversy. Only the usual questions about what are the use cases/benefits? what does it provide that can't be written now/only written clumsily? how does it work? what complications does the user need to understand? what complications does the compiler need to understand? > of "make global things possible locally" proposals. There are pretty clear semantics for how it works in all cases. Then it should be easy for someone to write up a proposal on github. I've seen plenty of "make global things possible locally" proposals. None of them have given a coherent explanation for how the local thing is to behave when something containing it or mentioning it or bound to it gets exported globally. (For example with class instances; that's why Wadler made them global despite his initial proposal making them let-bound.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 00:22:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 00:22:25 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.413d685e7e5417a8769ed2825e99c0f4@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I would be fine with not bringing existentials into scope. It does mean that my original motivation for wanting to bring nested `forall`d variables into scope with `ScopedTypeVariables` would go away (in #14288). Of course, this would have the distinct upside that we could fix #14288 by changing no code and simply adding documentation, which is nice. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 00:33:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 00:33:46 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.e400f3a1551034c55c9a38093ce83398@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think it would be worthwhile to investigate this issue further (probably in another Trac ticket). My gut feeling is that Phab:D4264 is simple enough that we can adopt it without too much worry—worst comes to worst, we can scrap the current implementation of `typeToLHsType` in favor of something simpler later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 04:20:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 04:20:11 -0000 Subject: [GHC] #14505: CircleCI only builds pushed heads In-Reply-To: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> References: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> Message-ID: <061.01f85926ad72a289ad29c7ca6acc7cca@haskell.org> #14505: CircleCI only builds pushed heads -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chak): Seems like we can sidestep this issue by using GitHub PRs instead of direct pushing to master, as per https://mail.haskell.org/pipermail/ghc- devops-group/2017-December/000129.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 05:28:11 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 05:28:11 -0000 Subject: [GHC] #14505: CircleCI only builds pushed heads In-Reply-To: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> References: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> Message-ID: <061.3ebf8201a77fd8fb95120687ebe8d72d@haskell.org> #14505: CircleCI only builds pushed heads -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Does this mean that contributors with commit rights will have to create a separate GitHub PR for each commit that we want to push? Or one for each set of somehow connected commits? And will these commits eventually enter `master` with the same git commit id? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 10:33:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 10:33:52 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.03c14818e962e1d95063934c6341bf57@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Add a -v3 to ghc to see what's happening when it fails -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 11:08:46 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 11:08:46 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.0a5b90bc0a250260bd6af4d9c46bfe54@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johndoe): Could you tell where exactly I should add `-v3`, as I do not call ghc directly? I can use `stack` or `cabal install`, but I simply do not know if I need to add `-v3` somewhere in config files, or specify in commandline. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 11:11:04 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 11:11:04 -0000 Subject: [GHC] #14505: CircleCI only builds pushed heads In-Reply-To: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> References: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> Message-ID: <061.635c0f069e1d1bd1b30b9bed8680a92b@haskell.org> #14505: CircleCI only builds pushed heads -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Replying to [comment:4 chak]: > Seems like we can sidestep this issue by using GitHub PRs instead of direct pushing to master, as per https://mail.haskell.org/pipermail/ghc- devops-group/2017-December/000129.html Does this mean that the builders will not run on differentials? This seems like a very serious flaw if so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 11:15:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 11:15:21 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.198d624a112215fbc468aaf00bb0fac6@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): `cabal install -v3` should work, you can also try `cabal install --ghc- option=-v3`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 11:48:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 11:48:02 -0000 Subject: [GHC] #14552: GHC panic on pattern synonym In-Reply-To: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> References: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> Message-ID: <066.15e8e648309bb842dca234af830d18e6@haskell.org> #14552: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms, TypeInType, | ViewPatterns Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Let's make it even simpler. Use Richard's data type `T`, and consider {{{ {-# LANGUAGE ViewPatterns, RankNTypes, GADTs #-} module Foo where data T where T :: (forall a. Int -> a -> a) -> T g1 (T f) = (f 3 'c', f 3 True) g2 (T f) = let h = f 3 in (h 'c', h True) g3 (T (id -> f)) = (f 3 'c', f 3 True) g4 (T ((\f -> f 3) -> h)) = (h 'c', h True) }}} Here we get * `g1` typechecks because `f` is bound to a polymorphic function. * `g2` does not typecheck, because the binding of `h` is not generalised (we have `MonoLocalBinds` when `GADTs` is on). So `h` is monomorphic. * `g3` does not typecheck for the same reason. It's akin to `g2` with `h = id f`; it desugars to something like {{{ g3 (T ff) = let f = id ff in (f 3 'c', f 3 True) }}} * `g4` does not typecheck for the same reason. It desugars to something like {{{ g4 (T ff) = let h = (\f -> f 3) ff in (h 'c', h True) }}} So I don't think this has anything to do with the impredicativity magic for `($)`. It's just that binding a polymorphic variable in a pattern is a very delicate business. One could imagine generalising those extra let-bindings in the desugarings of `g3` and `g4`, but would be hard to do reliably -- that is why we have `MonoLocalBinds`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 11:52:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 11:52:33 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.52be2ac8b0c71c295bcaa78a2dbf100f@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by johndoe): Thanks. See log here https://ci.appveyor.com/project/johnd0e/pandoc/build/1.0.95 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 11:52:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 11:52:55 -0000 Subject: [GHC] #14515: "Same" higher-rank kind synonyms behave differently In-Reply-To: <051.ddfbd3b154f112afe25d8aace589b1bc@haskell.org> References: <051.ddfbd3b154f112afe25d8aace589b1bc@haskell.org> Message-ID: <066.c8d1bab9923e4233afcae8d750a5645e@haskell.org> #14515: "Same" higher-rank kind synonyms behave differently -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T14515 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => polykinds/T14515 * resolution: => fixed Comment: Great examples! Fixed by {{{ commit 68149452a793aedd8d468b689dc93fb2ba5ec436 Author: Simon Peyton Jones Date: Fri Dec 15 09:29:12 2017 +0000 Fix tcDataKindSig This patch fixes an outright bug in tcDataKindSig, shown up in Trac of a data type declaration. See Note [TyConBinders for the result kind signature of a data type] I also took the opportunity to elminate the DataKindCheck argument and data type from tcDataKindSig, instead moving the check to the call site, which is easier to understand. >--------------------------------------------------------------- 68149452a793aedd8d468b689dc93fb2ba5ec436 compiler/typecheck/TcHsType.hs | 126 +++++++++++++++++------------ compiler/typecheck/TcInstDcls.hs | 20 ++--- compiler/typecheck/TcTyClsDecls.hs | 22 +++-- compiler/types/Type.hs | 16 +--- testsuite/tests/ghci/scripts/T13407.stdout | 2 +- testsuite/tests/polykinds/T14515.hs | 13 +++ testsuite/tests/polykinds/all.T | 1 + 7 files changed, 116 insertions(+), 84 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 12:20:21 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 12:20:21 -0000 Subject: [GHC] #14552: GHC panic on pattern synonym In-Reply-To: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> References: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> Message-ID: <066.c7e7e363b408c0ee2f101728b774af8d@haskell.org> #14552: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: | PatternSynonyms, TypeInType, | ViewPatterns Operating System: 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): PS > Interestingly, matcher2 does not type check without this inlining: It does for me! {{{ matcher3 (T (($ 3) -> x)) k = k x }}} typechecks just fine with inferred type {{{ matcher3 :: forall a t. T -> ((a -> a) -> t) -> t }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 12:58:23 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 12:58:23 -0000 Subject: [GHC] #14572: Document for writing GHC-based compiler In-Reply-To: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> References: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> Message-ID: <059.0a2d246a57afac864d860179367d0b2a@haskell.org> #14572: Document for writing GHC-based compiler -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zaoqi): Replying to [comment:1 bgamari]: > Does wiki:Commentary/Compiler/API help? It doesn't -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 14:37:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 14:37:34 -0000 Subject: [GHC] #14572: Document for writing GHC-based compiler In-Reply-To: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> References: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> Message-ID: <059.c61ea939ec43b25caae1e25450ccc0c0@haskell.org> #14572: Document for writing GHC-based compiler -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Does https://github.com/nomeata/veggies serve as an example of writing your own Core→LLVM compiler, and resuing GHC for the rest? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 14:52:18 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 14:52:18 -0000 Subject: [GHC] #14572: Document for writing GHC-based compiler In-Reply-To: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> References: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> Message-ID: <059.a2e9afdc07ec829963f93d0c409d33d7@haskell.org> #14572: Document for writing GHC-based compiler -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zaoqi): Replying to [comment:3 nomeata]: > Does https://github.com/nomeata/veggies serve as an example of writing your own Core→LLVM compiler, and resuing GHC for the rest? I want to write Core→Lisp compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 15:35:37 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 15:35:37 -0000 Subject: [GHC] #14572: Document for writing GHC-based compiler In-Reply-To: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> References: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> Message-ID: <059.849455d87e209056d2bcc8f79f0c0193@haskell.org> #14572: Document for writing GHC-based compiler -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It looks like nomeata's `veggies` would be a great start in that case. It looks like https://github.com/nomeata/veggies/blob/master/Veggies/CodeGen.hs may be a good place to start looking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 17:01:44 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 17:01:44 -0000 Subject: =?utf-8?b?W0dIQ10gIzE0NTgzOiBEb27igJl0IHVzZSBgU3RyaW5nYCB3aGVu?= =?utf-8?q?_generating_code?= Message-ID: <047.7951ca03cb8a2da2a04a92c46c30ba1d@haskell.org> #14583: Don’t use `String` when generating code -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (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: -------------------------------------+------------------------------------- GHC uses `String` when generating code, which is very slow. It would be much better to switch to `Data.ByteString.Builder`, or better yet output executables directly rather than going through an assembler. This applies to both the native and LLVM code generators. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 17:07:01 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 17:07:01 -0000 Subject: [GHC] #14584: Core Lint error Message-ID: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language PartialTypeSignatures #-} {-# Language TypeFamilyDependencies, KindSignatures #-} {-# Language PolyKinds #-} {-# Language DataKinds #-} {-# Language TypeFamilies #-} {-# Language RankNTypes #-} {-# Language NoImplicitPrelude #-} {-# Language FlexibleContexts #-} {-# Language MultiParamTypeClasses #-} {-# Language GADTs #-} {-# Language ConstraintKinds #-} {-# Language FlexibleInstances #-} {-# Language TypeOperators #-} {-# Language ScopedTypeVariables #-} {-# Language DefaultSignatures #-} {-# Language FunctionalDependencies #-} {-# Language UndecidableSuperClasses #-} {-# Language UndecidableInstances #-} {-# Language TypeInType #-} {-# Language AllowAmbiguousTypes #-} {-# Language InstanceSigs, TypeApplications #-} import Data.Monoid import Data.Kind data family Sing (a::k) class SingKind k where type Demote k = (res :: Type) | res -> k fromSing :: Sing (a::k) -> Demote k class SingI (a::k) where sing :: Sing a data ACT :: Type -> Type -> Type data MHOM :: Type -> Type -> Type type m ·- a = ACT m a -> Type type m ·-> m' = MHOM m m' -> Type class Monoid m => Action (act :: m ·- a) where act :: m -> (a -> a) class (Monoid m, Monoid m') => MonHom (mhom :: m ·-> m') where monHom :: m -> m' data MonHom_Distributive m :: (m ·- a) -> (a ·-> a) type Good k = (Demote k ~ k, SingKind k) instance (Action act, Monoid a, Good m) => MonHom (MonHom_Distributive m act :: a ·-> a) where monHom :: a -> a monHom = act @_ @_ @act (fromSing @m (sing @m @a :: Sing _)) where }}} fails on 8.2.1 and 8.3.20171208 when passed `-fdefer-type-errors -dcore- lint`, full log attached {{{ $ ghci -ignore-dot-ghci -fdefer-type-errors -dcore-lint 146-bug.hs GHCi, version 8.3.20171208: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 146-bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (after optimization) *** : warning: In the expression: fromSing @ m_a2Ju ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 17:07:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 17:07:25 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2314585=3A_Consider_doing_a_CPS=E2=86=92SSA?= =?utf-8?q?_conversion_in_the_backend?= Message-ID: <047.6108284ef723b4e4972bd53685686aa4@haskell.org> #14585: Consider doing a CPS→SSA conversion in the backend -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC currently uses CPS when generating code. This is difficult to map to LLVM, and even in the NCG may result in suboptimal use of the CPU, since CPUs are optimized for C-like languages. It might be worthwhile to convert from CPS to SSA form in the backend and then optimize ''that''. This would require a bunch of changes to the RTS, and add an entire new IR, but could enable optimizations that would otherwise be impossible. To avoid a big compile-time regression, the SSA IR should be represented as a flat array, rather than a sea of linked nodes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 17:08:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 17:08:08 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.bfac2172eae2d142268d1fa069b7dc34@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "14584.log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 17:08:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 17:08:25 -0000 Subject: [GHC] #14586: ARM and ARM64 NCG Message-ID: <047.025c7cd51841b67644346978775d5a0d@haskell.org> #14586: ARM and ARM64 NCG -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a feature request for an ARM and ARM64 NCG. This will vastly speed up compile time for those targeting mobile devices. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 17:13:24 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 17:13:24 -0000 Subject: [GHC] #14587: Unidirectional pattern signatures do not need to be invariant w.r.t. higher-rank polymorphism Message-ID: <047.5e8567ed0f3135297e48835bccb037c1@haskell.org> #14587: Unidirectional pattern signatures do not need to be invariant w.r.t. higher-rank polymorphism -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Best explained by example: {{{#!hs data T = MkT (forall a. a -> a) pattern PT :: (Int -> Int) -> T pattern PT x <- MkT x }}} This looks perfectly reasonable to me. And the hand-written matcher is also accepted. Note that a similar bidirectional pattern synonym should indeed be rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 17:16:15 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 17:16:15 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.efdc26825ce86ca2fd797eb9a8fa58b6@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: 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, DeferredTypeErrors -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 18:55:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 18:55:42 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.9b648134cac63334d1a48f4ff9996261@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: #13059 | Differential Rev(s): Phab:D2304 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 19:30:33 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 19:30:33 -0000 Subject: [GHC] #11203: Kind inference with SigTvs is wrong In-Reply-To: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> References: <047.63429af2d1e56b0df65904b5eee5f8ef@haskell.org> Message-ID: <062.e0fc3e148ccd31d23173def870217061@haskell.org> #11203: Kind inference with SigTvs is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11203 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"3910d3e2f8b3084f6f6de3d9aeb8d8ed20670245/ghc" 3910d3e2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3910d3e2f8b3084f6f6de3d9aeb8d8ed20670245" Add some commentary re: fix to #11203 The fix for #11203 prohibits duplicate SigTvs in non-CUSK kind signatures by checking for duplicates after type inference is done. This works well. GHC also checks for duplicate SigTvs after working with partial type signatures (another place where SigTvs arise). However, neither fix eliminates this whole class of problems (because doing so would be heavier than we would like). So, this comment adds a warning to users of newSigTyVar to be aware of problems with duplicates. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 15 23:04:57 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Dec 2017 23:04:57 -0000 Subject: [GHC] #14587: Unidirectional pattern signatures do not need to be invariant w.r.t. higher-rank polymorphism In-Reply-To: <047.5e8567ed0f3135297e48835bccb037c1@haskell.org> References: <047.5e8567ed0f3135297e48835bccb037c1@haskell.org> Message-ID: <062.8ab3c9e9e0623d8f52a07589e319d9c8@haskell.org> #14587: Unidirectional pattern signatures do not need to be invariant w.r.t. higher-rank polymorphism -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => duplicate Comment: This works fine in HEAD. It's a dup of #13752, which I fixed in May. I marked it as "merge" but I don't know if it actually got merged into 8.2. Perhpas not. Anyway I claim it's fine now. Re-open if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 01:49:41 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 01:49:41 -0000 Subject: [GHC] #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns Message-ID: <048.5b1c9ce58b11d50f9bba53c8d62c92a6@haskell.org> #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns -------------------------------------+------------------------------------- Reporter: kmiyazato | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Bang patterns occurring in let-bindings are allowed even if -XBangPatterns extension is not enabled. {{{#!hs -- Compile error in 8.0.2 -- Compiles in 8.2.1 and 8.2.2 main = print (let !x = 1 + 2 in x) }}} {{{#!hs -- Compile error in all of 8.0.2, 8.2.1, and 8.2.2 main = print (let f !x !y = x + y in f 1 2) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 02:07:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 02:07:49 -0000 Subject: [GHC] #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all In-Reply-To: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> References: <045.ecd7af4f53d7df1147bf6a068ec1e485@haskell.org> Message-ID: <060.f4bbd22b413529f54626d7e17cca6127@haskell.org> #8272: testing if SpLim=$rbp and Sp=$rsp changed performance at all -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | callingConvention Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollu): * cc: bollu (added) Comment: CCing myself in light of some [https://github.com/bollu/simplexhc-cpp simplexhc] experiments. On ackermann function, [https://gist.github.com/bgamari/bd424e82d96ddb7b9e67c5e51cdcc5ec GHC and clang O3 don't scale linearly]. On teaching simplexhc to generate C-like code (using `call/ret` instead of custom stack frame management), I began getting C-like performance on the same examples. Previously, I was around GHC, or somewhat slower. [https://gist.github.com/bollu/a59c3c8d2c193e2d63409064b6d855c3 Link to numbers from that experiment here]. I sent out an e-mail to LLVM-dev, asking if it is possible to fake GHC- like "custom call stack on the heap" within LLVM. If possible, I'd like to implement that and check for slowdowns in C code. That should provide some data of the benefits of choosing to use the native call stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 10:39:36 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 10:39:36 -0000 Subject: [GHC] #14589: The isUpper function should return true for the '\9438' character Message-ID: <045.be5986892fedcb0c824c473665b75261@haskell.org> #14589: The isUpper function should return true for the '\9438' character -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.2.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ λ> toLower '\9438' '\9438' λ> toUpper '\9438' '\9412' λ> isUpper '\9438' False λ> isLower '\9438' False }}} Here we can observe a contradiction. The `toLower` function does not alter its argument, but `toUpper` does, which tells us that the character 1) has the notion of case 2) it must be lower-cased. On the other hand, both `isUpper` and `isLower` functions return `False` for `\9438` suggesting that it has no notion of case. Apparently, `\9438` is lower-cased and `\9412` is its upper-cased version indeed: {{{ λ> putStrLn "\9438" ⓞ λ> putStrLn "\9412" Ⓞ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 10:40:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 10:40:55 -0000 Subject: [GHC] #14589: The isUpper function should return true for the '\9438' character In-Reply-To: <045.be5986892fedcb0c824c473665b75261@haskell.org> References: <045.be5986892fedcb0c824c473665b75261@haskell.org> Message-ID: <060.c244329b66a9c237ee9fffceac112606@haskell.org> #14589: The isUpper function should return true for the '\9438' character -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | 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 int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 13:16:13 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 13:16:13 -0000 Subject: [GHC] #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns In-Reply-To: <048.5b1c9ce58b11d50f9bba53c8d62c92a6@haskell.org> References: <048.5b1c9ce58b11d50f9bba53c8d62c92a6@haskell.org> Message-ID: <063.c2709a88e9c4d1348fc27c8976f4ed01@haskell.org> #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns -------------------------------------+------------------------------------- Reporter: kmiyazato | 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: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: bgamari (added) Comment: This behavior was introduced in 372995364c52eef15066132d7d1ea8b6760034e6 (`Treat banged bindings as FunBinds`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 13:56:02 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 13:56:02 -0000 Subject: [GHC] #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns In-Reply-To: <048.5b1c9ce58b11d50f9bba53c8d62c92a6@haskell.org> References: <048.5b1c9ce58b11d50f9bba53c8d62c92a6@haskell.org> Message-ID: <063.f5c46a934f4fdfcbb281a6ab8ac895da@haskell.org> #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns -------------------------------------+------------------------------------- Reporter: kmiyazato | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4270 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4270 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 14:32:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 14:32:16 -0000 Subject: [GHC] #13418: IndexError: pop from empty list In-Reply-To: <043.6a7d3c036ffaf65828210982a9855ffa@haskell.org> References: <043.6a7d3c036ffaf65828210982a9855ffa@haskell.org> Message-ID: <058.151905d087bff9cc6ab7d49e6dbf12e5@haskell.org> #13418: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: ralf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14294 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14294 Comment: There are several duplicates of this issue, so I'll close this in favor of #14294. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 14:32:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 14:32:38 -0000 Subject: [GHC] #13627: IndexError: pop from empty list In-Reply-To: <046.4bbf0226d456473b81ceb192cece0d5c@haskell.org> References: <046.4bbf0226d456473b81ceb192cece0d5c@haskell.org> Message-ID: <061.b1d99e59391cf7dfd11bfe7ed269cd2b@haskell.org> #13627: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: Lemming | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14294 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14294 Comment: There are several duplicates of this issue, so I'll close this in favor of #14294. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 14:33:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 14:33:17 -0000 Subject: [GHC] #14540: IndexError: pop from empty list In-Reply-To: <046.d5b9a5e6c04c98d634ef1167801af522@haskell.org> References: <046.d5b9a5e6c04c98d634ef1167801af522@haskell.org> Message-ID: <061.cd4f7254256f8cb0ba9f736dadd42e3b@haskell.org> #14540: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: Lemming | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14294 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14294 Comment: There are several duplicates of this issue, so I'll close this in favor of #14294. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 14:58:49 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 14:58:49 -0000 Subject: [GHC] #14589: The isUpper function should return true for the '\9438' character In-Reply-To: <045.be5986892fedcb0c824c473665b75261@haskell.org> References: <045.be5986892fedcb0c824c473665b75261@haskell.org> Message-ID: <060.466263fdb5c3850feb3091c42da02af6@haskell.org> #14589: The isUpper function should return true for the '\9438' character -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): This is documented behavior. `isUpper` says: > Selects upper-case or title-case alphabetic Unicode characters (letters). Title case is used by a small number of letter ligatures like the single-character form of Lj. Note that is says “letter”, and the code in libraries/base/cbits/WCsubst.c explicitly selects only uppper-case and title-case letters. I see how this is a bit unfortunate, but I am sure we should not change the semantics of `isUpper` . Maybe we are missing a function? `isUpperAnything` or something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 15:41:38 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 15:41:38 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.b704257a2ebc21898388da5938e10615@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14498 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I had been pushing for this change since I was convinced it was necessary to bring into scope the existentially quantified type variables in pattern synonym type signatures. But the discussion in #14498 has marched in the opposite direction (in particular, see https://ghc.haskell.org/trac/ghc/ticket/14498#comment:16). There, the consensus seems to be that we should //not// bring into scope these existentially quantified variables. In light of this, my original motivation for pursuing this ticket has disappeared, so I think we should go with the plan in comment:5 and document the current behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 15:58:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 15:58:47 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.146e91f9e51a3a5fe0f63b31bf8542f8@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14498 | Differential Rev(s): Phab:D4272 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4272 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 19:54:53 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 19:54:53 -0000 Subject: [GHC] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match In-Reply-To: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> References: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> Message-ID: <065.7aea9b2620788a8676c164b1376ccafa@haskell.org> #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lippling): Ok, I found a minimal example: {{{ {-# LANGUAGE ApplicativeDo #-} x = do [_] <- undefined -- the list is the problem undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 20:58:58 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 20:58:58 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables In-Reply-To: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> References: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> Message-ID: <062.fe0bedd02036dc21e7fbc5bc8c560c82@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: stusmith | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1316, #3691, | Differential Rev(s): #11438, #10581, #11539, #12716 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * owner: (none) => kanetw Comment: Working on this, but it seems pretty complicated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 22:03:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 22:03:44 -0000 Subject: [GHC] #14590: Sectioned hole oddities Message-ID: <050.776bcc337458e90ceae6ff94ddc5ed3d@haskell.org> #14590: Sectioned hole oddities -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13050 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #13050 added support for infix holes. However, it seems that the same support was not added for //sectioned// holes, as the following two examples demonstrate: Left-sectioned holes technically work, although they are pretty-printed poorly: {{{#!hs f :: Int -> Int -> Int f x y = (x `_`) y }}} {{{ GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:2:12: error: • Found hole: _ :: Int -> Int -> Int • In the expression: _ In the expression: \ x_ -> _ x x_ ) In the expression: ( \ x_ -> _ x x_ )) y • Relevant bindings include y :: Int (bound at Bug.hs:2:5) x :: Int (bound at Bug.hs:2:3) f :: Int -> Int -> Int (bound at Bug.hs:2:1) | 2 | f x y = (x `_`) y | ^^^ }}} Notice the messy `In the expression: \ x_ -> _ x x_ )` part. Right-sectioned holes don't even parse at all: {{{#!hs f :: Int -> Int -> Int f x y = (`_` x) y }}} {{{ GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:2:11: error: parse error on input ‘_’ | 2 | f x y = (`_` x) y | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 16 22:09:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Dec 2017 22:09:56 -0000 Subject: [GHC] #14590: Sectioned hole oddities In-Reply-To: <050.776bcc337458e90ceae6ff94ddc5ed3d@haskell.org> References: <050.776bcc337458e90ceae6ff94ddc5ed3d@haskell.org> Message-ID: <065.c3666f7d3b297967b6d37b94f0e0b7e4@haskell.org> #14590: Sectioned hole oddities -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13050 | Differential Rev(s): Phab:D4273 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4273 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 17 04:24:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Dec 2017 04:24:04 -0000 Subject: [GHC] #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns In-Reply-To: <048.5b1c9ce58b11d50f9bba53c8d62c92a6@haskell.org> References: <048.5b1c9ce58b11d50f9bba53c8d62c92a6@haskell.org> Message-ID: <063.c35b4867adc1801e1086b1efacdb4105@haskell.org> #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns -------------------------------------+------------------------------------- Reporter: kmiyazato | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4270 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The sort of things that sneak through our testsuite never ceases to amaze me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 17 04:49:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Dec 2017 04:49:23 -0000 Subject: [GHC] #14572: Document for writing GHC-based compiler In-Reply-To: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> References: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> Message-ID: <059.799cb76c44866d95362cf43f56b458a4@haskell.org> #14572: Document for writing GHC-based compiler -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zaoqi): Replying to [comment:5 bgamari]: > It looks like nomeata's `veggies` would be a great start in that case. It looks like https://github.com/nomeata/veggies/blob/master/Veggies/CodeGen.hs may be a good place to start looking. Do let us know if there are any specific questions. Is there document for Core? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 17 06:50:55 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Dec 2017 06:50:55 -0000 Subject: [GHC] #14572: Document for writing GHC-based compiler In-Reply-To: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> References: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> Message-ID: <059.c8829230861de83e6f39df67b0c40347@haskell.org> #14572: Document for writing GHC-based compiler -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Is there document for Core? The [[https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/CoreSynType|GHC commentary]] has a number of references. There is also the [[https://www.microsoft.com/en-us/research/publication/system-f-with-type- equality-coercions/|System FC paper]] although it may be a bit dense to start with. The Notes in `compiler/coreSyn/CoreSyn.hs` are also quite helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 17 08:16:03 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Dec 2017 08:16:03 -0000 Subject: [GHC] #14591: HEAD panic: tcSyntaxOp "noSyntaxExpr" Message-ID: <049.22e0e53f0ab2ad82495c3c7f4deb03a8@haskell.org> #14591: HEAD panic: tcSyntaxOp "noSyntaxExpr" -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program triggers a bug in 8.2.2 and 8.5.20171215. {{{#!hs -- Checks that the ordering constraint on the groupWith function is respected {-# OPTIONS_GHC -XMonadComprehensions -XTransformListComp #-} module ShouldFail where import GHC.Exts (groupWith) data Unorderable = Gnorf | Pinky | Brain foo = [ () | Gnorf <- [Gnorf, Brain] , then group by x using groupWith ] }}} Reproduce: {{{ ghc bug.hs }}} Output: {{{ [1 of 1] Compiling ShouldFail ( bug.hs, bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.5.20171215 for x86_64-unknown-linux): tcSyntaxOp "noSyntaxExpr" Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcExpr.hs:1436:31 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 Sun Dec 17 08:16:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Dec 2017 08:16:25 -0000 Subject: [GHC] #14591: HEAD panic: tcSyntaxOp "noSyntaxExpr" In-Reply-To: <049.22e0e53f0ab2ad82495c3c7f4deb03a8@haskell.org> References: <049.22e0e53f0ab2ad82495c3c7f4deb03a8@haskell.org> Message-ID: <064.d1ebd4347eabf7f9d939baa5afb549c5@haskell.org> #14591: HEAD panic: tcSyntaxOp "noSyntaxExpr" -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tianxiaogu): * Attachment "bug.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 17 13:12:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Dec 2017 13:12:05 -0000 Subject: [GHC] #14592: Totality checking Message-ID: <045.248ecf06ff86b05ee9f7ac04c7a37292@haskell.org> #14592: Totality checking -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example of that is Idris totality checking (http://docs.idris- lang.org/en/latest/tutorial/theorems.html#sect-totality). This feature could be started as a very specific types of pure functions which could be found to be total for sure and improve it in time. I'm putting a ticket for discussion here, because I didn't find any ticket related to that in GHC Trac. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 17 16:57:40 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Dec 2017 16:57:40 -0000 Subject: [GHC] #14593: Allow deprecation notices for type and data constructors separately Message-ID: <050.899ceaee488f47f1935b8456b2893b32@haskell.org> #14593: Allow deprecation notices for type and data constructors separately -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The [https://downloads.haskell.org/~ghc/8.2.2/docs/html/users_guide/glasgow_exts.html #warning-and-deprecated-pragmas syntax for deprecations] only allows you to provide a single message for deprecations: > You can only attach to entities declared at top level in the module being compiled, and you can only use unqualified names in the list of entities. A capitalised name, such as T refers to either the type constructor T or the data constructor T, or both if both are in scope. If both are in scope, there is currently no way to specify one without the other (c.f. fixities Infix type constructors, classes, and type variables). It would be nice to provide separate messages in deprecations for type and data constructors. As an example, I am making a breaking change to a library, and I am providing deprecated shims for backwards-compatibility: {{{ -- Old: data SomeField rec where SomeField :: EntityField rec field -> SomeField rec -- New: data UpdateCollision rec where CopyField :: EntityField rec field -> UpdateCollision rec CopyUnless :: -- etc... type SomeField = UpdateCollision {-# DEPRECATED SomeField "The SomeField type was renamed to UpdateCollision." #-} pattern SomeField :: EntityField record typ -> SomeField record pattern SomeField x = CopyField x {-# DEPRECATED SomeField "The constructor SomeField is deprecated. Use the function copyField instead." #-} }}} The workaround is to provide a longer error message that combines the two. This is less pleasant than having separate notices, because it makes it less obvious for the client how to migrate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 00:37:59 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 00:37:59 -0000 Subject: [GHC] #14593: Allow deprecation notices for type and data constructors separately In-Reply-To: <050.899ceaee488f47f1935b8456b2893b32@haskell.org> References: <050.899ceaee488f47f1935b8456b2893b32@haskell.org> Message-ID: <065.4310cb1229e2ca9deca93ece3155b16c@haskell.org> #14593: Allow deprecation notices for type and data constructors separately -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: new 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): There was a recent GHC proposal that asked for that, and it got accepted, so someone just has to implement it: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008 -type-infix.rst -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 00:44:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 00:44:46 -0000 Subject: [GHC] #14593: Allow deprecation notices for type and data constructors separately In-Reply-To: <050.899ceaee488f47f1935b8456b2893b32@haskell.org> References: <050.899ceaee488f47f1935b8456b2893b32@haskell.org> Message-ID: <065.3e24e9d40b549e905aa1d1a859e447ff@haskell.org> #14593: Allow deprecation notices for type and data constructors separately -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: new 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by parsonsmatt): Ah, nice! I'll close this out then :) Thanks for the pointer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 00:45:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 00:45:12 -0000 Subject: [GHC] #14593: Allow deprecation notices for type and data constructors separately In-Reply-To: <050.899ceaee488f47f1935b8456b2893b32@haskell.org> References: <050.899ceaee488f47f1935b8456b2893b32@haskell.org> Message-ID: <065.82e15dfab51ffa3719c2cf73142ae5aa@haskell.org> #14593: Allow deprecation notices for type and data constructors separately -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by parsonsmatt): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 06:22:08 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 06:22:08 -0000 Subject: [GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble In-Reply-To: <044.13612547bcec0532b940b49a41a2177d@haskell.org> References: <044.13612547bcec0532b940b49a41a2177d@haskell.org> Message-ID: <059.bee58659f047e85db0fd06e643059036@haskell.org> #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): I now have a patch that validates on `ghc-8.4` and `master`. Changing it to `type Uniq = Integer` turned out to be easiest because GHC doesn't know the data constructor for `Int64`. And I think `Integer` is actually more appropriate here. Some of the other types in the TH library are still machine sized, like operator precedence, but I think those don't lead to many problems in practice, since they tend to be user supplied. I still need to do a bit more testing with GHCJS to make sure that I haven't missed anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 09:22:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 09:22:46 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables In-Reply-To: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> References: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> Message-ID: <062.f1136235f9e7dc739689f1569d474d20@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: stusmith | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: | TypeErrorMessages Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1316, #3691, | Differential Rev(s): #11438, #10581, #11539, #12716 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Before implementing much, it'd be good to write a specification of what you are trying to implement. I think it may be something like this: * When compiling without `-XScopedTypevariables`... * ...and type variable `a` ''would'' have been in scope if you were compiling ''with'' `-XScopedTypeVariables`... * ...and when you are about to add implicit quantification over `a` * ...then emit a warning Example {{{ f :: forall a. [a] -> [a] f = ....(let g :: a -> a g = ... in blah).... }}} With `-XScopedTypeVariables` the tyvar `a` would have been in scope in the body of `f`. Because it isn't in scope, we are going to implicitly quantify over `a` in the type signature for `g`, treating its signature as `g :: forall a. a->a`. That implicit quantification is what we want to warn about. Question: what if we had instead written {{{ f :: [a] -> [a] f = ....(let g :: a -> a g = ... in blah).... }}} Now, even with `-XScopedTypeVariables` the tyvar `a` would not be in scope. Do we want to warn then too? I guess so. Writing all this down, with a series of examples, would be helpful. I can see that it's a bit tricky to implement. We kind of need an extra set of tyvars that would be in scope if `-XScopedTypeVariables` was on, but aren't in scope because it isn't. Is it worth the fuss? Perhaps. Anyway, it'd be worth explaining your proposed implementation path before investing effort in implementing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 09:37:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 09:37:16 -0000 Subject: [GHC] #14572: Document for writing GHC-based compiler In-Reply-To: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> References: <044.733dc288fe7276f87962dd9de30ad192@haskell.org> Message-ID: <059.9c62804734af2632cbacc647d6f45738@haskell.org> #14572: Document for writing GHC-based compiler -------------------------------------+------------------------------------- Reporter: zaoqi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Is there document for Core? Actually Core is rather carefully documented. Look in [https://github.com/ghc/ghc/tree/master/docs/core-spec docs/core-spec]. For convenience (and against convention, since it's a generated file) there's a [https://github.com/ghc/ghc/blob/master/docs/core-spec/core- spec.pdf typeset PDF] there too. Richard wrote this document. I like to keep it up to date. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 09:39:25 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 09:39:25 -0000 Subject: [GHC] #14592: Totality checking In-Reply-To: <045.248ecf06ff86b05ee9f7ac04c7a37292@haskell.org> References: <045.248ecf06ff86b05ee9f7ac04c7a37292@haskell.org> Message-ID: <060.bf04b734ad458addc3d4ba5bf4eaf0bf@haskell.org> #14592: Totality checking -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): See [https://ucsd-progsys.github.io/liquidhaskell-blog/ Liquid Haskell] which includes a pretty good totality checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 10:55:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 10:55:19 -0000 Subject: [GHC] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match In-Reply-To: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> References: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> Message-ID: <065.d591a0a1b89c2ed64155e605489d2080@haskell.org> #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Works fine in HEAD. Perhaps the patch didn't get merged into 8.2? Ben? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 12:38:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 12:38:50 -0000 Subject: [GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build Message-ID: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> #14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I tested this from a brand new MacBook 15" with 8 threads x 2.8 GHz Intel Core i7 / 16 GB RAM on OS X: {{{ $ time stack build WARNING: /Users/kvanb/git/github-webhooks/github-webhooks.cabal was generated with a newer version of hpack, please upgrade and try again. github-webhooks-1.0.0: unregistering (local file changes: github- webhooks.cabal package.yaml spec/DecodeEventsSpec.hs spec/Spec.hs src/GitHub/Data/Webhooks...) github-webhooks-1.0.0: configure (lib) Configuring github-webhooks-1.0.0... github-webhooks-1.0.0: build (lib) Preprocessing library github-webhooks-1.0.0... [1 of 3] Compiling Paths_github_webhooks ( .stack- work/dist/x86_64-osx/Cabal-1.24.2.0/build/autogen/Paths_github_webhooks.hs, .stack-work/dist/x86_64-osx/Cabal-1.24.2.0/build/Paths_github_webhooks.o ) [2 of 3] Compiling GitHub.Data.Webhooks.Payload ( src/GitHub/Data/Webhooks/Payload.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.2.0/build/GitHub/Data/Webhooks/Payload.o ) [3 of 3] Compiling GitHub.Data.Webhooks.Events ( src/GitHub/Data/Webhooks/Events.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.2.0/build/GitHub/Data/Webhooks/Events.o ) github-webhooks-1.0.0: copy/register Installing library in /Users/kvanb/git/github-webhooks/.stack- work/install/x86_64-osx/lts-9.18/8.0.2/lib/x86_64-osx-ghc-8.0.2/github- webhooks-1.0.0-LDmeffpkXvwH6ZXCPE95ke Registering github-webhooks-1.0.0... real 2m49.342s user 2m42.441s sys 0m5.805s }}} Source code has about 30 derivations of the form: {{{#!hs type IssueState = Text data HookIssue = HookIssue { whIssueUrl :: !URL , whIssueLabelsUrl :: !URL , whIssueCommentsUrl :: !URL , whIssueEventsUrl :: !URL , whIssueHtmlUrl :: !URL , whIssueId :: !Int , whIssueNumber :: !Int , whIssueTitle :: !Text , whIssueUser :: !HookUser , whIssueLabels :: !(Vector HookIssueLabels) , whIssueState :: IssueState , whIssueIsLocked :: !Bool , whIssueAssignee :: !(Maybe HookUser) , whIssueMilestone :: !(Maybe HookMilestone) , whIssueCommentCount :: !Int , whIssueCreatedAt :: !UTCTime , whIssueUpdatedAt :: !UTCTime , whIssueClosedAt :: !(Maybe UTCTime) , whIssueBody :: !Text } deriving (Eq, Show, Typeable, Data, Generic) instance NFData HookIssue where rnf = genericRnf }}} Steps to reproduce 1. clone https://github.com/onrock-eng/github-webhooks 2. checkout sha 40a7ecc3a5845717055ee372b89e645a498cf1e2 3. time stack build This is really ''really'' ''**really**'' slow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 12:40:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 12:40:41 -0000 Subject: [GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build In-Reply-To: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> References: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> Message-ID: <061.bb1ce6f927ce5197de497d863e24af63@haskell.org> #14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by schyler): * version: 8.2.1 => 8.0.2 Comment: {{{ $ stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 14:20:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 14:20:01 -0000 Subject: [GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble In-Reply-To: <044.13612547bcec0532b940b49a41a2177d@haskell.org> References: <044.13612547bcec0532b940b49a41a2177d@haskell.org> Message-ID: <059.ff2ab57caa574f1a7bd90c36a8d82507@haskell.org> #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:5 luite]: > Changing it to `type Uniq = Integer` turned out to be easiest because GHC doesn't know the data constructor for `Int64`. What do you mean by this? > And I think `Integer` is actually more appropriate here. I'm sure `Integer` technically works, but I am worried that we'd lose some efficiency by doing this, given how widely used `Name`s are in Template Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 14:34:47 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 14:34:47 -0000 Subject: [GHC] #14595: Can't build Sphinx HTML docs on GHC HEAD Message-ID: <050.bd5e9503d545bb9f916c73e213c2119f@haskell.org> #14595: Can't build Sphinx HTML docs on GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.3 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: -------------------------------------+------------------------------------- Attempting to build the Sphinx HTML documentation (i.e., putting `BUILD_SPHINX_HTML = YES` in one's `mk/build.mk` file) using the latest GHC HEAD (commit 3910d3e2f8b3084f6f6de3d9aeb8d8ed20670245) immediately fails: {{{ $ make ===--- 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 make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all /usr/bin/sphinx-build -b html -d docs/users_guide/.doctrees-html -D latex_paper_size=letter docs/users_guide docs/users_guide/build- html/users_guide Running Sphinx v1.2.2 Exception occurred: File "conf.py", line 29, in """.format(llvm_version=ghc_config.llvm_version) AttributeError: 'module' object has no attribute 'llvm_version' The full traceback has been saved in /tmp/sphinx-err-DVajkq.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at . Thanks! make[1]: *** [docs/users_guide/build-html/users_guide/index.html] Error 1 make: *** [all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 14:43:46 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 14:43:46 -0000 Subject: [GHC] #14595: Can't build Sphinx HTML docs on GHC HEAD In-Reply-To: <050.bd5e9503d545bb9f916c73e213c2119f@haskell.org> References: <050.bd5e9503d545bb9f916c73e213c2119f@haskell.org> Message-ID: <065.205d440379b36bc0edb276c44266d3e1@haskell.org> #14595: Can't build Sphinx HTML docs on GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: bgamari (added) Comment: Commit d4c8d895a477e66cc5d892de7d5f06a4068f9244 (`users-guide: Consistently document LLVM version requirement`) introduced this change. Ben, do you know what is happening here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 15:21:41 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 15:21:41 -0000 Subject: [GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build In-Reply-To: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> References: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> Message-ID: <061.ad0ff411fe85782ac06f7b1f815c0962@haskell.org> #14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think the resulting program after you expand the deriving clauses to source code will be many times bigger than 2500 lines. Is there something concrete you have identified as being unexpectedly slow? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 15:42:57 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 15:42:57 -0000 Subject: [GHC] #14595: Can't build Sphinx HTML docs on GHC HEAD In-Reply-To: <050.bd5e9503d545bb9f916c73e213c2119f@haskell.org> References: <050.bd5e9503d545bb9f916c73e213c2119f@haskell.org> Message-ID: <065.b2fd3728e2c6cc378941fad6936dbe7d@haskell.org> #14595: Can't build Sphinx HTML docs on GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Did you re-`boot` and `configure`? This symbol is defined by `docs/users- guide/ghc-conf.py` anwhich is generated by autoconf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 15:47:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 15:47:32 -0000 Subject: [GHC] #14591: HEAD panic: tcSyntaxOp "noSyntaxExpr" In-Reply-To: <049.22e0e53f0ab2ad82495c3c7f4deb03a8@haskell.org> References: <049.22e0e53f0ab2ad82495c3c7f4deb03a8@haskell.org> Message-ID: <064.28df8d07b8cbe534af3cc3ed4b2b0434@haskell.org> #14591: HEAD panic: tcSyntaxOp "noSyntaxExpr" -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"23b5b80418e219f0c0c27f0e37a08ccdc0045e87/ghc" 23b5b80/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="23b5b80418e219f0c0c27f0e37a08ccdc0045e87" Add missing case to HsExpr.isMonadFailStmtContext This fixes Trac #14591 I took the opportunity to delete the dead code isMonadCompExpr }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 15:58:58 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 15:58:58 -0000 Subject: [GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build In-Reply-To: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> References: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> Message-ID: <061.013ce647ee85190d3e2ad7be66a1e521@haskell.org> #14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this program produces some moderately large Core. {{{ *** Desugar [GitHub.Data.Webhooks.Events]: Result size of Desugar (after optimization) = {terms: 18,603, types: 76,783, coercions: 21,668, joins: 0/547} *** Desugar [GitHub.Data.Webhooks.Payload]: Result size of Desugar (after optimization) = {terms: 26,920, types: 195,711, coercions: 41,708, joins: 1/937} }}} Nearly all of this is derived bindings. It would be interesting to study which classes are contributing the most. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 16:02:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 16:02:44 -0000 Subject: [GHC] #14591: HEAD panic: tcSyntaxOp "noSyntaxExpr" In-Reply-To: <049.22e0e53f0ab2ad82495c3c7f4deb03a8@haskell.org> References: <049.22e0e53f0ab2ad82495c3c7f4deb03a8@haskell.org> Message-ID: <064.fac6b16147599aed7725f94c7d94d281@haskell.org> #14591: HEAD panic: tcSyntaxOp "noSyntaxExpr" -------------------------------------+------------------------------------- Reporter: tianxiaogu | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | rename/should_fail/T14591 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => rename/should_fail/T14591 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 16:05:01 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 16:05:01 -0000 Subject: [GHC] #14498: GHC internal error: "not in scope during TC but it passed the renamer" In-Reply-To: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> References: <051.b3a0bf5a82240883309588f58381ff3f@haskell.org> Message-ID: <066.5d6f6a0658af651d5f79d0ffc702db61@haskell.org> #14498: GHC internal error: "not in scope during TC but it passed the renamer" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | patsyn/should_fail/T14498 Blocked By: | Blocking: Related Tickets: #14288 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => patsyn/should_fail/T14498 * resolution: => fixed Comment: OK good. Fixed by {{{ commit f1fe5b4adf6a4094ecc600a28f64f7628903d017 Author: Simon Peyton Jones Date: Mon Dec 18 12:03:33 2017 +0000 Fix scoping of pattern-synonym existentials This patch fixes Trac #14998, where we eventually decided that the existential type variables of the signature of a pattern synonym should not scope over the pattern synonym. See Note [Pattern synonym existentials do not scope] in TcPatSyn. }}} Sorry about mis-typing the ticket number in the commit message! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 16:11:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 16:11:17 -0000 Subject: [GHC] #14595: Can't build Sphinx HTML docs on GHC HEAD In-Reply-To: <050.bd5e9503d545bb9f916c73e213c2119f@haskell.org> References: <050.bd5e9503d545bb9f916c73e213c2119f@haskell.org> Message-ID: <065.d75601a735aac1d375710471e40fddd0@haskell.org> #14595: Can't build Sphinx HTML docs on GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 8.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Aha, that did the trick. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 16:24:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 16:24:32 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.0fe0812668ce04866380c25c083de611@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4254 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"fb1f0a46983a887057de647eaaae9e83b5ebebd1/ghc" fb1f0a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fb1f0a46983a887057de647eaaae9e83b5ebebd1" Blackholes can be large objects (#14497) Test Plan: validate Reviewers: bgamari, niteria, erikd, dfeuer Reviewed By: dfeuer Subscribers: Yuras, dfeuer, rwbarton, thomie, carter GHC Trac Issues: #14497 Differential Revision: https://phabricator.haskell.org/D4254 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 17:06:07 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 17:06:07 -0000 Subject: [GHC] #14024: typechecker tests T13594 T13822 tc269 T13780c failing in devel2 flavour In-Reply-To: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> References: <043.b6a9b6292f832ebb52e568bfcb341f1b@haskell.org> Message-ID: <058.a00beee9fab57099f595a8b23bcb15d8@haskell.org> #14024: typechecker tests T13594 T13822 tc269 T13780c failing in devel2 flavour -------------------------------------+------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 17:20:27 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 17:20:27 -0000 Subject: [GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build In-Reply-To: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> References: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> Message-ID: <061.d5d9f215f410200358ef7ebe41a76e2f@haskell.org> #14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * owner: (none) => dfeuer Comment: I'll take a look today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 17:25:31 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 17:25:31 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.d3eb8d3614715428bfd931e79b1b5cf1@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: 14441 Related Tickets: #13643 | Differential Rev(s): Phab:D3848 Wiki Page: | -------------------------------------+------------------------------------- Old description: > This code > > {{{ > {-# LANGUAGE TypeInType, TypeFamilies, GADTs, ConstraintKinds #-} > > module T12919 where > > import Data.Kind > > data N = Z > > data V :: N -> Type where > VZ :: V Z > > type family VC (n :: N) :: Type where > VC Z = Type > > type family VF (xs :: V n) (f :: VC n) :: Type where > VF VZ f = f > > data Dict c where > Dict :: c => Dict c > > prop :: xs ~ VZ => Dict (VF xs f ~ f) > prop = Dict > }}} > > fails with this error: > > {{{ > T12919.hs:22:8: error: > • Couldn't match type ‘f’ with ‘VF 'VZ f’ > arising from a use of ‘Dict’ > ‘f’ is a rigid type variable bound by > the type signature for: > prop :: forall (xs :: V 'Z) f. xs ~ 'VZ => Dict VF xs f ~ f > at T12919.hs:21:9 > • In the expression: Dict > In an equation for ‘prop’: prop = Dict > • Relevant bindings include > prop :: Dict VF xs f ~ f (bound at T12919.hs:22:1) > }}} > > However, if I substitute `xs` with `VZ` (by hand) in the type of `prop`, > it compiles. Can be reproduced with GHC 8.0.1 but not HEAD. New description: This code {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, GADTs, ConstraintKinds #-} module T12919 where import Data.Kind data N = Z data V :: N -> Type where VZ :: V Z type family VC (n :: N) :: Type where VC Z = Type type family VF (xs :: V n) (f :: VC n) :: Type where VF VZ f = f data Dict c where Dict :: c => Dict c prop :: xs ~ VZ => Dict (VF xs f ~ f) prop = Dict }}} fails with this error: {{{ T12919.hs:22:8: error: • Couldn't match type ‘f’ with ‘VF 'VZ f’ arising from a use of ‘Dict’ ‘f’ is a rigid type variable bound by the type signature for: prop :: forall (xs :: V 'Z) f. xs ~ 'VZ => Dict VF xs f ~ f at T12919.hs:21:9 • In the expression: Dict In an equation for ‘prop’: prop = Dict • Relevant bindings include prop :: Dict VF xs f ~ f (bound at T12919.hs:22:1) }}} However, if I substitute `xs` with `VZ` (by hand) in the type of `prop`, it compiles. Can be reproduced with GHC 8.0.1 but not HEAD. -- Comment (by bgamari): A brief status update on this: Richard presented me with a patch fixing this a few months ago, giving me the task to reduce its footprint on compiler performance. He provided a few possible avenues for inquiry, a few of which I have explored. The result can be found on the `wip/T12919` branch. Unfortunately more performance improvement is necessary as several compiler performance testcases are still regressing in allocations by >50%. Sadly, I have recently lacked the time to dig back into the issue. Alex Vieth will be picking up the task shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 17:28:32 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 17:28:32 -0000 Subject: [GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble In-Reply-To: <044.13612547bcec0532b940b49a41a2177d@haskell.org> References: <044.13612547bcec0532b940b49a41a2177d@haskell.org> Message-ID: <059.5f69f968b3a5088a0807d0a0def8bdf6@haskell.org> #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): Replying to [comment:6 RyanGlScott]: > Replying to [comment:5 luite]: > > Changing it to `type Uniq = Integer` turned out to be easiest because GHC doesn't know the data constructor for `Int64`. > > What do you mean by this? GHC doesn't have the `GHC.Int.I64#` data constructor as a known name in `PrelNames` > > And I think `Integer` is actually more appropriate here. > > I'm sure `Integer` technically works, but I am worried that we'd lose some efficiency by doing this, given how widely used `Name`s are in Template Haskell. I think in practice it would not make much of a difference in situations that were already supported (i.e. target word size is the same as compiler word size). Only the `S#` constructor would be used (the library isn't compiled with `-funbox-strict-fields`). Maybe serialization would add an extra tag byte and there would be some additional unused branches in the code? Any suggestions for a good test case for the performance impact of this change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 17:30:35 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 17:30:35 -0000 Subject: [GHC] #14596: Remove uses of unsafeGlobalDynFlags for state hack Message-ID: <046.779bac3ba63546bc4a17b182b3ed3032@haskell.org> #14596: Remove uses of unsafeGlobalDynFlags for state hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently there are a variety of uses of the terrible `unsafeGlobalDynFlags` scattered about the compiler to implement `-fno- state-hack`. This global state makes parallel compilation unreliable and complicates API usage. Remove these uses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 17:50:23 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 17:50:23 -0000 Subject: [GHC] #14497: internal error: scavenge_one: strange object 19828 In-Reply-To: <044.d9e9a438baea314f437751a66a161d85@haskell.org> References: <044.d9e9a438baea314f437751a66a161d85@haskell.org> Message-ID: <059.4c0d6437ece54cc534454b0534f8a6e2@haskell.org> #14497: internal error: scavenge_one: strange object 19828 -------------------------------------+------------------------------------- Reporter: Yuras | Owner: simonmar Type: bug | Status: merge Priority: high | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4254 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 17:50:28 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 17:50:28 -0000 Subject: [GHC] #14596: Remove uses of unsafeGlobalDynFlags for state hack In-Reply-To: <046.779bac3ba63546bc4a17b182b3ed3032@haskell.org> References: <046.779bac3ba63546bc4a17b182b3ed3032@haskell.org> Message-ID: <061.92e665410a1a8804b9e201e407cf55ef@haskell.org> #14596: Remove uses of unsafeGlobalDynFlags for state hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4265 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: DemiMarie (added) * differential: => Phab:D4265 Comment: DemiMarie has a patch (Phab:D4265) implementing this. Unfortunately it's quite invasive. On the call Simon proposed an alternate way forward: rather than making the decision of whether to apply the state hack during simplification, instead push the decision up to the typechecker. The `State#` tycon would carry whether or not it should be considered for the state hack. Simonpj will likely pop up here and fill in more details later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 17:54:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 17:54:56 -0000 Subject: [GHC] #14597: Consider removing uses of unsafeGlobalDynFlags for -dppr-debug Message-ID: <046.8bf4cfdac6d0030c65afc2c4e39201e9@haskell.org> #14597: Consider removing uses of unsafeGlobalDynFlags for -dppr-debug -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently various functions in `Outputable` use `unsafeGlobalDynFlags` to get the state of `-dppr-debug`. `unsafeGlobalDynFlags` is rather ugly, being a blob of global state spanning both module compilations and GHC API sessions. Consequently, we might consider removing it. On the other hand, `-dppr-debug` is strictly a debug flag and removing `unsafeGlobalDynFlags` would likely require a lot more piping around of `DynFlags`. Consequently I suspect our current compromise of using `unsafeGlobalDynFlags` is the right solution. Nevertheless, I thought I would jot down the task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 18:16:54 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 18:16:54 -0000 Subject: [GHC] #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match In-Reply-To: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> References: <050.11e02ba42db9ddcb8fd7d6aa7559f6ed@haskell.org> Message-ID: <065.80bd77ae44b4161918e10ed8bd38d091@haskell.org> #14105: ApplicativeDo causes GHC panic on irrefutable list pattern match -------------------------------------+------------------------------------- Reporter: BoteboTsebo | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.2.3 Comment: Indeed it looks like this sadly fell through the cracks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 18:35:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 18:35:11 -0000 Subject: [GHC] #14598: 32-bit Linux environment Message-ID: <046.d2f4ecc843f7c7bed1054ebabaec5cff@haskell.org> #14598: 32-bit Linux environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 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: -------------------------------------+------------------------------------- Currently we lack any 32-bit test environment on CircleCI. This will need to change as we still provide 32-bit binary distributions and Harbormaster currently does have a 32-bit test target. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 18:36:11 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 18:36:11 -0000 Subject: [GHC] #14599: 32-bit Windows test environment Message-ID: <046.f041bf791eba4f88e592643da3b8f884@haskell.org> #14599: 32-bit Windows test environment -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 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: -------------------------------------+------------------------------------- We will need to add a build environment for 32-bit Windows as we still provide binary distributions for this target. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 18:38:05 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 18:38:05 -0000 Subject: [GHC] #14600: Work out why Hadrian builds routinely fail Message-ID: <046.d1a91fc8ce0240183a8fe557b52881a5@haskell.org> #14600: Work out why Hadrian builds routinely fail -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 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: -------------------------------------+------------------------------------- Currently Hadrian builds inexplicably and non-deterministically fail on CircleCI. They fail with, {{{ | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_l.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_debug.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_debug.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_l.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffi_thr_p.a | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffidebug_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_debug_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffil_-ghc8.5.20171218.so | Copy file (untracked): _build/stage1/libffi/inst/lib/libffi.a => _build/stage1/rts/libCffithr_l_-ghc8.5.20171218.so | Successfully built custom library 'libffi' Too long with no output (exceeded 10m0s) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 18:41:09 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 18:41:09 -0000 Subject: [GHC] #14505: CircleCI only builds pushed heads In-Reply-To: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> References: <046.5fc442bf07e9d8a0060fa53efebf8332@haskell.org> Message-ID: <061.dca8aef5010cdefc5117cfe5927fd66d@haskell.org> #14505: CircleCI only builds pushed heads -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Does this mean that the builders will not run on differentials? This seems like a very serious flaw if so. Differentials unfortunately need to be handled separately but sadly this isn't entirely trivial due to the GitHub-centric nature of CircleCI. See #14506. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 18:55:56 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 18:55:56 -0000 Subject: [GHC] #14601: Remove uses of unsafeGlobalDynFlags for -fopt-coercions Message-ID: <046.d361ab7de37c58253c96beea1e2ddfca@haskell.org> #14601: Remove uses of unsafeGlobalDynFlags for -fopt-coercions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the `-fopt-coercions` flag finds its way to `OptCoercion.optCoercion` by way of the terrible `unsafeGlobalDynFlags`. In general it's nice to minimize the uses of `unsafeGlobalDynFlags`. However, it's not entirely clear that passing a `DynFlags` to `optCoercion` is worthwhile in this case as `-fopt-coercion` is essentially a debug flag. Leaving this here for later consideration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 18:59:50 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 18:59:50 -0000 Subject: [GHC] #14538: forkprocess01 fails occassionally on with multiple ACQUIRE_LOCK panic In-Reply-To: <046.6179459a606dda455f09a96c2a4bfb98@haskell.org> References: <046.6179459a606dda455f09a96c2a4bfb98@haskell.org> Message-ID: <061.3ee92ea3d80f33c31e0b8d023a018f8d@haskell.org> #14538: forkprocess01 fails occassionally on with multiple ACQUIRE_LOCK panic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: 8.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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I seem to be seeing this more and more often. The fact that this failure is in `forkprocess01` definitely raises questions. Maybe this isn't an RTS bug at all but rather just a manifestation of one of the many gotchas associated with `fork`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 19:49:19 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 19:49:19 -0000 Subject: [GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build In-Reply-To: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> References: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> Message-ID: <061.0de6851b3d940b5169de22716931a87f@haskell.org> #14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Some good news: this appears to build much more quickly (1m13s real time) using the `nightly-2017-12-18` resolver (ghc-8.2.2) as with the 8.0-based `lts-9.18` resolver (which took 2m9s). Of course, those resolvers also differ in other ways. I'm still reducing the test file, and I'll report back when I have a better sense of the real difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 22:09:20 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 22:09:20 -0000 Subject: [GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build In-Reply-To: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> References: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> Message-ID: <061.d0b543e229d97f59e1a6fd96b914bc6c@haskell.org> #14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by schyler): Hey, thanks for looking into this. I don't have a concrete "X feature is slow", it just seemed so slow as a whole that I thought it might be a good candidate for profiling. Actually, the first few times I ran it I ctrl+c it because I thought it was hung. It's good to know that the latest resolver is quicker, thanks for that suggestion! When I get home I'll let you know exactly how much quicker it is on my machine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 18 22:44:48 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Dec 2017 22:44:48 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.fee16807969a115f868d6ee3c1fb1129@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I've beeb away these days and the appveyors UI is pretty horrible on mobile so I'll check this when I'm back mid week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 19 01:43:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Dec 2017 01:43:43 -0000 Subject: [GHC] #14596: Remove uses of unsafeGlobalDynFlags for state hack In-Reply-To: <046.779bac3ba63546bc4a17b182b3ed3032@haskell.org> References: <046.779bac3ba63546bc4a17b182b3ed3032@haskell.org> Message-ID: <061.c26d72dcdffa4a9adffa094644f4b994@haskell.org> #14596: Remove uses of unsafeGlobalDynFlags for state hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4265 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): It seems like the logical place to put this is as a flag in `TyCon`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 19 08:49:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Dec 2017 08:49:28 -0000 Subject: [GHC] #14596: Remove uses of unsafeGlobalDynFlags for state hack In-Reply-To: <046.779bac3ba63546bc4a17b182b3ed3032@haskell.org> References: <046.779bac3ba63546bc4a17b182b3ed3032@haskell.org> Message-ID: <061.a2b4190d881effdf37481524841fdca0@haskell.org> #14596: Remove uses of unsafeGlobalDynFlags for state hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4265 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > It seems like the logical place to put this is as a flag in TyCon. Yes... * The flag is only needed in `PrimTyCon` * And only used for `statePrimTyCon` (see `Id.isStateHackType`) The trouble is, if `statePrimTyCon` is dependent on `DynFlags`, it can't be top-level defines (as it is now). Does that matter? Turns out that `statePrimTyCon` is used * In `MkId.runRWId`. I think I can elimiante this top-level Id altogether * In `TysPrim.mkStatePrimTy`... * ...which in turn is used in `PrelRules.seqRule`. That is easy to elminate; I'll submit a patch shortly. * ...and `TysPrim.realWorldStatePrimTy` and `MkId.realWorldPrimId`. This is a bit harder; it they are used in: * a bunch of cases in `DsCCall`, but there is a monad to hand there, so that's easy to fix. * a couple of places in `eqType realWorldStatePrimTy`, but that doesn't need the tycon, only the unique * in `CorePrep` and `ByteCodeGen` where we are inlining `runRWId`. I'm sure these would be do-able because we have an argument of type `State#` so the relevant `TyCon` is in there. In short, I think this could be done with minimal plumbing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 19 12:00:21 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Dec 2017 12:00:21 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.f2c4105466d79a2b6fd2612a32074efe@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: 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: goldfire (added) Comment: Yurgh. I don't yet understand the details, but what is happening is something like this. We have an implication constraint {{{ forall x[2]. [W] co1: alpaha[1] ~ ty |> co2 [W] co2: k1 ~ * }}} Here `co2` is an ultimately-unsolved kind coercion. We float `co1` out of the implication and unify with `alpha`. Then in `TcErrors` we make evidence for `co2` using a call to `error`, bound in the `EvBinds` for the implication. But alas the scope of the binding for `co2` is just the term enclosed by the implication constraint. But the use of `co2` has escaped, in the type `alpha`. Yikes. This only shows up with deferred type errors, because normally we don't make term-level bindings for coercions; instead we just side-effect them right into the coercions they are used in, which just happens to work even in the "escaping" case. But with deferred type errors we need to force a term-level error, and to do so in as narrow a scope as possible. I'd like a smaller test case to show this up. I really do not know how to solve this. It's all because of those pesky casts inside types! Richard, your advice would be valuable here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 19 15:29:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Dec 2017 15:29:43 -0000 Subject: [GHC] #14596: Remove uses of unsafeGlobalDynFlags for state hack In-Reply-To: <046.779bac3ba63546bc4a17b182b3ed3032@haskell.org> References: <046.779bac3ba63546bc4a17b182b3ed3032@haskell.org> Message-ID: <061.4a906902ce4f33e440b639eb1a10292a@haskell.org> #14596: Remove uses of unsafeGlobalDynFlags for state hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4265 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"10ed31980f30bf2a0091b6f4cef11e0f2f633f22/ghc" 10ed3198/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="10ed31980f30bf2a0091b6f4cef11e0f2f633f22" Stop runRW# being magic Triggered by thinking about Trac #14596, I found that runRW# does not need to be a "magic" wired-in Id, now that we have levity polymorphism. This patch stops it being wired-in. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 19 15:29:43 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Dec 2017 15:29:43 -0000 Subject: [GHC] #14596: Remove uses of unsafeGlobalDynFlags for state hack In-Reply-To: <046.779bac3ba63546bc4a17b182b3ed3032@haskell.org> References: <046.779bac3ba63546bc4a17b182b3ed3032@haskell.org> Message-ID: <061.263fe213daa48da5da8321d12f7ebab7@haskell.org> #14596: Remove uses of unsafeGlobalDynFlags for state hack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4265 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ff1544d6db26c16d801f9cf9197db6eede57d576/ghc" ff1544d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ff1544d6db26c16d801f9cf9197db6eede57d576" Rmove a call to mkStatePrimTy This is a tiny refactoring that removes one of the calls to mkStatePrimTy, in service to Trac #14596 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 19 17:09:04 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Dec 2017 17:09:04 -0000 Subject: [GHC] #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble In-Reply-To: <044.13612547bcec0532b940b49a41a2177d@haskell.org> References: <044.13612547bcec0532b940b49a41a2177d@haskell.org> Message-ID: <059.8e8a73632b995c2e19d2c2b8b6795993@haskell.org> #14574: Template Haskell Uniq ~ Int leads to external interpreter cross compilation trouble -------------------------------------+------------------------------------- Reporter: luite | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): I've tested the change with the upcoming GHCJS release and it fixes the problem. I'll submit the patch tomorrow after some sleep. Also I now have a way to build GHCJS against a customized GHC library (`ghc-api-ghcjs`) and template haskell (`template-haskell-ghcjs`) package, so GHCJS on GHC 8.2 can get a backported fix and working Template Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 19 17:50:15 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Dec 2017 17:50:15 -0000 Subject: [GHC] #14507: Core Lint error with Type.Reflection and pattern synonyms In-Reply-To: <051.39dfd28e6e1a32cce4d4d43aea87a71e@haskell.org> References: <051.39dfd28e6e1a32cce4d4d43aea87a71e@haskell.org> Message-ID: <066.de79b13553c663be3ff88a866c1a2f7c@haskell.org> #14507: Core Lint error with Type.Reflection and pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's a smaller example {{{ module T14507 where import Type.Reflection import Data.Kind foo :: TypeRep a -> (Bool :~~: k, TypeRep a) foo rep = error "urk" type family SING :: k -> Type where -- Core Lint error disappears with this line: SING = (TypeRep :: Bool -> Type) pattern RepN :: forall (a::kk). () => Bool~kk => SING a -> TypeRep (a::kk) pattern RepN tr <- (foo -> ( HRefl :: Bool:~~:kk , tr :: TypeRep (a::Bool))) -- error pattern SO x <- RepN (id -> x) }}} The trouble is that the matcher for `SO` has a type like this {{{ $mSO :: forall (r :: TYPE rep) kk (a :: kk). TypeRep kk a -> (((Bool :: *) ~ (kk :: *)) => TypeRep Bool (a |> co_a2sv) -> r) -> (Void# -> r) -> r }}} where that unbound `co_a2sv` actually a coercion derived from the match on `(Bool ~ kk)`. If you like, the real second (continuation) argument of `$msO` is more like {{{ -> (forall (co::Bool~kk) -> TypeRep Bool (a |> get-superclass co) -> r }}} This is bogus because * We don't have term-level dependency `forall co -> ...` * We can't extract a superclass in a type. Richard, I need your help again! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 19 21:28:07 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Dec 2017 21:28:07 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.e1c535130f09cbbcfcd3463f3c37ebd2@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4216 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed Comment: Should be fixed in ghc 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 19 22:14:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Dec 2017 22:14:26 -0000 Subject: [GHC] #14537: Do not link to msvcrt.dll In-Reply-To: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> References: <046.1c327e3acbc706888aef5a746e2bc1a4@haskell.org> Message-ID: <061.212ca5a283fba04304c57276d00ba018@haskell.org> #14537: Do not link to msvcrt.dll -------------------------------------+------------------------------------- Reporter: johndoe | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Linking) | Resolution: invalid | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): The specs file is fine: {{{ $ ghc -optl-specs=msvcrt100.specs test.hs -fforce-recomp [1 of 1] Compiling Main ( test.hs, test.o ) Linking test.exe ... }}} and checking {{{ > dumpbin /imports test.exe | findstr msvcrt* msvcr100.dll msvcrt.dll }}} You will need to change as I mentioned before `lib\package.conf.d\` the `base-*.conf` and the `ghc-prim-*.conf` files changing the extra-libraries part. To get rid of the remaining references to `msvcrt.dll`. I see you're replacing the default spec file, but the new one is quite small, so Id'd try just passing it to the compiler as an argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 19 22:40:08 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Dec 2017 22:40:08 -0000 Subject: [GHC] #14507: Core Lint error with Type.Reflection and pattern synonyms In-Reply-To: <051.39dfd28e6e1a32cce4d4d43aea87a71e@haskell.org> References: <051.39dfd28e6e1a32cce4d4d43aea87a71e@haskell.org> Message-ID: <066.1e2c0ff3d7652f72498ae0d85b9efef0@haskell.org> #14507: Core Lint error with Type.Reflection and pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms, 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: PatternSynonyms => PatternSynonyms, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 00:18:53 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 00:18:53 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.dcea06e9c9b8637fe771a9ea1ac0cbe9@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: 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've reduced to: {{{ {-# Language PartialTypeSignatures #-} {-# Language KindSignatures #-} {-# Language PolyKinds #-} {-# Language ScopedTypeVariables #-} {-# Language AllowAmbiguousTypes #-} {-# Language TypeApplications #-} data Sing (a :: *) = X f :: forall m a. Sing a f = X @m :: Sing _ }}} and as previously `ghci -ignore-dot-ghci -fdefer-type-errors -dcore-lint 146-bug.hs` gives a Core Lint error; I've checked 8.2.1 but not HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 01:52:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 01:52:59 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.a8534a0e8da02c1497b06679f0a59874@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: 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): Why doesn't `co2` float out? We really shouldn't float `co1` out if we don't float `co2` out. The fact that it works without deferred type errors is just a fluke, really. (What if `co2` ends up being filled in with a coercion that mentions `x`?) I think this can be fixed just by adding a little more logic to the float- out code. Unfortunately, it also means that we need to calculate floating- out in dependency order (so we can process `co2` before even looking at `co1`. It makes the floating-out code a little more intricate, but the complication should be quite local. Does that sound reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 02:45:38 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 02:45:38 -0000 Subject: [GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build In-Reply-To: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> References: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> Message-ID: <061.bd751d4ec70f2fb3957f195dd990bb0e@haskell.org> #14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I've been digging a bit further (with GHC 8.2.2). It appears that the (derived) `Data` instances are responsible for most of the compilation time. I haven't yet tracked down what's taking the most time (no particular compiler phase seems egregiously bad). After peeking at some Core and thinking about the methods of `Data`, it doesn't really seem too surprising that the instances for large products might compile slowly. {{{#!hs gfoldl :: Data a => => (forall d b. Data d => c (d -> b) -> d -> c b) -> (forall g. g -> c g) -> a -> c a gunfold :: Data a => (forall b r. Data b => c (b -> r) -> c r) -> (forall r. r -> c r) -> Constr -> c a }}} Note the `Data` constraints on the function arguments. The implementation of `gfoldl` or `gunfold` needs to provide `Data` dictionaries for each field type. Those will initially be local `let`-bound values. Hopefully the duplicates are eventually eliminated, but if that doesn't happen quickly, we could waste some time. I'm still building HEAD to see if this has changed any lately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 05:42:39 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 05:42:39 -0000 Subject: [GHC] #14602: Implement the pattern synonym construction function signatures proposal Message-ID: <045.e40f2213ac4d80872fad159c9b3fe7a8@haskell.org> #14602: Implement the pattern synonym construction function signatures proposal -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0005 -bidir-constr-sigs.rst The pattern synonym construction function signatures proposal] has been accepted and should be implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 06:57:24 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 06:57:24 -0000 Subject: [GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build In-Reply-To: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> References: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> Message-ID: <061.081c410d3defe563fe6503661ed17d30@haskell.org> #14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): HEAD (with master branches of `primitive` and `vector`) is a little faster than 8.2.2, at least for building `Payload`, but not by much. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 08:02:37 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 08:02:37 -0000 Subject: [GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build In-Reply-To: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> References: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> Message-ID: <061.40fda354b82c58ab431e0856d579589d@haskell.org> #14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I see also that there's a fair bit of type gunk going on. The signature of `gfoldl` means that the combining function will be applied at O(n) different types, each a bit bigger than the last. Some other methods are similar. I don't know if this has any performance impact in the optimizer, but it might. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 10:02:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 10:02:51 -0000 Subject: [GHC] #14602: Implement the pattern synonym construction function signatures proposal In-Reply-To: <045.e40f2213ac4d80872fad159c9b3fe7a8@haskell.org> References: <045.e40f2213ac4d80872fad159c9b3fe7a8@haskell.org> Message-ID: <060.0d2201c3035037d250000d94cccac8f1@haskell.org> #14602: Implement the pattern synonym construction function signatures proposal -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I added a question about `:info` and `hs-boot` files to the proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 10:03:04 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 10:03:04 -0000 Subject: [GHC] #14602: Implement the pattern synonym construction function signatures proposal In-Reply-To: <045.e40f2213ac4d80872fad159c9b3fe7a8@haskell.org> References: <045.e40f2213ac4d80872fad159c9b3fe7a8@haskell.org> Message-ID: <060.d6a25b0f262357bf58cb04355a94673a@haskell.org> #14602: Implement the pattern synonym construction function signatures proposal -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 10:20:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 10:20:48 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.7db153588852423a4f134d2dc7fe4c5b@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > What if co2 ends up being filled in with a coercion that mentions x? Excellent question! But even a more complicated floating isn't enough. Suppose `co2` ''is'' actually solved. Then its binding will live in the inner implication; so we then can't float `co1`. And if that solved binding did mention `x`, then we should presumably not float `co1`. Yikes. This works today because: if `co2` is solved, when we zonk `co1` we'll see all the free vars of `co1` (because of the update in place stuff). In truth, if coercions generated bindings in the implication, we'd have to float them too, assuming none of them mention the skolemised variables. Bottom line: it seems delicate, but yes perhaps doing transitive capture would nail it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 10:21:09 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 10:21:09 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.9be24b5e7987b0ecb35649c57b705cf7@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: 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): ...or not. Monoidal's example is amazing. Here's the constraint we get (before simplifying it): {{{ simplifyTop { wanted = WC {wc_impl = Implic { TcLevel = 2 Skolems = k_aGF[sk:2] (m_aGG[sk:2] :: k_aGF[sk:2]) No-eqs = False Status = Unsolved Given = Wanted = WC {wc_simple = [WD] hole{aGP} {0}:: ((m_aGG[sk:2] |> {aGN}) -> (m_aGG[sk:2] |> {aGN}) :: *) GHC.Prim.~# (() :: *) (CNonCanonical) wc_impl = Implic { TcLevel = 3 Skolems = No-eqs = False Status = Unsolved Given = Wanted = WC {wc_simple = [D] _ {0}:: (m_aGG[sk:2] |> {aGN}) -> (m_aGG[sk:2] |> {aGN}) (CHoleCan: TypeHole(_)) [WD] hole{aGN} {0}:: (k_aGF[sk:2] :: *) GHC.Prim.~# (* :: *) (CNonCanonical)} Binds = EvBindsVar Needed = [] the inferred type of _02y :: w_aGJ[tau:3] }} Binds = EvBindsVar Needed = [] the type signature for: f :: forall k (m :: k). () }} }}} Notice that the coercion `{aGN}` is a Wanted inside the inner implication constraint, but is used a constraint (for `{aGP}`) outside that implication. No amount of floating is going to put that right! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 10:25:00 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 10:25:00 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.04bd3acf9e1a242edbfac2ed347e8847@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): We don't even need a partial type signature. This gives a similar Lint error (when compiled with `-fdefer-type-errrors`: {{{ g :: forall m. () g = let h = id @m in h }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 14:19:47 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 14:19:47 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.06adaa0203c2154f8494ef9e03c4d320@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: 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): comment:6 is frightening. I can look into this in due course, but do you see how on earth that happens? I wonder if that's a separate bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 22:03:07 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 22:03:07 -0000 Subject: [GHC] #14530: hWaitForInput causes the program to abort on Windows In-Reply-To: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> References: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> Message-ID: <062.64886de38d17d1b859cf9648f6b052d1@haskell.org> #14530: hWaitForInput causes the program to abort on Windows -----------------------------------+-------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by Phyx-): Hi can you please add a full repro, including all the imports? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 23:04:15 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 23:04:15 -0000 Subject: [GHC] #14603: GHC segfaults building store with profiling Message-ID: <046.7db770ba92a42deacd0ed35af7d6c965@haskell.org> #14603: GHC segfaults building store with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Trying to build `store` c5b6e34ebe4f74a971a8d7428c4cd1fe9bfeecf1 with GHC 8.4.1-alpha1 and profiling enabled results in a segmentation fault. {{{ Thread 1 "ghc" received signal SIGSEGV, Segmentation fault. >>> bt #0 0x00007ffff2f19100 in templatezmhaskell_LanguageziHaskellziTHziSyntax_nameModule_info () from /opt/exp/ghc/roots/8.4.1-alpha1/lib/ghc-8.4.0.20171214/bin/../template- haskell-2.13.0.0/libHStemplate-haskell-2.13.0.0-ghc8.4.0.20171214.so #1 0x0000000000000000 in ?? () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 20 23:41:21 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Dec 2017 23:41:21 -0000 Subject: [GHC] #14604: Flag to disable error position description Message-ID: <046.8e0d9c66951111cae4c1a3a37752c930@haskell.org> #14604: Flag to disable error position description -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.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: -------------------------------------+------------------------------------- Now since GHC has carat diagnostics I have heard at least one person ask for a way to disable the old position descriptions (e.g. "in the first argument of ..."). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 00:01:38 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 00:01:38 -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.d5e484c18ddd59e7b108ade60a7ba5a3@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.4.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): * owner: (none) => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 00:44:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 00:44:14 -0000 Subject: [GHC] #14578: Incorrect parenthesization of types in -ddump-deriv In-Reply-To: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> References: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> Message-ID: <065.9cb3553fc24720851a50d684376fa412@haskell.org> #14578: Incorrect parenthesization of types in -ddump-deriv -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4266 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"1bd91a7ac60eba3b0c019e2228f4b2b07f8cd5ad/ghc" 1bd91a7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1bd91a7ac60eba3b0c019e2228f4b2b07f8cd5ad" Fix #14578 by checking isCompoundHsType in more places Summary: The `HsType` pretty-printer does not automatically insert parentheses where necessary for type applications, so a function `isCompoundHsType` was created in D4056 towards this purpose. However, it was not used in as many places as it ought to be, resulting in #14578. Test Plan: make test TEST=T14578 Reviewers: alanz, bgamari, simonpj Reviewed By: alanz, simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14578 Differential Revision: https://phabricator.haskell.org/D4266 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 00:44:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 00:44:14 -0000 Subject: [GHC] #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns In-Reply-To: <048.5b1c9ce58b11d50f9bba53c8d62c92a6@haskell.org> References: <048.5b1c9ce58b11d50f9bba53c8d62c92a6@haskell.org> Message-ID: <063.5e8f409060d1e012810b444101b62d2c@haskell.org> #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns -------------------------------------+------------------------------------- Reporter: kmiyazato | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4270 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"9caf40e9d7233a2a6e78a0c4f2d2f13acbf804dd/ghc" 9caf40e9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9caf40e9d7233a2a6e78a0c4f2d2f13acbf804dd" Fix #14588 by checking for more bang patterns Summary: Commit 372995364c52eef15066132d7d1ea8b6760034e6 inadvertently removed a check in the parser which rejected let-bindings with bang patterns, leading to #14588. This fixes it by creating a `hintBangPat` function to perform this check, and sprinkling it in the right places. Test Plan: make test TEST=T14588 Reviewers: bgamari, alanz, simonpj Reviewed By: bgamari, simonpj Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #14588 Differential Revision: https://phabricator.haskell.org/D4270 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 00:44:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 00:44:14 -0000 Subject: [GHC] #12512: UnboxedTupleRep-related panic involving typeclasses In-Reply-To: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> References: <050.351b1a4e0676850f3fc7fe85b0a83b8b@haskell.org> Message-ID: <065.f9fe49d7e837944bdea9121b307e69fb@haskell.org> #12512: UnboxedTupleRep-related panic involving typeclasses -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #11723 | Differential Rev(s): Phab:D2557 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"9cb289abc582c9eb8337a2621baf58e35feeff46/ghc" 9cb289ab/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9cb289abc582c9eb8337a2621baf58e35feeff46" Remove hack put in place for #12512 Summary: Previously, I added an ad hoc check for unboxed tuples and sums in standalone-derived instances to fix #12512, under the pretense that polymorphism over `UnboxedTupleRep` and `UnboxedSumRep` was a lie. But that is no longer the case, and so this ad hoc check can be removed entirely. Less code, and easier to understand. Test Plan: make test TEST=T12512 Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4271 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 00:44:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 00:44:14 -0000 Subject: [GHC] #14590: Sectioned hole oddities In-Reply-To: <050.776bcc337458e90ceae6ff94ddc5ed3d@haskell.org> References: <050.776bcc337458e90ceae6ff94ddc5ed3d@haskell.org> Message-ID: <065.ef62a4efea9bc5069e2a5e99a7651cec@haskell.org> #14590: Sectioned hole oddities -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13050 | Differential Rev(s): Phab:D4273 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"4d41e9212d1fdf109f2d0174d204644446f5874c/ghc" 4d41e92/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4d41e9212d1fdf109f2d0174d204644446f5874c" Improve treatment of sectioned holes Summary: Previously, GHC was pretty-printing left-section holes incorrectly and not parsing right-sectioned holes at all. This patch fixes both problems. Test Plan: make test TEST=T14590 Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, mpickering, carter GHC Trac Issues: #14590 Differential Revision: https://phabricator.haskell.org/D4273 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 00:44:14 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 00:44:14 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.3282ba6a796d60ca4840f846b346c5c2@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14498 | Differential Rev(s): Phab:D4272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"b6304f8fd9b845466116874db4224f42acbc597d/ghc" b6304f8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b6304f8fd9b845466116874db4224f42acbc597d" Document ScopedTypeVariables' interaction with nested foralls Summary: This documents the status quo with regards to how `ScopedTypeVariables` brings into scope type variables that are quantified by nested `forall`s (that is to say, it doesn't). This takes the prose in https://ghc.haskell.org/trac/ghc/ticket/14288#comment:5 and enshrines it into the users' guide. Test Plan: Read it Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14288 Differential Revision: https://phabricator.haskell.org/D4272 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 00:46:24 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 00:46:24 -0000 Subject: [GHC] #14578: Incorrect parenthesization of types in -ddump-deriv In-Reply-To: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> References: <050.1bb782b3eb79c5da4302f5fbe9b4afd7@haskell.org> Message-ID: <065.8cfeea2009a76d871ff4a994324347ec@haskell.org> #14578: Incorrect parenthesization of types in -ddump-deriv -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Debugging | Test Case: information is incorrect | deriving/should_compile/T14578 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4266 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => deriving/should_compile/T14578 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 00:47:28 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 00:47:28 -0000 Subject: [GHC] #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns In-Reply-To: <048.5b1c9ce58b11d50f9bba53c8d62c92a6@haskell.org> References: <048.5b1c9ce58b11d50f9bba53c8d62c92a6@haskell.org> Message-ID: <063.b2ed6b633e88d33efee2f2ac0a9addae@haskell.org> #14588: GHC 8.2.1 allows bang patterns in let-bindings without -XBangPatterns -------------------------------------+------------------------------------- Reporter: kmiyazato | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | parser/should_fail/T14588 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4270 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => parser/should_fail/T14588 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 00:48:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 00:48:16 -0000 Subject: [GHC] #14590: Sectioned hole oddities In-Reply-To: <050.776bcc337458e90ceae6ff94ddc5ed3d@haskell.org> References: <050.776bcc337458e90ceae6ff94ddc5ed3d@haskell.org> Message-ID: <065.3fefceb0fe2b6b23e337680ce4dc3bd2@haskell.org> #14590: Sectioned hole oddities -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T14590 Blocked By: | Blocking: Related Tickets: #13050 | Differential Rev(s): Phab:D4273 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => typecheck/should_compile/T14590 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 00:49:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 00:49:02 -0000 Subject: [GHC] #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 In-Reply-To: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> References: <054.12a8b47c33ef278049d5dc75803a77fb@haskell.org> Message-ID: <069.65b80f33353ddddf261337afc5c460ae@haskell.org> #14288: ScopedTypeVariables with nested foralls broken since 8.0.2 -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14498 | Differential Rev(s): Phab:D4272 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 03:32:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 03:32:41 -0000 Subject: [GHC] #13360: Add a flag to enable inferring HasCallStack constraints In-Reply-To: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> References: <049.fd20b919b0b248d87541443c07c93d5f@haskell.org> Message-ID: <064.067e8ad0f6e90a7bee1a1245371c8334@haskell.org> #13360: Add a flag to enable inferring HasCallStack constraints -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ntc2): * cc: ntc2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 04:04:50 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 04:04:50 -0000 Subject: [GHC] #14605: Core Lint error Message-ID: <051.4d7eef339ce5b99337cf52694286a2a6@haskell.org> #14605: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: TypeInType, | Operating System: Unknown/Multiple DeferredTypeErrors | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This piece of code fails when run with `ghci -ignore-dot-ghci -fdefer- type-errors -dcore-lint bug.hs`, maybe same as my previous #14584. {{{#!hs {-# Language DerivingStrategies #-} {-# Language GeneralizedNewtypeDeriving #-} {-# Language InstanceSigs #-} {-# Language KindSignatures #-} {-# Language PolyKinds #-} {-# Language ScopedTypeVariables #-} {-# Language TypeApplications #-} {-# Language TypeFamilies #-} {-# Language TypeInType #-} {-# Language TypeOperators #-} {-# Language UndecidableInstances #-} import Data.Kind import Data.Functor.Identity import Data.Functor.Product type a <-> b = a -> b -> Type class Iso (iso :: a <-> b) where iso :: a -> b osi :: b -> a data Iso_Bool :: Either () () <-> Bool instance Iso Iso_Bool where class Representable f where type Rep f :: Type index :: f a -> (Rep f -> a) tabulate :: (Rep f -> a) -> f a class Comonad w where extract :: w a -> a duplicate :: w a -> w (w a) newtype Co f a = Co (f a) deriving newtype (Functor, Representable) instance (Representable f, Monoid (Rep f)) => Comonad (Co f) where extract = (`index` mempty) newtype WRAP (iso::old <-> new) f a = WRAP (f a) instance (Representable f, Rep f ~ old, Iso iso) => Representable (WRAP (iso :: old <-> new) f) where type Rep (WRAP (iso :: old <-> new) f) = new index :: WRAP iso f a -> (new -> a) index (WRAP fa) = index fa . osi @old @new @iso tabulate :: (new -> a) -> WRAP iso f a tabulate gen = WRAP $ tabulate (gen . iso @old @new @iso) newtype PAIR a = PAIR (Co (WRAP Iso_Bool (Product Identity Identity)) a) deriving newtype Comonad }}} I unfortunately don't have time to find a more minimal example. Core linter vomits a lot of errors on 8.2.1 & 8.3.20171208. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 04:05:15 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 04:05:15 -0000 Subject: [GHC] #14605: Core Lint error In-Reply-To: <051.4d7eef339ce5b99337cf52694286a2a6@haskell.org> References: <051.4d7eef339ce5b99337cf52694286a2a6@haskell.org> Message-ID: <066.8799d9ce2b6515293d113ffe6c3aeb68@haskell.org> #14605: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14584 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #14584 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 12:11:33 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 12:11:33 -0000 Subject: [GHC] #14605: Core Lint error In-Reply-To: <051.4d7eef339ce5b99337cf52694286a2a6@haskell.org> References: <051.4d7eef339ce5b99337cf52694286a2a6@haskell.org> Message-ID: <066.83bb5fedb477c07693f1aeade4a18229@haskell.org> #14605: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14584 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Similar to #14584. The essence is the code that is generated via GND for `Comonad PAIR`, which I've reduced to: {{{ {-# Language TypeApplications #-} {-# Language ImpredicativeTypes #-} import GHC.Prim (coerce) duplicate = coerce @(forall x. ()) @(forall x. x) }}} (though it's possible there are more factors causing the bug and I isolated only one of them) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 12:18:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 12:18:51 -0000 Subject: [GHC] #14605: Core Lint error In-Reply-To: <051.4d7eef339ce5b99337cf52694286a2a6@haskell.org> References: <051.4d7eef339ce5b99337cf52694286a2a6@haskell.org> Message-ID: <066.51fd0959534f3efcbe68c64491d8e2d9@haskell.org> #14605: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14584 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The error is a kind error under a forall type, which gets an implication constraint, but with nowhere to put its (value) bindings. The the deferred type error produces a value binding that is then discarded. Monoidal, you are brilliant at reducing these examples to their essence. Amazing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 13:48:25 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 13:48:25 -0000 Subject: [GHC] #14605: Core Lint error In-Reply-To: <051.4d7eef339ce5b99337cf52694286a2a6@haskell.org> References: <051.4d7eef339ce5b99337cf52694286a2a6@haskell.org> Message-ID: <066.5ae5d64e1fd469d7eee63f79a5ba51f4@haskell.org> #14605: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14584 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Thanks monoidal for cleaning up my mess :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 14:55:31 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 14:55:31 -0000 Subject: [GHC] #14479: Partial type signatures and generalisation In-Reply-To: <046.dc08a3c3d392ce3db896a2149215fdcd@haskell.org> References: <046.dc08a3c3d392ce3db896a2149215fdcd@haskell.org> Message-ID: <061.2fb3972721206f80fa54baf5b0ab042b@haskell.org> #14479: Partial type signatures and generalisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"72938f5890dac81afad52bf58175c1e29ffbc6dd/ghc" 72938f58/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="72938f5890dac81afad52bf58175c1e29ffbc6dd" Check for bogus quantified tyvars in partial type sigs This fixes Trac #14479. Not difficult. See Note [Quantification and partial signatures] Wrinkle 4, in TcSimplify. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 14:55:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 14:55:32 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.8b5f8ff2913c9b4d09c0049e4aa35185@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: 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:"f5cf9d1a1b198edc929e1fa96c6d841d182fe766/ghc" f5cf9d1a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f5cf9d1a1b198edc929e1fa96c6d841d182fe766" Fix floating of equalities This rather subtle patch fixes Trac #14584. The problem was that we'd allowed a coercion, bound in a nested scope, to escape into an outer scope. The main changes are * TcSimplify.floatEqualities takes more care when floating equalities to make sure we don't float one out that mentions a locally-bound coercion. See Note [What prevents a constraint from floating] * TcSimplify.emitResidualConstraints (which emits the residual constraints in simplifyInfer) now avoids burying the constraints for escaping CoVars inside the implication constraint. * Since I had do to this stuff with CoVars, I moved the fancy footwork about not quantifying over CoVars from TcMType.quantifyTyVars to its caller TcSimplify.decideQuantifiedTyVars. I think its other callers don't need to worry about all this CoVar stuff. This turned out to be surprisigly tricky, and took me a solid day to get right. I think the result is reasonably neat, though, and well documented with Notes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 14:55:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 14:55:32 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.53a7348bdfcc8234eb28df50ea54d0ba@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: 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:"a492af06d3264530d134584f22ffb726a16c78ec/ghc" a492af06/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a492af06d3264530d134584f22ffb726a16c78ec" Refactor coercion holes In fixing Trac #14584 I found that it would be /much/ more convenient if a "hole" in a coercion (much like a unification variable in a type) acutally had a CoVar associated with it rather than just a Unique. Then I can ask what the free variables of a coercion is, and get a set of CoVars including those as-yet-un-filled in holes. Once that is done, it makes no sense to stuff coercion holes inside UnivCo. They were there before so we could know the kind and role of a "hole" coercion, but once there is a CoVar we can get that info from the CoVar. So I removed HoleProv from UnivCoProvenance and added HoleCo to Coercion. In summary: * Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance * Similarly in IfaceCoercion * Make CoercionHole have a CoVar in it, not a Unique * Make tyCoVarsOfCo return the free coercion-hole variables as well as the ordinary free CoVars. Similarly, remember to zonk the CoVar in a CoercionHole We could go further, and remove CoercionHole as a distinct type altogther, just collapsing it into HoleCo. But I have not done that yet. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 14:58:16 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 14:58:16 -0000 Subject: [GHC] #14479: Partial type signatures and generalisation In-Reply-To: <046.dc08a3c3d392ce3db896a2149215fdcd@haskell.org> References: <046.dc08a3c3d392ce3db896a2149215fdcd@haskell.org> Message-ID: <061.c569bd4e7a5a8330f6481078b0738bfe@haskell.org> #14479: Partial type signatures and generalisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: partial- | sigs/should_fail/T14479 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => partial-sigs/should_fail/T14479 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 14:59:12 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 14:59:12 -0000 Subject: [GHC] #14584: Core Lint error In-Reply-To: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> References: <051.361d3c896bae88bdc5274084b023d7fd@haskell.org> Message-ID: <066.73998636306070627fe8d29f96409fb6@haskell.org> #14584: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: TypeInType, | DeferredTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/partial- | sigs/should_fail/T14584, T14584a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => testsuite/tests/partial-sigs/should_fail/T14584, T14584a * resolution: => fixed Comment: Blimey. That rabbit-hole was a lot deeper than I expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 18:38:52 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 18:38:52 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.e464d1a380817b14ef93a3ba4a96af07@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chris_r_timmons): I'd like to move forward on this with a submission to Phabricator, but I'd appreciate some guidance as to whether my approach is correct. My plan is: 1. Create a new folder $TOP/utils/checkRTS 2. Place the python script (renamed to checkRTS.py) and a README file in that folder 3. As suggested, modify $TOP/validate to call $TOP/utils/checkRTS/checkRTS.py 4. checkRTS.py will print its findings to stdout Does this sound feasible? Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 20:27:48 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 20:27:48 -0000 Subject: [GHC] #14606: ghc-exactprint not up to date Message-ID: <044.eda8c95560814c75d9806634f1da14ed@haskell.org> #14606: ghc-exactprint not up to date -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have created this ticket to track that ghc-exactprint has not yet been updated, and this should happen before a final release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 20:28:11 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 20:28:11 -0000 Subject: [GHC] #14606: ghc-exactprint not up to date In-Reply-To: <044.eda8c95560814c75d9806634f1da14ed@haskell.org> References: <044.eda8c95560814c75d9806634f1da14ed@haskell.org> Message-ID: <059.40a1b9032fc8d596ab7766e11c8ea23f@haskell.org> #14606: ghc-exactprint not up to date -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: GHC API | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 21 23:25:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Dec 2017 23:25:06 -0000 Subject: [GHC] #14594: 2 modules / 2500LOC takes nearly 3 minutes to build In-Reply-To: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> References: <046.b60bf688db171cb4139d3998a57394f4@haskell.org> Message-ID: <061.0899011fc49267351ab53e6276322e4e@haskell.org> #14594: 2 modules / 2500LOC takes nearly 3 minutes to build -------------------------------------+------------------------------------- Reporter: schyler | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by schyler): On a desktop (Intel i5-3470 which is 3.2-3.6ghz, 8gb RAM): {{{ resolver: lts-9.18 real 1m55.157s user 0m0.000s sys 0m0.015s }}} {{{ resolver: lts-10.0 real 1m19.322s user 0m0.000s sys 0m0.015s }}} A concrete example where lts-10 is considerably faster (nearly 50%)! Well done everyone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 22 01:05:25 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Dec 2017 01:05:25 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.aab932a637236d3f45f178df9cd24ac3@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: akio Type: bug | Status: new Priority: low | Milestone: 8.4.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2951 Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): although this is low priority, it looks like it is done. Is there any reason not to put it into 8.4.1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 22 11:42:34 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Dec 2017 11:42:34 -0000 Subject: [GHC] #13861: Take more advantage of STG representation invariance (follows up #9291) In-Reply-To: <048.651e325a747e822318af666cede88e81@haskell.org> References: <048.651e325a747e822318af666cede88e81@haskell.org> Message-ID: <063.e75f87c434726c9c47d27e0b1c41736c@haskell.org> #13861: Take more advantage of STG representation invariance (follows up #9291) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): https://github.com/ggreif/ghc/tree/wip/T13861 is the branch that builds on https://github.com/ggreif/ghc/tree/wip/T14373. I wonder what https://perf.haskell.org will say... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 22 11:58:55 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Dec 2017 11:58:55 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.a2c3121f5407c42d74220eccde37a1c9@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @chris_r_timmons that sounds fine to me. Though I think this should run before the tests are run, not after, since Stage2 may not work this will tell you why. I also think it should be a hard error if something is wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 22 12:10:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Dec 2017 12:10:35 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.3a4b2811759d8cc2eae0599c29edc3a4@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): So looking at the script, two comments: There's no guarantee that there's a GCC on the path. On Windows you may not have one. So you have two choices here. You can either hardcode inplace/mingw/bin/gcc for Windows, or you can ask ghc for the C compiler it's using. (e.g. calling ghc --info). If you do the second one, you have the issue that some configurations use clang, so you have to guard against that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 22 14:09:52 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Dec 2017 14:09:52 -0000 Subject: [GHC] #12670: Representation polymorphism validity check is too strict In-Reply-To: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> References: <046.fd6ae5da604399ed80256a1ee732e4bb@haskell.org> Message-ID: <061.e994b3bd125e887354729e303d9a1d84@haskell.org> #12670: Representation polymorphism validity check is too strict -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Typeable, Resolution: fixed | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: typeable, LevityPolymorphism => Typeable, LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 22 14:10:16 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Dec 2017 14:10:16 -0000 Subject: [GHC] #12905: Core lint failure with pattern synonym and levity polymorphism In-Reply-To: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> References: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> Message-ID: <061.e56b11db7db95014444149c73ca09a52@haskell.org> #12905: Core lint failure with pattern synonym and levity polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: duplicate | LevityPolymorphism, Typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #11714 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: LevityPolymorphism, typeable => LevityPolymorphism, Typeable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 22 17:42:05 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Dec 2017 17:42:05 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.b898eb04f1f14c02a0253b4d720b2e2d@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: akio Type: bug | Status: closed Priority: low | Milestone: 8.4.1 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2951 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Indeed it's already in 8.4.1; it looks like the ticket was simply never closed. Thanks George! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 22 20:44:28 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Dec 2017 20:44:28 -0000 Subject: [GHC] #14456: Windows runtime linker failure with icuuc In-Reply-To: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> References: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> Message-ID: <065.7a7c5e1d4d251b9ff3f061bc8292203c@haskell.org> #14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4274 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D4274 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 22 20:44:40 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Dec 2017 20:44:40 -0000 Subject: [GHC] #14456: Windows runtime linker failure with icuuc In-Reply-To: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> References: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> Message-ID: <065.d3317fb28bf4be76874412967f02d4df@haskell.org> #14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.2.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4274 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 22 20:45:12 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Dec 2017 20:45:12 -0000 Subject: [GHC] #14456: Windows runtime linker failure with icuuc In-Reply-To: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> References: <050.3b07902cfc2f558e6740649e9c204478@haskell.org> Message-ID: <065.55530ed97eccfe7e75dcafcf5eba50de@haskell.org> #14456: Windows runtime linker failure with icuuc -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4274 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 22 22:51:02 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Dec 2017 22:51:02 -0000 Subject: [GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure In-Reply-To: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> References: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> Message-ID: <061.159440e9c1070a010c010b319acb51b3@haskell.org> #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8048 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollu): * cc: bollu (added) Comment: CCing myself because I have been running into related issues with closure- creation-on-the-stack that's not necessary here: https://github.com/bollu/exploration/tree/master/dec-22-asm-diff -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 23 04:43:44 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Dec 2017 04:43:44 -0000 Subject: [GHC] #14607: Core Lint error Message-ID: <051.0789d1ec4c690cec121da05b03933298@haskell.org> #14607: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: TypeInType, | Operating System: Unknown/Multiple DeferredTypeErrors | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14605 #14584 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This produces long {{{#!hs {-# Language DerivingStrategies #-} {-# Language GADTs #-} {-# Language GeneralizedNewtypeDeriving #-} {-# Language InstanceSigs #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language TypeInType #-} {-# Language TypeOperators #-} import Data.Kind data DEFUNC :: Type -> Type -> Type where (:~>) :: a -> b -> DEFUNC a b type a ~> b = DEFUNC a b -> Type data LamCons a :: Type ~> Type where LamCons :: a -> LamCons a ([a] :~> [a]) class Mk (app :: Type ~> Type) where type Arg app :: Type mk :: Arg app -> app (a :~> b) instance Mk (LamCons a :: Type ~> Type) where type Arg (LamCons a) = a mk :: a -> LamCons (a :~> b) mk = LamCons }}} erros with `ghci -ignore-dot-ghci -fdefer-type-errors -dcore-lint bug.hs` on GHC 8.2.1 and 8.3.20171208. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 23 04:44:14 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Dec 2017 04:44:14 -0000 Subject: [GHC] #14607: Core Lint error In-Reply-To: <051.0789d1ec4c690cec121da05b03933298@haskell.org> References: <051.0789d1ec4c690cec121da05b03933298@haskell.org> Message-ID: <066.b57529153dd51e335066164614c4f7f1@haskell.org> #14607: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14605 #14584 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > This produces long {{{#!hs > {-# Language DerivingStrategies #-} > {-# Language GADTs #-} > {-# Language GeneralizedNewtypeDeriving #-} > {-# Language InstanceSigs #-} > {-# Language KindSignatures #-} > {-# Language TypeFamilies #-} > {-# Language TypeInType #-} > {-# Language TypeOperators #-} > > import Data.Kind > > data DEFUNC :: Type -> Type -> Type where > (:~>) :: a -> b -> DEFUNC a b > > type a ~> b = DEFUNC a b -> Type > > data LamCons a :: Type ~> Type where > LamCons :: a -> LamCons a ([a] :~> [a]) > > class Mk (app :: Type ~> Type) where > type Arg app :: Type > > mk :: Arg app -> app (a :~> b) > > instance Mk (LamCons a :: Type ~> Type) where > type Arg (LamCons a) = a > > mk :: a -> LamCons (a :~> b) > mk = LamCons > }}} > > erros with `ghci -ignore-dot-ghci -fdefer-type-errors -dcore-lint bug.hs` > on GHC 8.2.1 and 8.3.20171208. New description: This produces a long Core lint error: {{{#!hs {-# Language DerivingStrategies #-} {-# Language GADTs #-} {-# Language GeneralizedNewtypeDeriving #-} {-# Language InstanceSigs #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language TypeInType #-} {-# Language TypeOperators #-} import Data.Kind data DEFUNC :: Type -> Type -> Type where (:~>) :: a -> b -> DEFUNC a b type a ~> b = DEFUNC a b -> Type data LamCons a :: Type ~> Type where LamCons :: a -> LamCons a ([a] :~> [a]) class Mk (app :: Type ~> Type) where type Arg app :: Type mk :: Arg app -> app (a :~> b) instance Mk (LamCons a :: Type ~> Type) where type Arg (LamCons a) = a mk :: a -> LamCons (a :~> b) mk = LamCons }}} with `ghci -ignore-dot-ghci -fdefer-type-errors -dcore-lint bug.hs` on GHC 8.2.1 and 8.3.20171208. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 23 05:18:20 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Dec 2017 05:18:20 -0000 Subject: [GHC] #14607: Core Lint error In-Reply-To: <051.0789d1ec4c690cec121da05b03933298@haskell.org> References: <051.0789d1ec4c690cec121da05b03933298@haskell.org> Message-ID: <066.fb056515c51651c15c89a47712608d98@haskell.org> #14607: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14605 #14584 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Simplified example {{{#!hs {-# Language GADTs #-} {-# Language GeneralizedNewtypeDeriving #-} {-# Language InstanceSigs #-} {-# Language KindSignatures #-} {-# Language TypeInType #-} import Data.Kind type Arr a b = (a, b) -> Type data LamCons a :: Arr Type Type where LamCons :: LamCons a '([a], [a]) class Mk (app :: Arr Type Type) where mk :: app '(a, b) instance Mk (LamCons a :: Arr Type Type) where mk :: LamCons '(a, b) mk = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 23 05:48:05 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Dec 2017 05:48:05 -0000 Subject: [GHC] #14608: Different GHCi error messages for similar scenarios Message-ID: <043.dc3a47548a95791f116ee7f040dff01e@haskell.org> #14608: Different GHCi error messages for similar scenarios -------------------------------------+------------------------------------- Reporter: mb64 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With the following code: {{{#!hs {-# LANGUAGE UnboxedTuples #-} module Test where data UnboxedTupleData = MkUTD (# (),() #) doThings :: UnboxedTupleData -> () doThings (MkUTD t) = () }}} This is accepted and compiled with a simple `ghc --make Test.hs`. However, with `ghci Test.hs`, you get an ugly error message: {{{#!hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): bcIdPrimRep t_s1ro :: (# (), () #) Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/ghci/ByteCodeGen.hs:1582:5 in ghc:ByteCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Replacing `(MkUTD t)` with just `t` obtains a different error, with a nicer message: {{{#!hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Test ( Test.hs, interpreted ) Error: bytecode compiler can't handle unboxed tuples and sums. Possibly due to foreign import/export decls in source. Workaround: use -fobject-code, or compile this module to .o separately. }}} True to its word, GHCi accepts it with `-fobject-code`, but it also accepts the unwrapping one, with the worse error message, with `-fobject- code`. It only happens with unboxed tuples in GHCi: if you replace the unboxed tuple with an unboxed int, GHCi will happily accept it. GHC cheerfully compiles everything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 23 08:16:28 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Dec 2017 08:16:28 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.821c2fc3a67a1ad7356c0fc89ba7990f@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pggiarrusso): Other reports of GHCi leaks include https://ghc.haskell.org/trac/ghc/ticket/12848 https://github.com/commercialhaskell/intero/issues/84. The first suggests that loading code leaks memory, which might relate to comment:5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 23 08:17:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Dec 2017 08:17:16 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.be360a40482cf8fdb6cfeec893b671d9@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by pggiarrusso): * cc: pggiarrusso (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 23 15:09:51 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Dec 2017 15:09:51 -0000 Subject: [GHC] #14607: Core Lint error In-Reply-To: <051.0789d1ec4c690cec121da05b03933298@haskell.org> References: <051.0789d1ec4c690cec121da05b03933298@haskell.org> Message-ID: <066.f31a7c15b6df3f049348f5190b88551a@haskell.org> #14607: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: TypeInType, | DeferredTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14605 #14584 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Small simplification: {{{ #!hs {-# Language GADTs #-} {-# Language InstanceSigs #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language DataKinds #-} {-# Language FlexibleInstances #-} import Data.Kind data LamCons :: Type -> Type -> () -> Type where C :: LamCons a a '() class Mk a where mk :: LamCons a a '() instance Mk a where mk :: LamCons a '() mk = mk }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 23 17:14:30 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Dec 2017 17:14:30 -0000 Subject: [GHC] #14608: Different GHCi error messages for similar scenarios In-Reply-To: <043.dc3a47548a95791f116ee7f040dff01e@haskell.org> References: <043.dc3a47548a95791f116ee7f040dff01e@haskell.org> Message-ID: <058.e2217077e175c1b52a4f1b239af40ef7@haskell.org> #14608: Different GHCi error messages for similar scenarios -------------------------------------+------------------------------------- Reporter: mb64 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This panic first started appearing in commit 714bebff44076061d0a719c4eda2cfd213b7ac3d (`Implement unboxed sum primitive type`). The panic changed to its current `bcIdPrimRep` form in commit e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9 (`Update levity polymorphism`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 24 02:35:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Dec 2017 02:35:23 -0000 Subject: [GHC] #14609: Per-instance UndecidableInstances Message-ID: <048.249a939a6e76cafabb0ae79267f4d3cf@haskell.org> #14609: Per-instance UndecidableInstances -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The LANGUAGE pragma OverlappingInstances is now a per-instance modifier specifying the manner of overlap. Can (or why can't) this also be done for UndecidableInstances? It gives me an icky feeling to put it at the top of a source file when I just want to allow one specific instance to be undecidable. My apologies if this request already exists. It is very difficult to find bugs about UndecidableInstances in particular as opposed merely to those containing code with this pragma, which appear to be numerous. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 24 12:23:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Dec 2017 12:23:33 -0000 Subject: [GHC] #14610: newtype wrapping of a monadic stack kills performance Message-ID: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> #14610: newtype wrapping of a monadic stack kills performance -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a project where I in one module (A) I decided to build something like a minimal framework for the other bigger module (B) to use. One of the main points of the framework is that the monadic stacks are hidden behind `newtype`s and in those monads you can only use the functions that the module A provides. The module A can be found here: https://github.com/mrkkrp/mmark/blob/master/Text/MMark/Parser/Internal.hs There are two monadic stack wrapped with newtypes: `BParser` and `IParser`. The module B is this: https://github.com/mrkkrp/mmark/blob/master/Text/MMark/Parser.hs But it's not really relevant. Now if I change `newtype`s to `type` synonyms like so: {{{ type BParser a = ParsecT MMarkErr Text (State BlockState) a type IParser a = StateT InlineState (Parsec MMarkErr Text) a }}} and do corresponding minor corrections, I get 2x less allocations and almost 2x faster code (before): {{{ Case Allocated GCs Max with file: data/bench-yaml-block.md 119,080 0 11,088 with file: data/bench-thematic-break.md 74,368 0 10,224 with file: data/bench-heading.md 901,928 0 9,432 with file: data/bench-fenced-code-block.md 145,744 0 9,368 with file: data/bench-indented-code-block.md 124,312 0 9,368 with file: data/bench-unordered-list.md 2,010,496 1 10,784 with file: data/bench-ordered-list.md 2,025,016 1 10,728 with file: data/bench-blockquote.md 1,961,672 1 42,648 with file: data/bench-paragraph.md 2,084,104 1 42,648 with file: data/comprehensive.md 25,899,496 24 44,200 benchmarking with file: data/comprehensive.md time 3.590 ms (3.578 ms .. 3.601 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 3.555 ms (3.546 ms .. 3.565 ms) std dev 31.07 μs (24.63 μs .. 39.90 μs) }}} After: {{{ Case Allocated GCs Max with file: data/bench-yaml-block.md 116,864 0 11,088 with file: data/bench-thematic-break.md 64,776 0 10,392 with file: data/bench-heading.md 615,672 0 9,432 with file: data/bench-fenced-code-block.md 144,736 0 9,368 with file: data/bench-indented-code-block.md 123,352 0 9,368 with file: data/bench-unordered-list.md 795,072 0 41,568 with file: data/bench-ordered-list.md 808,808 0 41,512 with file: data/bench-blockquote.md 826,392 0 41,568 with file: data/bench-paragraph.md 881,432 0 41,568 with file: data/comprehensive.md 10,945,104 10 44,440 benchmarking with file: data/comprehensive.md time 2.451 ms (2.448 ms .. 2.456 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 2.432 ms (2.427 ms .. 2.437 ms) std dev 15.86 μs (13.16 μs .. 19.01 μs) }}} I'm not great at reading non-trivial core, but I gave it a shot and dumped some core. One thing I noticed that core for the module A is the same in both cases. Then the problem is an inter-module problem, probably like when you don't dump definitions into interface files with `INLINEABLE` and end up without specialization, but here it perhaps has to do with the fact that B has no information about internals of the monadic stacks from A, but I'm not sure. Here is the beginnings of core dumps (before): {{{ ==================== Tidy Core ==================== 2017-12-23 04:55:17.967944505 UTC Result size of Tidy Core = {terms: 210,169, types: 209,675, coercions: 82,492, joins: 973/3,753} }}} After: {{{ ==================== Tidy Core ==================== 2017-12-23 04:58:46.386265108 UTC Result size of Tidy Core = {terms: 301,256, types: 263,104, coercions: 28,560, joins: 1,726/5,393} }}} So it looks like `newtype` wrapping reduces GHC's ability to create join points SPJ talked about recently. I do understand that you expect a minimal reproducing example but I could not produce it even though I spent several hours in futile attempts. I started by creating a small project, defining a similar stack with a `newtype` wrapper and using it in a simple parser in another module. Then I benchmarked the parser. There is no difference between `newtype`d and code and the code that uses just type synonyms. I tried different variations, no difference. The core output is too big for me to analyze, it's like 25 Mb and 33 Mb, and I have no idea what's going on there. You're welcome to experiment with the repo, there are benchmarks for memory usage and criterion benchmarks for speed of execution: https://github.com/mrkkrp/mmark If you like I can create a separate branch with newtypes replaced with type synonyms, so you can compare the both approaches easier. I'm submitting this because my friend convinced me that it's better to let you know (even though I could not create a minimal reproducing example on my own) than to let it go completely unnoticed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 24 13:43:21 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Dec 2017 13:43:21 -0000 Subject: [GHC] #14610: newtype wrapping of a monadic stack kills performance In-Reply-To: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> References: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> Message-ID: <060.53f86a70d6d65b0504b9e9c06cb62269@haskell.org> #14610: newtype wrapping of a monadic stack kills performance -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mrkkrp: Old description: > I have a project where I in one module (A) I decided to build something > like > a minimal framework for the other bigger module (B) to use. One of the > main > points of the framework is that the monadic stacks are hidden behind > `newtype`s and in those monads you can only use the functions that the > module A provides. > > The module A can be found here: > > https://github.com/mrkkrp/mmark/blob/master/Text/MMark/Parser/Internal.hs > > There are two monadic stack wrapped with newtypes: `BParser` and > `IParser`. > > The module B is this: > > https://github.com/mrkkrp/mmark/blob/master/Text/MMark/Parser.hs > > But it's not really relevant. > > Now if I change `newtype`s to `type` synonyms like so: > > {{{ > type BParser a = ParsecT MMarkErr Text (State BlockState) a > type IParser a = StateT InlineState (Parsec MMarkErr Text) a > }}} > > and do corresponding minor corrections, I get 2x less allocations and > almost 2x faster code (before): > > {{{ > Case Allocated GCs Max > with file: data/bench-yaml-block.md 119,080 0 11,088 > with file: data/bench-thematic-break.md 74,368 0 10,224 > with file: data/bench-heading.md 901,928 0 9,432 > with file: data/bench-fenced-code-block.md 145,744 0 9,368 > with file: data/bench-indented-code-block.md 124,312 0 9,368 > with file: data/bench-unordered-list.md 2,010,496 1 10,784 > with file: data/bench-ordered-list.md 2,025,016 1 10,728 > with file: data/bench-blockquote.md 1,961,672 1 42,648 > with file: data/bench-paragraph.md 2,084,104 1 42,648 > with file: data/comprehensive.md 25,899,496 24 44,200 > > benchmarking with file: data/comprehensive.md > time 3.590 ms (3.578 ms .. 3.601 ms) > 1.000 R² (1.000 R² .. 1.000 R²) > mean 3.555 ms (3.546 ms .. 3.565 ms) > std dev 31.07 μs (24.63 μs .. 39.90 μs) > }}} > > After: > > {{{ > Case Allocated GCs Max > with file: data/bench-yaml-block.md 116,864 0 11,088 > with file: data/bench-thematic-break.md 64,776 0 10,392 > with file: data/bench-heading.md 615,672 0 9,432 > with file: data/bench-fenced-code-block.md 144,736 0 9,368 > with file: data/bench-indented-code-block.md 123,352 0 9,368 > with file: data/bench-unordered-list.md 795,072 0 41,568 > with file: data/bench-ordered-list.md 808,808 0 41,512 > with file: data/bench-blockquote.md 826,392 0 41,568 > with file: data/bench-paragraph.md 881,432 0 41,568 > with file: data/comprehensive.md 10,945,104 10 44,440 > > benchmarking with file: data/comprehensive.md > time 2.451 ms (2.448 ms .. 2.456 ms) > 1.000 R² (1.000 R² .. 1.000 R²) > mean 2.432 ms (2.427 ms .. 2.437 ms) > std dev 15.86 μs (13.16 μs .. 19.01 μs) > }}} > > I'm not great at reading non-trivial core, but I gave it a shot and > dumped > some core. One thing I noticed that core for the module A is the same in > both cases. Then the problem is an inter-module problem, probably like > when > you don't dump definitions into interface files with `INLINEABLE` and end > up > without specialization, but here it perhaps has to do with the fact that > B > has no information about internals of the monadic stacks from A, but I'm > not > sure. > > Here is the beginnings of core dumps (before): > > {{{ > ==================== Tidy Core ==================== > 2017-12-23 04:55:17.967944505 UTC > > Result size of Tidy Core > = {terms: 210,169, > types: 209,675, > coercions: 82,492, > joins: 973/3,753} > }}} > > After: > > {{{ > ==================== Tidy Core ==================== > 2017-12-23 04:58:46.386265108 UTC > > Result size of Tidy Core > = {terms: 301,256, > types: 263,104, > coercions: 28,560, > joins: 1,726/5,393} > }}} > > So it looks like `newtype` wrapping reduces GHC's ability to create join > points SPJ talked about recently. > > I do understand that you expect a minimal reproducing example but I could > not produce it even though I spent several hours in futile attempts. I > started by creating a small project, defining a similar stack with a > `newtype` wrapper and using it in a simple parser in another module. Then > I > benchmarked the parser. There is no difference between `newtype`d and > code > and the code that uses just type synonyms. I tried different variations, > no difference. > > The core output is too big for me to analyze, it's like 25 Mb and 33 Mb, > and I have no idea what's going on there. > > You're welcome to experiment with the repo, there are benchmarks for > memory usage and criterion benchmarks for speed of execution: > > https://github.com/mrkkrp/mmark > > If you like I can create a separate branch with newtypes replaced with > type synonyms, so you can compare the both approaches easier. > > I'm submitting this because my friend convinced me that it's better to > let you know (even though I could not create a minimal reproducing > example on my own) than to let it go completely unnoticed. New description: I have a project where I in one module (A) I decided to build something like a minimal framework for the other bigger module (B) to use. One of the main points of the framework is that the monadic stacks are hidden behind `newtype`s and in those monads you can only use the functions that the module A provides. The module A can be found here: https://github.com/mrkkrp/mmark/blob/ghc-bug- newtypes/Text/MMark/Parser/Internal.hs There are two monadic stack wrapped with newtypes: `BParser` and `IParser`. The module B is this: https://github.com/mrkkrp/mmark/blob/ghc-bug-newtypes/Text/MMark/Parser.hs But it's not really relevant. Now if I change `newtype`s to `type` synonyms like so: {{{ type BParser a = ParsecT MMarkErr Text (State BlockState) a type IParser a = StateT InlineState (Parsec MMarkErr Text) a }}} and do corresponding minor corrections, I get 2x less allocations and almost 2x faster code (before): {{{ Case Allocated GCs Max with file: data/bench-yaml-block.md 119,080 0 11,088 with file: data/bench-thematic-break.md 74,368 0 10,224 with file: data/bench-heading.md 901,928 0 9,432 with file: data/bench-fenced-code-block.md 145,744 0 9,368 with file: data/bench-indented-code-block.md 124,312 0 9,368 with file: data/bench-unordered-list.md 2,010,496 1 10,784 with file: data/bench-ordered-list.md 2,025,016 1 10,728 with file: data/bench-blockquote.md 1,961,672 1 42,648 with file: data/bench-paragraph.md 2,084,104 1 42,648 with file: data/comprehensive.md 25,899,496 24 44,200 benchmarking with file: data/comprehensive.md time 3.590 ms (3.578 ms .. 3.601 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 3.555 ms (3.546 ms .. 3.565 ms) std dev 31.07 μs (24.63 μs .. 39.90 μs) }}} After: {{{ Case Allocated GCs Max with file: data/bench-yaml-block.md 116,864 0 11,088 with file: data/bench-thematic-break.md 64,776 0 10,392 with file: data/bench-heading.md 615,672 0 9,432 with file: data/bench-fenced-code-block.md 144,736 0 9,368 with file: data/bench-indented-code-block.md 123,352 0 9,368 with file: data/bench-unordered-list.md 795,072 0 41,568 with file: data/bench-ordered-list.md 808,808 0 41,512 with file: data/bench-blockquote.md 826,392 0 41,568 with file: data/bench-paragraph.md 881,432 0 41,568 with file: data/comprehensive.md 10,945,104 10 44,440 benchmarking with file: data/comprehensive.md time 2.451 ms (2.448 ms .. 2.456 ms) 1.000 R² (1.000 R² .. 1.000 R²) mean 2.432 ms (2.427 ms .. 2.437 ms) std dev 15.86 μs (13.16 μs .. 19.01 μs) }}} I'm not great at reading non-trivial core, but I gave it a shot and dumped some core. One thing I noticed that core for the module A is the same in both cases. Then the problem is an inter-module problem, probably like when you don't dump definitions into interface files with `INLINEABLE` and end up without specialization, but here it perhaps has to do with the fact that B has no information about internals of the monadic stacks from A, but I'm not sure. Here is the beginnings of core dumps (before): {{{ ==================== Tidy Core ==================== 2017-12-23 04:55:17.967944505 UTC Result size of Tidy Core = {terms: 210,169, types: 209,675, coercions: 82,492, joins: 973/3,753} }}} After: {{{ ==================== Tidy Core ==================== 2017-12-23 04:58:46.386265108 UTC Result size of Tidy Core = {terms: 301,256, types: 263,104, coercions: 28,560, joins: 1,726/5,393} }}} So it looks like `newtype` wrapping reduces GHC's ability to create join points SPJ talked about recently. I do understand that you expect a minimal reproducing example but I could not produce it even though I spent several hours in futile attempts. I started by creating a small project, defining a similar stack with a `newtype` wrapper and using it in a simple parser in another module. Then I benchmarked the parser. There is no difference between `newtype`d and code and the code that uses just type synonyms. I tried different variations, no difference. The core output is too big for me to analyze, it's like 25 Mb and 33 Mb, and I have no idea what's going on there. You're welcome to experiment with the repo, there are benchmarks for memory usage and criterion benchmarks for speed of execution: https://github.com/mrkkrp/mmark I have created two branches I won't touch, one with newtypes and another one with type synonyms: * https://github.com/mrkkrp/mmark/tree/ghc-bug-newtypes * https://github.com/mrkkrp/mmark/tree/ghc-bug-type-synonyms Just checkout one of these and run `stack bench`. This is the commit that changes newtypes to type synonyms: https://github.com/mrkkrp/mmark/commit/759d8d4aa52dd57a393299c63e8c9b70d0d43290 I'm submitting this because my friend convinced me that it's better to let you know (even though I could not create a minimal reproducing example on my own) than to let it go completely unnoticed. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 24 15:51:45 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Dec 2017 15:51:45 -0000 Subject: [GHC] #14611: Support LIBRARY_PATH and LD_LIBRARY_PATH in rts Message-ID: <044.c9e86efaafe85adfbe60e6506a085329@haskell.org> #14611: Support LIBRARY_PATH and LD_LIBRARY_PATH in rts -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.2.2 System (Linker) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To complement the C compiler's usage of these, the Haskell runtime loader should use `LD_LIBRARY_PATH` to load shared libraries and the linker should use `LIBRARY_PATH` to find libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 24 15:51:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Dec 2017 15:51:56 -0000 Subject: [GHC] #14611: Support LIBRARY_PATH and LD_LIBRARY_PATH in rts In-Reply-To: <044.c9e86efaafe85adfbe60e6506a085329@haskell.org> References: <044.c9e86efaafe85adfbe60e6506a085329@haskell.org> Message-ID: <059.7866b6b120b5ecb9acf2231ced24ef05@haskell.org> #14611: Support LIBRARY_PATH and LD_LIBRARY_PATH in rts -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 (Linker) | 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 Phyx-): * owner: (none) => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 24 16:37:04 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Dec 2017 16:37:04 -0000 Subject: [GHC] #14611: Support LIBRARY_PATH and LD_LIBRARY_PATH in rts In-Reply-To: <044.c9e86efaafe85adfbe60e6506a085329@haskell.org> References: <044.c9e86efaafe85adfbe60e6506a085329@haskell.org> Message-ID: <059.7445c6206aaf0112fbce7e013ddebc35@haskell.org> #14611: Support LIBRARY_PATH and LD_LIBRARY_PATH in rts -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 8.2.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T14611 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4275 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * testcase: => T14611 * differential: => Phab:D4275 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 24 17:41:17 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Dec 2017 17:41:17 -0000 Subject: [GHC] #8033: add AVX register support to llvm calling convention In-Reply-To: <045.7dc8866bbad0b343f7d0cca58aa9a9b3@haskell.org> References: <045.7dc8866bbad0b343f7d0cca58aa9a9b3@haskell.org> Message-ID: <060.7784a751cee547b4d9770e9fcc9bd410@haskell.org> #8033: add AVX register support to llvm calling convention -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): have the GHC calling conventions bits by default been flipped on in HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 24 22:44:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Dec 2017 22:44:08 -0000 Subject: [GHC] #14612: unsolved constraints, panic during compilation Message-ID: <042.3ba6edc7514c0c2087de37afe4878bfd@haskell.org> #14612: unsolved constraints, panic during compilation -------------------------------------+------------------------------------- Reporter: msk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Code: {{{#!hs import Graphics.X11.Xlib getWindowRect :: Display -> Window -> IO Rectangle getWindowRect dpy w = fmap makeRect (getWindowAttributes dpy w) }}} Error: {{{ # ghc main.hs [1 of 1] Compiling Main ( main.hs, main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] makeRect_a1LX :: t_a1LW[tau:1] (CHoleCan: makeRect) [W] getWindowAttributes_a1M2 :: t_a1M1[tau:1] (CHoleCan: getWindowAttributes)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Compiler: {{{ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 }}} Graphics.X11.Xlib from the ArchHaskell package: {{{ haskell-x11 1.8.x0-1 }}} Frankly, I'm just following the request made by the compiler output "Please report this as a GHC bug" and have no idea what's going on. Hopefully this isn't spurious. Let me know if I can help at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 24 23:03:16 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Dec 2017 23:03:16 -0000 Subject: [GHC] #14613: Validate Failure On OSX -- implicit fall through error for machO linker support (master == ghc8.5) Message-ID: <045.c82d9958b329ffd45f64454bdb7b134e@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: Component: Compiler | Version: 8.3 (Linking) | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- seems like validate for OSX needs some TLC, heres a bug from the linker code that maybe could use an eyeball or two. Phyx suggests someone familiar with the code base could simply do ` __attribute__ ((fallthrough)); `, which is allegedly also supported by clang? {{{ "inplace/bin/ghc-stage1" -optc-fno-stack-protector -optc-Wall -optc-Werror -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-fno-strict-aliasing -optc-fno-common -optc-DDTRACE -optc- Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit- frame-pointer -optc-g -optc-DDYNAMIC -optc-DRtsWay=\"rts_dyn\" -fPIC -dynamic -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_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 -c rts/posix/GetTime.c -o rts/dist/build/posix/GetTime.dyn_o rts/linker/MachO.c: In function 'ocGetNames_MachO': rts/linker/MachO.c:1532:17: error: error: this statement may fall through [-Werror=implicit- fallthrough=] secArray[i].info->relocation_info ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ = (MachORelocationInfo*)(oc->image + section->reloff); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 1532 | = (MachORelocationInfo*)(oc->image + section->reloff); | ^ rts/linker/MachO.c:1534:13: error: note: here default: { ^~~~~~~ | 1534 | default: { }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 24 23:05:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Dec 2017 23:05:56 -0000 Subject: [GHC] #11380: Compiling a 10.000 line file exhausts memory In-Reply-To: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> References: <047.6a4d84405cfb70413f250387caf7a07e@haskell.org> Message-ID: <062.1328b0c25eac77e3f77fa1972020e45f@haskell.org> #11380: Compiling a 10.000 line file exhausts memory -------------------------------------+------------------------------------- Reporter: kennethb | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): This regressed farther in 8.2.2 and 8.0.2 (at -O1) Compiling the project in GHC-8.2.2 takes forever (~10 Hours on an i7-6700). Ram usage for compile or ghci didn't go over 3GB in the first 10 Minutes but I stopped watching it afterwards. So the compile time of ~10h could have been a result of my machine running out of ram. With 7.10.3 compiling takes less than two Minutes. GHC-8.0.2 (stackage lts-9.20) probably has the same behaviour as 8.2.2 but I didn't wait around for it to finish. Using the same lts with ghc-7.10.3 works fine. Logs for build/ghci with 8.2.2: [https://github.com/AndreasPK/pyn/tree/f77f9454aa424545b2ce8bfb460d8d275edda956 repo for repro] {{{ Compiled (-O1) [17 of 20] Compiling Language.Python.Pyn.Parser.Parser ( .stack- work\dist\5c8418a7\build\Language\Python\Pyn\Parser\Parser.hs, .stack- work\dist\5c8418a7\build\Language\Python\Pyn\Parser\Parser.o ) *** Checking old interface for Language.Python.Pyn.Lexer (use -ddump-hi- diffs for more details): *** Deleting temp files: Deleting: compile: input file C:\Users\Andi\AppData\Local\Temp\ghc81932_0\ghc_7.hscpp *** Checking old interface for Language.Python.Pyn.Parser.Parser (use -ddump-hi-diffs for more details): *** Parser [Language.Python.Pyn.Parser.Parser]: !!! Parser [Language.Python.Pyn.Parser.Parser]: finished in 937.50 milliseconds, allocated 2647.317 megabytes *** Renamer/typechecker [Language.Python.Pyn.Parser.Parser]: !!! Renamer/typechecker [Language.Python.Pyn.Parser.Parser]: finished in 35763203.12 milliseconds, allocated 109977425.131 megabytes *** Desugar [Language.Python.Pyn.Parser.Parser]: Result size of Desugar (after optimization) = {terms: 83,551, types: 2,023,928, coercions: 76,061, joins: 1/136} Interpreter: [17 of 21] Compiling Language.Python.Pyn.Parser.Parser ( C:\test\pyn \.stack-work\dist\5c8418a7\build\Language\Python\Pyn\Parser\Parser.hs, interpreted ) *** Parser [Language.Python.Pyn.Parser.Parser]: !!! Parser [Language.Python.Pyn.Parser.Parser]: finished in 890.62 milliseconds, allocated 2646.366 megabytes *** Renamer/typechecker [Language.Python.Pyn.Parser.Parser]: !!! Renamer/typechecker [Language.Python.Pyn.Parser.Parser]: finished in 35747375.00 milliseconds, allocated 109978920.259 megabytes *** Desugar [Language.Python.Pyn.Parser.Parser]: Result size of Desugar (after optimization) = {terms: 217,920, types: 3,341,879, coercions: 76,475, joins: 0/653} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 25 00:14:16 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Dec 2017 00:14:16 -0000 Subject: [GHC] #14614: Compile time regression when compiling alex generated files Message-ID: <047.f06856cc15910fe8c29f9ec90b1a441f@haskell.org> #14614: Compile time regression when compiling alex generated files -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11380 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compile time increased slightly from 7.10.3 to 8.0.2 and significantly when going to 8.2.2 {{{ compiler=ghc-7.10.3 /c/test/happy-example $ time ghc Tokens.hs -fforce-recomp -fno-code [1 of 1] Compiling Tokens ( Tokens.hs, nothing ) real 0m0.243s compiler=ghc-8.0.2 /c/test/happy-example $ time ghc Tokens.hs -fforce-recomp -fno-code [1 of 1] Compiling Tokens ( Tokens.hs, nothing ) real 0m0.286s compiler=ghc-8.2.2 $ time ghc Tokens.hs -fforce-recomp -fno-code [1 of 1] Compiling Tokens ( Tokens.hs, nothing ) real 0m0.721s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 25 00:18:12 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Dec 2017 00:18:12 -0000 Subject: [GHC] #14614: Compile time regression when compiling alex generated files In-Reply-To: <047.f06856cc15910fe8c29f9ec90b1a441f@haskell.org> References: <047.f06856cc15910fe8c29f9ec90b1a441f@haskell.org> Message-ID: <062.3dfb30d4c9db7a04fe59cb046f4df1a4@haskell.org> #14614: Compile time regression when compiling alex generated files -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11380 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * Attachment "Tokens.x" added. Alex definition Tokens.hs is based on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 25 00:22:00 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Dec 2017 00:22:00 -0000 Subject: [GHC] #14614: Compile time regression when compiling alex generated files In-Reply-To: <047.f06856cc15910fe8c29f9ec90b1a441f@haskell.org> References: <047.f06856cc15910fe8c29f9ec90b1a441f@haskell.org> Message-ID: <062.a593ff2923fa4ef923d32288ac1b9157@haskell.org> #14614: Compile time regression when compiling alex generated files -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11380 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * Attachment "Tokens.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 25 00:47:02 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Dec 2017 00:47:02 -0000 Subject: [GHC] #14609: Per-instance UndecidableInstances In-Reply-To: <048.249a939a6e76cafabb0ae79267f4d3cf@haskell.org> References: <048.249a939a6e76cafabb0ae79267f4d3cf@haskell.org> Message-ID: <063.cb9a31578c9f3c03bcee7b1ca2aaf97a@haskell.org> #14609: Per-instance UndecidableInstances -------------------------------------+------------------------------------- Reporter: ryanreich | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [ticket:14609 ryanreich]: > Can (or why can't) this also be done for UndecidableInstances? It can and should; and there's almost certainly a proposal somewhere; or a comment on a ticket on (say) overlaps or FunDeps. See also this [https://people.cs.kuleuven.be/~tom.schrijvers/portfolio/haskell2017a.html recent paper] It's a symptom of Functional Dependencies not getting much love recently/perhaps getting phased out in favour of Type Families. And a great deal of nervousness that GHC's implementation of UndecidableInstances is [https://ghc.haskell.org/trac/ghc/ticket/10675#comment:15 bogus] -- which to me argues we should encourage a per-instance pragma, to limit the bogusness. Perhaps we should try to root out the bogusness: [https://github.com/ghc- proposals/ghc-proposals/pull/56 properly] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 25 01:30:44 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Dec 2017 01:30:44 -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.ce5ac9b9f59c2912956c8d78447b5ddf@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: 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: | -------------------------------------+------------------------------------- Comment (by carter): this pragma seems to only be needed by GCC, but not be clang (or equivalently clang does not support this pragma at statements , just definitions) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 25 11:52:06 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Dec 2017 11:52:06 -0000 Subject: [GHC] #14610: newtype wrapping of a monadic stack kills performance In-Reply-To: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> References: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> Message-ID: <060.b2792123347668c42a181cd69112c29b@haskell.org> #14610: newtype wrapping of a monadic stack kills performance -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > So it looks like newtype wrapping reduces GHC's ability to create join points SPJ talked about recently. Without looking at the code: This is a good guess. `foo x = if … then foo (x+1) else …` is a tail call (and hence allows `foo` to be a join point) while `foo x = if … then foo (x+1) `cast` coercion … else …` is not. But (from an operational point of view) it could well be! But someone would have to produce a minimal example to be sure this is really the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 25 12:03:26 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Dec 2017 12:03:26 -0000 Subject: [GHC] #14614: Compile time regression when compiling alex generated files In-Reply-To: <047.f06856cc15910fe8c29f9ec90b1a441f@haskell.org> References: <047.f06856cc15910fe8c29f9ec90b1a441f@haskell.org> Message-ID: <062.aa3b085bf27da110479f7adf36c2fdbf@haskell.org> #14614: Compile time regression when compiling alex generated files -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11380 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => closed * resolution: => invalid Old description: > Compile time increased slightly from 7.10.3 to 8.0.2 and significantly > when going to 8.2.2 > > {{{ > compiler=ghc-7.10.3 > > /c/test/happy-example > $ time ghc Tokens.hs -fforce-recomp -fno-code > [1 of 1] Compiling Tokens ( Tokens.hs, nothing ) > > real 0m0.243s > > > compiler=ghc-8.0.2 > > /c/test/happy-example > $ time ghc Tokens.hs -fforce-recomp -fno-code > [1 of 1] Compiling Tokens ( Tokens.hs, nothing ) > > real 0m0.286s > > > compiler=ghc-8.2.2 > > $ time ghc Tokens.hs -fforce-recomp -fno-code > [1 of 1] Compiling Tokens ( Tokens.hs, nothing ) > > real 0m0.721s > }}} New description: This seems to be caused by the difference in package dbs resulting in a constant time difference. -- Comment: This takes 0.8 seconds to just typecheck and desugar on GHC-8.2.2: {{{ module Tokens where import GHC.Exts data AlexAddr = AlexA# Addr# }}} 8.0.2: {{{ $ time ghc T.hs -fforce-recomp -fno-code [1 of 1] Compiling Tokens ( T.hs, nothing ) real 0m0.354s user 0m0.000s sys 0m0.000s }}} 8.2.2: {{{ time ghc T.hs -fforce-recomp -fno-code [1 of 1] Compiling Tokens ( T.hs, nothing ) real 0m0.866s user 0m0.015s sys 0m0.000s }}} T -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 25 14:06:04 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Dec 2017 14:06:04 -0000 Subject: [GHC] #14592: Totality checking In-Reply-To: <045.248ecf06ff86b05ee9f7ac04c7a37292@haskell.org> References: <045.248ecf06ff86b05ee9f7ac04c7a37292@haskell.org> Message-ID: <060.471776f7bcfc16c8c82fb98d6035ccad@haskell.org> #14592: Totality checking -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Great! I didn't know that. Thanks! This is third-party solution. It'll be great if GHC has totality checking embedded into the language itself, like Idris has. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 25 18:13:17 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Dec 2017 18:13:17 -0000 Subject: [GHC] #14615: Segfault when printing a simple string Message-ID: <051.9e7ed3f4287aabd28eba38bc726d4321@haskell.org> #14615: Segfault when printing a simple string -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: Christmas | 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 segfaults on GHC 8.2.1 and 8.3.20171208 {{{#!hs -- Segfault.hs main = do let xs = [1,1,1,1,1,1,5,0,1,1,1,1,1,4,2,4,0,1,1,1,1,4,2,2,2,4,0,1,1,1,4,2,3,2,2,3,4,0,1,1,4,3,2,2,3,2,2,2,4,0,1,4,2,2,3,2,2,2,3,2,2,4,0,4,2,3,2,2,2,3,2,2,3,2,2,4,0,1,1,1,1,1,1,2,0,1,1,1,1,1,1,2] let f ?? x = fmap ($ x) f putStrLn (traverse ((??) (!!)) xs "\n #%.t") }}} when running it as {{{ $ runghc -ignore-dot-ghci -dcore-lint -fdefer-type-errors Segfault.hs Segmentation fault: 11 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 25 20:15:39 2017 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Dec 2017 20:15:39 -0000 Subject: [GHC] #14616: panic! initTc: unsolved constraints Message-ID: <044.523ebc7b1b9bfb6dc0d106032ec119ac@haskell.org> #14616: panic! initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: w-j-w | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- New haskeller here, I was doing an exercise at http://exercism.io/exercises/haskell /rotational-cipher/readme and got the following error message from the compiler. {{{ Compiling Main ( RotationalCipher.hs, .stack-work/dist/x86_64 -linux-tinfo6/Cabal-1.24.2.0/build/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] find_a7hU :: t_a7hT[tau:1] (CHoleCan: find) [W] find_a7iF :: t_a7iE[tau:1] (CHoleCan: find)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Progress: 16/17 -- While building custom Setup.hs for package rotational-cipher-1.1.0.1 using: /home/websterw/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal- simple_mPHDZzAJ_1.24.2.0_ghc-8.0.2 --builddir=.stack-work/dist/x86_64 -linux-tinfo6/Cabal-1.24.2.0 build lib:rotational-cipher test:test --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} I was using the normal project setup that exercism uses for this problem, with my code residing a file called `RotationalCipher.hs`. The contents of this file are as follows. {{{ rotate :: Int -> String -> String rotate n = map (rot n) rot :: Int -> Char -> Char rot i c | c `elem` ['a'..'z'] = let translate = zip (lowershift n) ['a'..'z'] in fst (find (\x -> snd x == c) translate) | c `elem` ['A'..'Z'] = let translate = zip (uppershift n) ['A'..'Z'] in fst (find (\x -> snd x == c) translate) | otherwise = c where lowershift n = take 26 $ drop n $ cycle ['a'..'z'] uppershift n = take 26 $ drop n $ cycle ['A'..'Z'] }}} The error occured when I ran `stack test` I am using fedora linux as my operating system on x86_64 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 00:03:28 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 00:03:28 -0000 Subject: [GHC] #14616: panic! initTc: unsolved constraints In-Reply-To: <044.523ebc7b1b9bfb6dc0d106032ec119ac@haskell.org> References: <044.523ebc7b1b9bfb6dc0d106032ec119ac@haskell.org> Message-ID: <059.869abb0ffc374e9fa94d98393b1e45c5@haskell.org> #14616: panic! initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: w-j-w | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.3 Component: Compiler | Version: 8.0.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => duplicate * related: => #13106 * milestone: => 8.2.3 Comment: It appears that this is a slightly unusual duplicate of #13106, which was fixed in 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 00:13:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 00:13:06 -0000 Subject: [GHC] #14615: Segfault when printing a simple string In-Reply-To: <051.9e7ed3f4287aabd28eba38bc726d4321@haskell.org> References: <051.9e7ed3f4287aabd28eba38bc726d4321@haskell.org> Message-ID: <066.4b8734d7a27175333e38340420818d45@haskell.org> #14615: Segfault when printing a simple string -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Christmas Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => infoneeded Comment: The program in question seems to work just fine on Linux with both GHC 8.2.1 and a fairly recent head. Based on the program behavior and the `Christmas` keyword, I have to ask if this report is a joke. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 01:08:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 01:08:09 -0000 Subject: [GHC] #14610: newtype wrapping of a monadic stack kills performance In-Reply-To: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> References: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> Message-ID: <060.8b93074c61c747b910bbc4f603c0827c@haskell.org> #14610: newtype wrapping of a monadic stack kills performance -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I haven't yet been able to reproduce quite the same behavior, but this small example looks like it could be related. If I write {{{#!hs foo :: forall a. (Int -> Bool) -> Int -> a -> a foo p = go where go :: Int -> a -> a go !n a | p n = a | otherwise = go (n + 1) a }}} then I get {{{ foo = \ (@ a_aYZ) (p_aWO :: Int -> Bool) (eta_B2 :: Int) (eta1_B1 :: a_aYZ) -> case eta_B2 of { GHC.Types.I# ww1_s1bZ -> joinrec { $wgo_s1c1 [InlPrag=NOUSERINLINE[0], Occ=LoopBreaker] :: GHC.Prim.Int# -> a_aYZ -> a_aYZ [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] $wgo_s1c1 (ww2_X1cu :: GHC.Prim.Int#) (w_s1bW :: a_aYZ) = case p_aWO (GHC.Types.I# ww2_X1cu) of { False -> jump $wgo_s1c1 (GHC.Prim.+# ww2_X1cu 1#) w_s1bW; True -> w_s1bW }; } in jump $wgo_s1c1 ww1_s1bZ eta1_B1 } }}} But if I make `go` polymorphic, {{{#!hs foo :: (Int -> Bool) -> Int -> a -> a foo p = go where go :: Int -> b -> b go !n a | p n = a | otherwise = go (n + 1) a }}} I get a wrapper and this worker: {{{#!hs T14610.$wfoo = \ (@ a_s1cm) (w_s1cn :: Int -> Bool) (ww_s1cs :: GHC.Prim.Int#) (w1_s1cp :: a_s1cm) -> letrec { $wgo_s1cl [InlPrag=NOUSERINLINE[0], Occ=LoopBreaker] :: forall b. GHC.Prim.Int# -> b -> b [LclId, Arity=2, Str=, Unf=OtherCon []] $wgo_s1cl = \ (@ b_s1ce) (ww1_s1cj :: GHC.Prim.Int#) (w2_s1cg :: b_s1ce) -> case w_s1cn (GHC.Types.I# ww1_s1cj) of { False -> $wgo_s1cl @ b_s1ce (GHC.Prim.+# ww1_s1cj 1#) w2_s1cg; True -> w2_s1cg }; } in $wgo_s1cl @ a_s1cm ww_s1cs w1_s1cp }}} This distinction remains as `let` vs. `let-no-escape` in STG. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 01:08:55 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 01:08:55 -0000 Subject: [GHC] #14610: newtype wrapping of a monadic stack kills performance In-Reply-To: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> References: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> Message-ID: <060.9a07f7aaaf3bd332dac6a34d2455fc68@haskell.org> #14610: newtype wrapping of a monadic stack kills performance -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) * failure: None/Unknown => Runtime performance bug * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 01:09:41 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 01:09:41 -0000 Subject: [GHC] #14615: Segfault when printing a simple string In-Reply-To: <051.9e7ed3f4287aabd28eba38bc726d4321@haskell.org> References: <051.9e7ed3f4287aabd28eba38bc726d4321@haskell.org> Message-ID: <066.5e60b17b6269c4942a8df59caa8bd16d@haskell.org> #14615: Segfault when printing a simple string -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Christmas Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 04:48:57 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 04:48:57 -0000 Subject: [GHC] #14617: Join point test join001 doesn't seem to be properly automated Message-ID: <045.8df871e2e6ed60aeb57e9e867858e89d@haskell.org> #14617: Join point test join001 doesn't seem to be properly automated -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.2 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The test `join001` was presumably used for manual testing (poring over the Core by hand). Unfortunately, the test suite runs it in an utterly bland fashion that doesn't appear to check whether the join point transformation is working as intended. The other join point tests run in this fashion (`join005` and `join006`) include notes indicating that Core Lint will trip if the desired property doesn't hold; there is no such note here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 05:29:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 05:29:35 -0000 Subject: [GHC] #14610: newtype wrapping of a monadic stack kills performance In-Reply-To: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> References: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> Message-ID: <060.82209e1069c266e3c019d4eb025626a1@haskell.org> #14610: newtype wrapping of a monadic stack kills performance -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Here's an example that doesn't quite go far enough to demonstrate the problem, but seems closer in spirit to the original. {{{#!hs newtype D a = D {getD :: a} d :: a -> D a d a = D a baz :: D Int -> Int -> D Int baz y x0 = foo x0 where foo :: Int -> D Int foo 0 = y foo x = D (bar (x - 3)) bar :: Int -> Int bar 0 = getD y bar x = getD (foo x) }}} Compiling with `-dverbose-core2core`, we see that after the first simplifier run (gentle, before floating), we get {{{ baz :: D Int -> Int -> D Int [LclIdX, Arity=2, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0] 121 0}] baz = \ (y_aSE :: D Int) (x0_aSF :: Int) -> letrec { foo_aSG [Occ=LoopBreaker] :: Int -> D Int [LclId, Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20] 81 0}] foo_aSG = \ (ds_d27R :: Int) -> case ds_d27R of { GHC.Types.I# ds_d27T -> case ds_d27T of ds_X289 { __DEFAULT -> (case ds_X289 of ds_X284 { __DEFAULT -> (foo_aSG (GHC.Types.I# (GHC.Prim.-# ds_X284 3#))) `cast` (Foo.N:D[0] _R :: (D Int :: *) ~R# (Int :: *)); 3# -> y_aSE `cast` (Foo.N:D[0] _R :: (D Int :: *) ~R# (Int :: *)) }) `cast` (Sym (Foo.N:D[0] _R) :: (Int :: *) ~R# (D Int :: *)); 0# -> y_aSE } }; } in foo_aSG x0_aSF }}} Note that `foo_aSG` is bound by `letrec`. If we switch to a type synonym version, {{{#!hs type D a = a getD :: D a -> a getD a = a d :: a -> D a d a = a baz :: Int -> Int -> Int baz y x0 = foo x0 where foo :: Int -> Int foo 0 = y foo x = d (bar (x - 3)) bar :: Int -> Int bar 0 = getD y bar x = getD (foo x) }}} then at the same point in core2core we instead see {{{#!hs baz :: Int -> Int -> Int [LclIdX, Arity=2, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0] 59 0}] baz = \ (y_aSQ :: Int) (x0_aSR :: Int) -> joinrec { foo_aSS [Occ=LoopBreaker] :: Int -> Int [LclId[JoinId(1)], Arity=1, Unf=Unf{Src=, TopLvl=False, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [20] 55 0}] foo_aSS (ds_d27X :: Int) = case ds_d27X of { GHC.Types.I# ds_d27Z -> case ds_d27Z of ds_X28a { __DEFAULT -> jump foo_aSS (GHC.Types.I# (GHC.Prim.-# ds_X28a 3#)); 0# -> y_aSQ; 3# -> y_aSQ } }; } in jump foo_aSS x0_aSR }}} The reason this example doesn't quite go far enough is that later transformations work out the kinks and recognize the join point. But based on the bug report, that isn't always the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 12:29:40 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 12:29:40 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.2c83c70cc5826b85c00197ad84b24293@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"e19b6464cc8ea498775074a680f91d3e5b5636d3/ghc" e19b6464/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e19b6464cc8ea498775074a680f91d3e5b5636d3" Compute InScopeSet in substInteractiveContext It doesn't look like we keep any sets of free variables of the types of Ids handy, so we just have to build them when doing a substitution. Test Plan: buildbot + run testsuite with debug Reviewers: simonmar, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: carter, rwbarton, thomie GHC Trac Issues: #11371 Differential Revision: https://phabricator.haskell.org/D3431 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 14:11:46 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 14:11:46 -0000 Subject: [GHC] #14618: Higher rank typechecking is broken Message-ID: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> #14618: Higher rank typechecking is broken -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- The oddity was noticed when someone asked the type of `lens` from lambdabot and it replied with {{{#!hs 1514165211 [04:26:51] Functor f => (s1 -> a1) -> (s1 -> b1 -> t1) -> (a2 -> f b2) -> s2 -> f t2 }}} This disagrees with `lens`'s type per definition (way too many foralls and unconstrained type variables), and if handled carefully it could be used to implement `unsafeCoerce` within SafeHaskell. The minimalest example I could come up with: {{{#!hs {-# LANGUAGE RankNTypes #-} safeCoerce :: a -> b safeCoerce = f' where f :: d -> forall c. d f x = x f' = f }}} This compiles and typechecks on GHC 8.2.2, 8.2.1 (courtesy of hydraz) and HEAD. But not on 8.0.2 (hydraz) or 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 16:05:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 16:05:23 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations Message-ID: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The optimisation pass seems to affect the behaviour of the attached program (a basic ray-sphere intersection test, 40 lines long, no dependencies). Specifically, compiling the attached source file with -O or -O2, and considering the definition of main: {{{#!hs result = sphereIntersection testRay testSphere main :: IO() main = do print $ result print $ sphereIntersection testRay testSphere }}} I get the troubling output: {{{ > bug.exe Just ((0.0,0.0,0.0),0.0) Just ((0.0,0.0,100.0),1.0) }}} This is especially troubling because the second component of the output should always be 1.0: {{{#!hs testRay = ((0, 0, 0),(0, 0, 1)) sphereIntersection (orig, dir@(_, _, dirz)) (c,r) | disc < 0 = Nothing | t1 > 0 = Just (t1 *> dir <+> orig, dirz) | t2 > 0 = Just (t2 *> dir <+> orig, dirz) | otherwise = Nothing where ... }}} as we are returning the "dirz" component of the input ray straight back out. On the other hand, when the program is run without optimisations, I get the expected output: {{{ > bug.exe Just ((0.0,0.0,100.0),1.0) Just ((0.0,0.0,100.0),1.0) }}} This behaviour was present on all versions of GHC that I tested (7.10.1, 8.0.1, 8.2.1, 8.2.2). I initially ran into this issue when I noticed that the profiling builds of my program produced different results, which was boiled down to this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 16:05:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 16:05:47 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.36c3108fccaf55798d564dbdf49ec4a6@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sheaf): * Attachment "bug.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 16:45:52 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 16:45:52 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.db8f840243e2683be233155d100070d3@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * os: Windows => Unknown/Multiple Comment: Thanks for the report!, reclassifying so it gets more eyeballs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 16:54:17 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 16:54:17 -0000 Subject: [GHC] #14618: Higher rank typechecking is broken In-Reply-To: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> References: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> Message-ID: <059.4784ae5a762a98dabc44a1f27ce27ec9@haskell.org> #14618: Higher rank typechecking is broken -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.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 int-e): * cc: int-e (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 18:19:05 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 18:19:05 -0000 Subject: [GHC] #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE In-Reply-To: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> References: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> Message-ID: <064.625e10c8b95846d8940efe1fed267e89@haskell.org> #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: performance, | inline, bits 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 m-renaud): Hey, just following up on this, there's still an open issue in containers[1] awaiting this change to go in. Is there any fundamental reason why these instance functions cannot be marked INLINE? [1] https://github.com/haskell/containers/pull/216 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 18:31:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 18:31:38 -0000 Subject: [GHC] #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE In-Reply-To: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> References: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> Message-ID: <064.11e739b167fc7e63f5400020e1f18da5@haskell.org> #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: performance, | inline, bits Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Is there a reason why they should be marked `INLINE`? The note seems to indicate that GHC inlines these functions anyway, they look small so I suspect this is the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 18:34:51 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 18:34:51 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.8ff2fa0b7f17add66fadb2f212b745f2@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): What exact invocation of GHC are you using to reproduce this? I can't with > `ghc bug.hs` and > `ghc -O2 bug.hs` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 18:42:37 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 18:42:37 -0000 Subject: [GHC] #14618: Higher rank typechecking is broken In-Reply-To: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> References: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> Message-ID: <059.5d8d69d1605e48cb5928d59854af97f0@haskell.org> #14618: Higher rank typechecking is broken -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.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 mpickering): There is a core lint error at least.. {{{ [1 of 1] Compiling Foo ( unco.hs, unco.o ) *** Core Lint errors : in result of Desugar (after optimization) *** unco.hs:5:1: warning: [RHS of safeCoerce :: forall a b. a -> b] The type of this binder doesn't match the type of its RHS: safeCoerce Binder's type: forall a b. a -> b Rhs type: forall a b. b -> b *** Offending Program *** safeCoerce :: forall a b. a -> b [LclIdX] safeCoerce = \ (@ a_ao7) (@ b_ao8) -> let { f_anO :: forall d. d -> forall c. d [LclId] f_anO = \ (@ d_aop) (dk_aSV :: d_aop) (@ c_aos) -> dk_aSV } in \ (di_aSY :: b_ao8) -> f_anO @ b_ao8 di_aSY @ Any $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Foo"#) *** End of Offense *** : error: Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 18:47:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 18:47:14 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.9c8f3836b52f07dfb67fbab99aaa5919@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 19:03:11 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 19:03:11 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.c05251d4990b4f84c6cea3d7e0593660@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sheaf): I'm not doing anything specific at all, just plain vs -O2 as you seem to be doing. {{{ > ghc bug.hs [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug.exe ... > bug Just ((0.0,0.0,100.0),1.0) Just ((0.0,0.0,100.0),1.0) > ghc bug.hs -O2 -fforce-recomp [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug.exe ... > bug Just ((0.0,0.0,0.0),0.0) Just ((0.0,0.0,100.0),1.0) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 19:06:29 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 19:06:29 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.42f2d205fa71ee2555fa013a5d634e34@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: infoneeded => new * os: Unknown/Multiple => Windows Comment: Phyx said that he could reproduce something wrong using his windows server. Can you provide some details about your machine? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 19:07:47 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 19:07:47 -0000 Subject: [GHC] #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE In-Reply-To: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> References: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> Message-ID: <064.cf5b3f171df6a8a4c06b5f03b07f4801@haskell.org> #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: performance, | inline, bits Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 19:08:10 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 19:08:10 -0000 Subject: [GHC] #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE In-Reply-To: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> References: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> Message-ID: <064.54a26769dbc37e6b6fe01d91d0c892cc@haskell.org> #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: performance, | inline, bits Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * os: Windows => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 19:11:26 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 19:11:26 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.68ed70be23e0bbe4e3a9490ec4bca521@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sheaf): Sure thing. I'm running Windows 7 64-bit, on an Intel i7-3820 CPU. Let me know what other information would be helpful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 19:13:06 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 19:13:06 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.d7de9f53970e39573f0bf27e2392e62f@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Guess it is Windows specific... {{{ Tamar at Rage ~/g/l/p/t/T3994.run> ghc "bug.hs" -O2 -fforce-recomp; ./bug.exe [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug.exe ... Just ((0.0,0.0,0.0),0.0) Just ((0.0,0.0,100.0),1.0) }}} {{{ Tamar at Rage ~/g/l/p/t/T3994.run> ghc "bug.hs" -O2 -fforce-recomp -fno- worker-wrapper; ./bug.exe [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug.exe ... Just ((0.0,0.0,100.0),1.0) Just ((0.0,0.0,100.0),1.0) }}} {{{ Tamar at Rage ~/g/l/p/t/T3994.run> ~/ghc2/inplace/bin/ghc-stage2.exe "bug.hs" -O2 -fforce-recomp; ./bug.exe [1 of 1] Compiling Main ( bug.hs, bug.o ) Linking bug.exe ... Just ((0.0,0.0,100.0),1.0) Just ((0.0,0.0,100.0),1.0) }}} So it seems to work on HEAD also, but the 8.0.2 fails.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 19:21:59 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 19:21:59 -0000 Subject: [GHC] #14618: Higher rank typechecking is broken In-Reply-To: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> References: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> Message-ID: <059.0e55df7d9234c7f093addc8aa25f9008@haskell.org> #14618: Higher rank typechecking is broken -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.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 goldfire): How utterly frightening. I have a fix. Validating now. Thanks for the wonderfully simple test case! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 19:42:00 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 19:42:00 -0000 Subject: [GHC] #14610: newtype wrapping of a monadic stack kills performance In-Reply-To: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> References: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> Message-ID: <060.b243b2f9ccbcc5b48fe830e15fd99f12@haskell.org> #14610: newtype wrapping of a monadic stack kills performance -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) Comment: The polymorphic `go` in comment:3 is a separate problem from the one that I described further up (but it might well be the OP’s problem). It could be fixed by static argument transformation. On my TODO list, after #14068, is SAT for join points, but it would not help here, because only after SAT it is a join point. Exitification unfortunately also does not help to turn this into a joint point. Maybe worth opening a separate ticket. Your example in comment:4 is precisely what I described, thanks for working it out. The fix here probably requires some significant thought about the join point typing. Maybe it is enough to relax the rule “The return type must not depend on any arguments” to “The return type must be representatoinally equal for all arguments” and that might allow us to {{{e `cast` co}}} to be a tail-call position. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 19:46:38 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 19:46:38 -0000 Subject: [GHC] #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE In-Reply-To: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> References: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> Message-ID: <064.71c0dfe145880364aadab4e2d52a9bb3@haskell.org> #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: performance, | inline, bits 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 m-renaud): This all predates me but in comment 2 above thomie@ points out: "But that `Note` is older (2008) than the commit that introduced `unsafeShiftL/R` ([f1c593e01d740fde1202f84aa37ad4cc95ec7272], 2011)." In fact, these functions ''are'' marked INLINE in the typeclass definition when they were introduced, and if the assumption is that GHC ''should'' always inline them, then why not make that explicit in the Int and Word instances? It appears this may have simply been an oversight. In containers if these functions are not inlined it is my understanding that there is a performance hit which is why there is custom code to ensure that these shifts are inlined (https://github.com/haskell/containers/blob/master/Utils/Containers/Internal/BitUtil.hs#L74-L89). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 20:28:27 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 20:28:27 -0000 Subject: [GHC] #14592: Totality checking In-Reply-To: <045.248ecf06ff86b05ee9f7ac04c7a37292@haskell.org> References: <045.248ecf06ff86b05ee9f7ac04c7a37292@haskell.org> Message-ID: <060.4b84e580b26e266f4c567e459860b51d@haskell.org> #14592: Totality checking -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): There's a downside to totality checking: it means that the language needs to be simple enough to support it. GHC has several features making totality checking hard: * `Type :: Type` (whereas Idris has `Type :: Type 1`, `Type 1 :: Type 2`, etc.) * The `Type.Reflection` library (a.k.a. `Typeable`). Section 7 of the recent [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1002&context=compsci_pubs paper] shows how `Typeable` can lead to non-termination without recursion. * Non-strictly-positive datatypes (sorry, I don't know how Idris handles these, nor do I have a good reference for more information) * Pattern synonyms (should we trust `COMPLETE` pragmas here?) * Probably more... I agree that having a totality checker would be wonderful. But writing one with GHC's current feature set is a major research undertaking, and then maintaining it might force GHC to slow down its innovation in other areas. This isn't really an argument against it, but I just wanted to highlight that there are major tradeoffs here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 20:31:09 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 20:31:09 -0000 Subject: [GHC] #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE In-Reply-To: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> References: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> Message-ID: <064.e3662647664f1cccbd9876fbae2b0b3d@haskell.org> #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: performance, | inline, bits Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): To take that example you linked, it is peculiar as depending on whether `__GLASGOW_HASKELL__` is set, `shiftLL` has different semantics. Running the program {{{ {-# LANGUAGE MagicHash #-} module Main where import Bits import GHC.Exts (Word(..), Int(..)) import GHC.Prim (uncheckedShiftL#, uncheckedShiftRL#) shiftRL :: Word -> Int -> Word shiftRL x i = shiftR x i shiftRL' :: Word -> Int -> Word shiftRL' (W# x) (I# i) = W# (uncheckedShiftRL# x i) main = do print $ shiftRL 1 65 print $ shiftRL' 1 65 }}} Yields {{{ 0 shift: Bad shift length65 }}} But ignoring this fact, if you inspect the [https://imgur.com/a/DLDjo core] you see that the result is the same as the handwritten "optimised" definition so I'm not sure what the intention is here with the additional complexity... > In fact, these functions are marked INLINE in the typeclass definition when they were introduced, and if the assumption is that GHC should always inline them, then why not make that explicit in the Int and Word instances? In general the compiler has much more information available at call sites to decide whether to inline a definition than a library author does at definition site. Preoptimisation, adding `INLINE` pragmas everywhere, can be very detrimental as the compiler can no longer decide whether it is worthwhile to do the inlining itself. In this case, I think the compiler will decide to inline all these small functions so there is no reason to add an `INLINE` pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 21:10:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 21:10:45 -0000 Subject: [GHC] #14618: Higher rank typechecking is broken In-Reply-To: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> References: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> Message-ID: <059.f6d9f6ddb493e057fd934a1068e8673c@haskell.org> #14618: Higher rank typechecking is broken -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.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 mniip): Can't help but be curious about what caused this. Something related to broken instantiation before constraint solving, or overzealous generalization afterwards? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 21:11:32 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 21:11:32 -0000 Subject: [GHC] #14618: Higher rank typechecking is broken In-Reply-To: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> References: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> Message-ID: <059.6dda4ce1c5d4765b887d8d995f0576c8@haskell.org> #14618: Higher rank typechecking is broken -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.2.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 Richard Eisenberg ): In [changeset:"722a6584bb338bc77ad978d14113b3b8e6a45cab/ghc" 722a658/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="722a6584bb338bc77ad978d14113b3b8e6a45cab" Fix #14618 by applying a subst in deeplyInstantiate Previously, we were inexplicably not applying an instantiating substitution to arguments in non-prenex types. It's amazing this has been around for so long! I guess there aren't a lot of non-prenex types around. test case: typecheck/should_fail/T14618 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 21:13:45 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 21:13:45 -0000 Subject: [GHC] #14618: Higher rank typechecking is broken In-Reply-To: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> References: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> Message-ID: <059.d33221d30127e780d4395b735906f217@haskell.org> #14618: Higher rank typechecking is broken -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T14618 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_fail/T14618 * milestone: => 8.4.1 Comment: You can see the commit. It was just a simple oversight in propagating an instantiating substitution. This should certainly be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 21:24:56 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 21:24:56 -0000 Subject: [GHC] #14612: unsolved constraints, panic during compilation In-Reply-To: <042.3ba6edc7514c0c2087de37afe4878bfd@haskell.org> References: <042.3ba6edc7514c0c2087de37afe4878bfd@haskell.org> Message-ID: <057.18dac34ac7a28663e9e862e185b14422@haskell.org> #14612: unsolved constraints, panic during compilation -------------------------------------+------------------------------------- Reporter: msk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Have you tried with GHC 8.2? The `initTc` bug was one of the fixes for that release. I'm not in a good position to test this myself, unfortunately, but let us know here if that works and we can close the ticket. Thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 22:21:35 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 22:21:35 -0000 Subject: [GHC] #14592: Totality checking In-Reply-To: <045.248ecf06ff86b05ee9f7ac04c7a37292@haskell.org> References: <045.248ecf06ff86b05ee9f7ac04c7a37292@haskell.org> Message-ID: <060.fcba3a8010fc577efe49a8dfcae2f783@haskell.org> #14592: Totality checking -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by varosi): Totality checking ability is in close importance as stronger typing in my opinion. Idris as I know could guarantee totality only in certain types of functions, not all types functions. So similar path could be used by Haskell and widening it with next versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 22:55:23 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 22:55:23 -0000 Subject: [GHC] #14620: Polymorphic functions not easily recognized as join points Message-ID: <045.e40dfafc013d5e85dc279ef3f5b404dc@haskell.org> #14620: Polymorphic functions not easily recognized as join points -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #14610 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This grew out of ticket:14610#comment:3. If I write {{{#!hs foo :: forall a. (Int -> Bool) -> Int -> a -> a foo p = go where go :: Int -> a -> a go !n a | p n = a | otherwise = go (n + 1) a }}} then I get {{{ foo = \ (@ a_aYZ) (p_aWO :: Int -> Bool) (eta_B2 :: Int) (eta1_B1 :: a_aYZ) -> case eta_B2 of { GHC.Types.I# ww1_s1bZ -> joinrec { $wgo_s1c1 [InlPrag=NOUSERINLINE[0], Occ=LoopBreaker] :: GHC.Prim.Int# -> a_aYZ -> a_aYZ [LclId[JoinId(2)], Arity=2, Str=, Unf=OtherCon []] $wgo_s1c1 (ww2_X1cu :: GHC.Prim.Int#) (w_s1bW :: a_aYZ) = case p_aWO (GHC.Types.I# ww2_X1cu) of { False -> jump $wgo_s1c1 (GHC.Prim.+# ww2_X1cu 1#) w_s1bW; True -> w_s1bW }; } in jump $wgo_s1c1 ww1_s1bZ eta1_B1 } }}} But if I make `go` polymorphic, {{{#!hs foo :: (Int -> Bool) -> Int -> a -> a foo p = go where go :: Int -> b -> b go !n a | p n = a | otherwise = go (n + 1) a }}} I get a wrapper and this worker: {{{#!hs T14610.$wfoo = \ (@ a_s1cm) (w_s1cn :: Int -> Bool) (ww_s1cs :: GHC.Prim.Int#) (w1_s1cp :: a_s1cm) -> letrec { $wgo_s1cl [InlPrag=NOUSERINLINE[0], Occ=LoopBreaker] :: forall b. GHC.Prim.Int# -> b -> b [LclId, Arity=2, Str=, Unf=OtherCon []] $wgo_s1cl = \ (@ b_s1ce) (ww1_s1cj :: GHC.Prim.Int#) (w2_s1cg :: b_s1ce) -> case w_s1cn (GHC.Types.I# ww1_s1cj) of { False -> $wgo_s1cl @ b_s1ce (GHC.Prim.+# ww1_s1cj 1#) w2_s1cg; True -> w2_s1cg }; } in $wgo_s1cl @ a_s1cm ww_s1cs w1_s1cp }}} This distinction remains as `let` vs. `let-no-escape` in STG. As Joachim Breitner's comments seem to suggest, we could probably recognize this by applying the static argument transformation to the type argument of `go`. But we don't currently have any machinery for doing that, I don't think. Furthermore, that would fail with polymorphic recursion even if the only type changes are from `newtype`. That said, the SAT approach would presumably help when the worker has a non-essential type signature for clarity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 22:56:48 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 22:56:48 -0000 Subject: [GHC] #14610: newtype wrapping of a monadic stack kills performance In-Reply-To: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> References: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> Message-ID: <060.13e39df6e289fe2af64c142a0fc2e964@haskell.org> #14610: newtype wrapping of a monadic stack kills performance -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14620 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #14620 Comment: nomeata, I opened #14620 for the issue in comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 22:57:14 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 22:57:14 -0000 Subject: [GHC] #14612: unsolved constraints, panic during compilation In-Reply-To: <042.3ba6edc7514c0c2087de37afe4878bfd@haskell.org> References: <042.3ba6edc7514c0c2087de37afe4878bfd@haskell.org> Message-ID: <057.d6b8e45434b41c4678dcd10bf24037ad@haskell.org> #14612: unsolved constraints, panic during compilation -------------------------------------+------------------------------------- Reporter: msk | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13106 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13106 Comment: Yep, this is a duplicate of #13160. Here's the (proper) error you get on GHC 8.2.2: {{{ $ /opt/ghc/8.2.2/bin/ghci Bug.hs GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:4:28: error: Variable not in scope: makeRect :: a0 -> Rectangle | 4 | getWindowRect dpy w = fmap makeRect (getWindowAttributes dpy w) | ^^^^^^^^ Bug.hs:4:38: error: • Variable not in scope: getWindowAttributes :: Display -> Window -> IO a0 • Perhaps you meant ‘setLineAttributes’ (imported from Graphics.X11.Xlib) | 4 | getWindowRect dpy w = fmap makeRect (getWindowAttributes dpy w) | ^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 26 23:17:12 2017 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Dec 2017 23:17:12 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.42fb694e1f4c86876c52be6b7a9075c9@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => dfeuer Comment: David, perhaps you could look into this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 01:44:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 01:44:55 -0000 Subject: [GHC] #14608: Different GHCi error messages for similar scenarios In-Reply-To: <043.dc3a47548a95791f116ee7f040dff01e@haskell.org> References: <043.dc3a47548a95791f116ee7f040dff01e@haskell.org> Message-ID: <058.faeb4d758f0382b76de59531dccb44a0@haskell.org> #14608: Different GHCi error messages for similar scenarios -------------------------------------+------------------------------------- Reporter: mb64 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah. I believe the culprit is the fact that these two lines were removed: https://github.com/ghc/ghc/commit/714bebff44076061d0a719c4eda2cfd213b7ac3d #diff-6fd42166fdf8d397ba9081bb24661f1fL851 Previously, this would check that in interpreted code, any alternatives in a pattern match would not scrutinize unboxed tuples. But since that check was removed, it falls through and eventually results in the disastrous panic shown above. Luckily, we should be able to reinstate this check with relative ease. Patch coming soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 01:54:34 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 01:54:34 -0000 Subject: [GHC] #14608: Different GHCi error messages for similar scenarios In-Reply-To: <043.dc3a47548a95791f116ee7f040dff01e@haskell.org> References: <043.dc3a47548a95791f116ee7f040dff01e@haskell.org> Message-ID: <058.5be05eca9bbed338f606a44738197567@haskell.org> #14608: Different GHCi error messages for similar scenarios -------------------------------------+------------------------------------- Reporter: mb64 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4276 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D4276 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 10:09:57 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 10:09:57 -0000 Subject: [GHC] #14618: Higher rank typechecking is broken In-Reply-To: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> References: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> Message-ID: <059.f21d1a778e227ac35902eddd6454c0b3@haskell.org> #14618: Higher rank typechecking is broken -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T14618 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Should this be backported to 8.2? I feel like a complete violation of SafeHaskell might be a fairly serious concern to some users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 10:46:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 10:46:10 -0000 Subject: [GHC] #14530: hWaitForInput causes the program to abort on Windows In-Reply-To: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> References: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> Message-ID: <062.ce5ac5569e51ceec9d3169eb5df7879a@haskell.org> #14530: hWaitForInput causes the program to abort on Windows -----------------------------------+-------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Description changed by dnadales: Old description: > When running the following program on Windows (10): > > {{{#!hs > readWithinNSecs :: IO () > readWithinNSecs = withSocketsDo $ do > h <- connectTo "localhost" (PortNumber 9090) > hSetBuffering h NoBuffering > readerTid <- forkIO $ politeReader h > threadDelay (2 * 10^6) > killThread readerTid > > where > politeReader h = do > info <- hShow h > putStrLn info > line <- ifM (hWaitForInput h (10^6)) (hGetLine h) (return > "Nothing!") > putStrLn $ "Got " ++ line > }}} > > The program aborts with the following error: > > {{{#!text > {loc=,type=duplex (read-write),buffering=none} > fdReady: fd is too big > This application has requested the Runtime to terminate it in an unusual > way. > }}} New description: When running the "server" and "client" progams shown below, the client aborts, on Windows (10), with the following error: {{{#!text {loc=,type=duplex (read-write),buffering=none} fdReady: fd is too big This application has requested the Runtime to terminate it in an unusual way. }}} Here is the code for the client: {{{#!hs import Network import Control.Concurrent import System.IO main = readWithinNSecs readWithinNSecs :: IO () readWithinNSecs = withSocketsDo $ do h <- connectTo "localhost" (PortNumber 9090) hSetBuffering h NoBuffering readerTid <- forkIO $ politeReader h threadDelay (2 * 10^6) killThread readerTid where politeReader h = do info <- hShow h putStrLn info gotSth <- hWaitForInput h (10^6) if gotSth then do line <- hGetLine h putStrLn $ "Got " ++ line else return () }}} And here the code for the server: {{{#!hs module Main where import Network.Socket import Control.Concurrent main :: IO () main = do sock <- socket AF_INET Stream 0 -- create socket setSocketOption sock ReuseAddr 1 -- make socket immediately reusable - eases debugging. bind sock (SockAddrInet 9090 iNADDR_ANY) -- listen on TCP port 4242. listen sock 2 -- set a max of 2 queued connections mainLoop sock mainLoop :: Socket -> IO () mainLoop sock = do conn <- accept sock -- accept a connection and handle it runConn conn -- run our server's logic mainLoop sock -- repeat runConn :: (Socket, SockAddr) -> IO () runConn (sock, _) = do threadDelay (2 * 10^6) send sock "Hello!\n" close sock }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 10:47:17 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 10:47:17 -0000 Subject: [GHC] #14530: hWaitForInput causes the program to abort on Windows In-Reply-To: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> References: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> Message-ID: <062.8572326fab03e3d9b11e6cf0e861a2fd@haskell.org> #14530: hWaitForInput causes the program to abort on Windows -----------------------------------+-------------------------------------- Reporter: dnadales | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by dnadales): I added a complete repro, as requested. Notice that this also fails in the latest GHC version (8.2.2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 13:54:36 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 13:54:36 -0000 Subject: [GHC] #14615: Segfault when printing a simple string In-Reply-To: <051.9e7ed3f4287aabd28eba38bc726d4321@haskell.org> References: <051.9e7ed3f4287aabd28eba38bc726d4321@haskell.org> Message-ID: <066.53fbe58d2500c69ed9995aec0fdc0ef3@haskell.org> #14615: Segfault when printing a simple string -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: worksforme | Keywords: Christmas Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * status: infoneeded => closed * resolution: => worksforme Comment: I ran the program again and the output seems indicative of a joke -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 15:43:29 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 15:43:29 -0000 Subject: [GHC] #14618: Higher rank typechecking is broken In-Reply-To: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> References: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> Message-ID: <059.ec4e5d52e8e4165fdc931cf53cbee403@haskell.org> #14618: Higher rank typechecking is broken -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T14618 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I think so. To be honest, I wasn't sure how to set the Milestone tag to make sure it gets into both 8.2.3 and 8.4.1. But Safe Haskell isn't safe anyway: see #9562. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 16:15:55 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 16:15:55 -0000 Subject: [GHC] #14496: Invoking GHC 8.2.1 executable anywhere results in access violation on Windows 10 In-Reply-To: <050.8ec2c012a4031c145e18d1e0d7cbdd1d@haskell.org> References: <050.8ec2c012a4031c145e18d1e0d7cbdd1d@haskell.org> Message-ID: <065.3e1cadc5293185b846d5a72ae81ac523@haskell.org> #14496: Invoking GHC 8.2.1 executable anywhere results in access violation on Windows 10 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's also worth noting that this does not happen on GHC 8.2.2 or HEAD builds. So only 8.2.1 seems to suffer from this issue! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 19:53:51 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 19:53:51 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.e4a1cf009fbacddd78965b405388bc70@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I am curious as to why it's failing on earlier GHC versions. Here's a slightly modified version of the program that also prints different output depending on the optimization level: {{{#!hs module Main (main) where import Debug.Trace type V3 = (Double, Double, Double) infixl 6 <-> infixl 7 <.> (<->) :: V3 -> V3 -> V3 (<->) (x, y, z) (x', y', z') = (x-x', y-y', z-z') (<.>) :: V3 -> V3 -> Double (<.>) (x, y, z) (x', y', z') = x*x'+y*y'+z*z' sphereIntersection :: V3 -> V3 -> V3 sphereIntersection orig dir | t1 > 0 = traceShow ("orig", orig) $ traceShow ("dir", dir) $ -- traceShow ("oc", oc) $ traceShow ("b", b) $ traceShow ("disc", disc) $ traceShow ("sqrtDisc", sqrtDisc) $ traceShow ("t1", t1) $ dir where oc = (0, 0, 200) <-> orig b = oc <.> dir disc = 50000 - oc <.> oc sqrtDisc = sqrt disc t1 = b - sqrtDisc {-# NOINLINE sphereIntersection #-} main :: IO () main = print $ sphereIntersection (0, 0, 0) (0, 0, 1) }}} {{{ $ ghc -O0 Foo.hs -fforce-recomp [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Linking Foo.exe ... $ ./Foo.exe ("orig",(0.0,0.0,0.0)) ("dir",(0.0,0.0,1.0)) ("b",200.0) ("disc",10000.0) ("sqrtDisc",100.0) ("t1",100.0) (0.0,0.0,1.0) $ ghc -O1 Foo.hs -fforce-recomp [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Linking Foo.exe ... $ ./Foo.exe ("orig",(0.0,0.0,0.0)) ("dir",(0.0,0.0,0.0)) ("b",200.0) ("disc",10000.0) ("sqrtDisc",100.0) ("t1",100.0) (0.0,0.0,0.0) }}} Notice that in the optimized version, GHC thinks the `dir` argument is `(0.0,0.0,0.0)`, when it should be `(0.0,0.0,1.0)`! To make things stranger, if you uncomment the `traceShow ("oc", oc) $` line, then the optimized program's answer is different (but still wrong): {{{ $ ghc -O1 Foo.hs -fforce-recomp [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Linking Foo.exe ... $ ./Foo.exe ("orig",(0.0,0.0,0.0)) ("dir",(0.0,0.0,40000.0)) ("oc",(0.0,0.0,200.0)) ("b",200.0) ("disc",10000.0) ("sqrtDisc",100.0) ("t1",100.0) (0.0,0.0,40000.0) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 20:14:10 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 20:14:10 -0000 Subject: [GHC] #8033: add AVX register support to llvm calling convention In-Reply-To: <045.7dc8866bbad0b343f7d0cca58aa9a9b3@haskell.org> References: <045.7dc8866bbad0b343f7d0cca58aa9a9b3@haskell.org> Message-ID: <060.e32737108ef18d34995cc16e5ed310ca@haskell.org> #8033: add AVX register support to llvm calling convention -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.4.1 Comment: Indeed they were in 15f788f5e5096641245a4f060600a6db9cbc2c4e. A note about this was added to the release notes in c1bc923b08860101d0b74795ff42f6022c7fec0b. Thanks for noticing this, George! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 22:35:59 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 22:35:59 -0000 Subject: [GHC] #14388: GHC Panic In-Reply-To: <048.ff04d4b22c4f4e0aec9c19da64e2231b@haskell.org> References: <048.ff04d4b22c4f4e0aec9c19da64e2231b@haskell.org> Message-ID: <063.f7932d8b1b33036fe1fc2fbd9019272e@haskell.org> #14388: GHC Panic -------------------------------------+------------------------------------- Reporter: aferrandi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: IfaceTyLit | panic Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 22:59:08 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 22:59:08 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.de3569f3ee1b47ebcd6d41fbb6566f7e@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) * priority: normal => high * milestone: => 8.6.1 Comment: Raising priority. Not raising it to highest for now because it looks like it could be some fragile floating-point business. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 23:09:48 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 23:09:48 -0000 Subject: [GHC] #14388: GHC Panic In-Reply-To: <048.ff04d4b22c4f4e0aec9c19da64e2231b@haskell.org> References: <048.ff04d4b22c4f4e0aec9c19da64e2231b@haskell.org> Message-ID: <063.14cc579e7840a34898e0e638f8f8ddab@haskell.org> #14388: GHC Panic -------------------------------------+------------------------------------- Reporter: aferrandi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * keywords: IfaceTyLit panic => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 23:10:19 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 23:10:19 -0000 Subject: [GHC] #14388: GHC Panic In-Reply-To: <048.ff04d4b22c4f4e0aec9c19da64e2231b@haskell.org> References: <048.ff04d4b22c4f4e0aec9c19da64e2231b@haskell.org> Message-ID: <063.9268e2d5836b5c1baaf7dfa38d6a60a8@haskell.org> #14388: GHC Panic -------------------------------------+------------------------------------- Reporter: aferrandi | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.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 dfeuer): * os: Linux => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 23:21:44 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 23:21:44 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.8159e6641308c0cf2ec3c217c7bb01c6@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 27 23:47:43 2017 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Dec 2017 23:47:43 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.7fe23fdba0c963f01c5e715adb7859fc@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It seems to have been lost above but -fno-worker-wrapper fixes the issue. This seems to point to the implementation of unboxed tuples or Double# being the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 00:23:00 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 00:23:00 -0000 Subject: [GHC] #13002: :set -O does not work in .ghci file In-Reply-To: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> References: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> Message-ID: <060.943d824369f313bcb0a6a6b1bdd391db@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.3 Component: GHCi | Version: 8.0.1 Resolution: worksforme | Keywords: | RecompilationCheck 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): * status: new => closed * resolution: => worksforme * milestone: 8.4.1 => 8.0.3 Comment: I'm not at all convinced that this bug is valid at all. I suspect the timing difference you saw was some sort of insignificant artifact; perhaps the extra command line options are affecting GC timings. I tested with a version that includes an utterly bogus `RULES` pragma: {{{#!hs {-# OPTIONS_GHC -Wall #-} module T13002 where testFromTo :: Int -> Int testFromTo n = length ([0..(10^n)] :: [Int]) {-# NOINLINE testFromTo #-} test :: Int -> Int test x = testFromTo x {-# RULES "bogus" forall x. testFromTo x = 12 #-} }}} This produces semantically different `test` functions depending on whether optimizations are enabled or not, and the change occurs as expected when I add `-O` to the `.ghci` file. It works for me under 8.0, 8.2, and HEAD. So I'm going to close this for now; if you disagree, I suggest you add a more robust test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 00:29:41 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 00:29:41 -0000 Subject: [GHC] #13002: :set -O does not work in .ghci file In-Reply-To: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> References: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> Message-ID: <060.08078ddcd670c4c6284a7291c97a87c0@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.3 Component: GHCi | Version: 8.0.1 Resolution: worksforme | Keywords: | RecompilationCheck 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): That is, GHC's processing of its own command line could affect GC timings in some tiny way that is enough to lead to the difference you experienced. Just to make really sure, I turned on `-ddump-simpl` and saw that the core produced when loading the test file had all the signs of having been optimized (e.g., strictness annotations, unfoldings, and worker/wrapper pairs). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 00:30:07 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 00:30:07 -0000 Subject: [GHC] #13002: :set -O does not work in .ghci file In-Reply-To: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> References: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> Message-ID: <060.67c0e75122c9a6254a6a8f7fac90163a@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.3 Component: GHCi | Version: 8.0.1 Resolution: worksforme | Keywords: | RecompilationCheck 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: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 10:31:23 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 10:31:23 -0000 Subject: [GHC] #14621: GHC 8.2 GCed too early Message-ID: <052.2adf9e24fc3980219ad915eaf6b9afc5@haskell.org> #14621: GHC 8.2 GCed too early -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The network package uses mkWeakVar so that unreachable Sockets can be GCed. See the master branch of https://github.com/haskell/network {{{ mkSocket :: CInt -> Family -> SocketType -> ProtocolNumber -> SocketStatus -> IO Socket mkSocket fd fam sType pNum stat = do mStat <- newMVar stat withSocketsDo $ return () let sock = Socket fd fam sType pNum mStat ##if MIN_VERSION_base(4,6,0) _ <- mkWeakMVar mStat $ close sock ##endif return sock }}} The following code cause "threadWait: invalid argument (Bad file descriptor)" in accept: {{{ module Main where import Control.Concurrent (forkIO) import Control.Monad (void, forever) import Network.Socket hiding (recv) import Network.Socket.ByteString (recv, sendAll) main :: IO () main = do let localhost = "localhost" listenPort = "9876" connectPort = "6789" proxy localhost listenPort connectPort proxy :: HostName -> ServiceName -> ServiceName -> IO () proxy localhost listenPort connectPort = do fromClient <- serverSocket localhost listenPort toServer <- clientSocket localhost connectPort void $ forkIO $ relay toServer fromClient relay fromClient toServer relay :: Socket -> Socket -> IO () relay s1 s2 = forever $ do payload <- recv s1 4096 sendAll s2 payload serverSocket :: HostName -> ServiceName -> IO Socket serverSocket host port = do let hints = defaultHints { addrFlags = [AI_PASSIVE] , addrSocketType = Stream } addr:_ <- getAddrInfo (Just hints) (Just host) (Just port) sock <- socket (addrFamily addr) (addrSocketType addr) (addrProtocol addr) bind sock (addrAddress addr) listen sock 1 fst <$> accept sock clientSocket :: HostName -> ServiceName -> IO Socket clientSocket host port = do let hints = defaultHints { addrSocketType = Stream } addr:_ <- getAddrInfo (Just hints) (Just host) (Just port) sock <- socket (addrFamily addr) (addrSocketType addr) (addrProtocol addr) connect sock (addrAddress addr) return sock }}} GC frees sock while accepting. This occurs with GHC 8.2 or higher. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 16:59:55 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 16:59:55 -0000 Subject: [GHC] #14622: Add `joinState# :: State# s -> State# s -> State# s` primop Message-ID: <046.2f08750a18eac25f0ddcb36c8052535d@haskell.org> #14622: Add `joinState# :: State# s -> State# s -> State# s` primop -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The state threading in GHC.Prim requires the user to impose a total order on memory reads and writes within a state thread. In some cases, this total order constrains the compiler more than necessary. For example, if the programmer knows that `addr1` and `addr2` don't alias, then they might like to express that the two writes in the following can be reordered relative to each other: {{{#!hs doTwoWrites :: Addr# -> Addr# -> State# s -> State# s doTwoWrites addr1 addr2 s = writeWord8OffAddr# addr2 0# 123## ( writeWord8OffAddr# addr1 0# 234## s) }}} If we had the following primop, then we could express that flexibility in reordering: {{{#!hs -- | Produces a state that has a data dependency on the two input -- states. Generates no machine code. joinState# :: State# s -> State# s -> State# s }}} That is, we'd write the above function as: {{{#!hs doTwoWrites :: Addr# -> Addr# -> State# s -> State# s doTwoWrites addr1 addr2 s = joinState# (writeWord8OffAddr# addr2 0# 123## s) (writeWord8OffAddr# addr1 0# 234## s) }}} This would give us fine-grained fork/join of `State#` threads, with fork provided by copying of `State# s` objects and join provided by `joinState#`. This lets the programmer express arbitrary DAGs of dependencies between memory operations, rather than just linear chains of dependencies. Low priority; I don't have a specific use case with a missed optimization. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 17:53:01 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 17:53:01 -0000 Subject: [GHC] #14621: GHC 8.2 GCed too early In-Reply-To: <052.2adf9e24fc3980219ad915eaf6b9afc5@haskell.org> References: <052.2adf9e24fc3980219ad915eaf6b9afc5@haskell.org> Message-ID: <067.ded5a473175cf45dfe52198f43653c76@haskell.org> #14621: GHC 8.2 GCed too early -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => upstream Old description: > The network package uses mkWeakVar so that unreachable Sockets can be > GCed. See the master branch of https://github.com/haskell/network > > {{{ > mkSocket :: CInt > -> Family > -> SocketType > -> ProtocolNumber > -> SocketStatus > -> IO Socket > mkSocket fd fam sType pNum stat = do > mStat <- newMVar stat > withSocketsDo $ return () > let sock = Socket fd fam sType pNum mStat > ##if MIN_VERSION_base(4,6,0) > _ <- mkWeakMVar mStat $ close sock > ##endif > return sock > }}} > > The following code cause "threadWait: invalid argument (Bad file > descriptor)" in accept: > > {{{ > module Main where > > import Control.Concurrent (forkIO) > import Control.Monad (void, forever) > import Network.Socket hiding (recv) > import Network.Socket.ByteString (recv, sendAll) > > main :: IO () > main = do > let localhost = "localhost" > listenPort = "9876" > connectPort = "6789" > proxy localhost listenPort connectPort > > proxy :: HostName -> ServiceName -> ServiceName -> IO () > proxy localhost listenPort connectPort = do > fromClient <- serverSocket localhost listenPort > toServer <- clientSocket localhost connectPort > void $ forkIO $ relay toServer fromClient > relay fromClient toServer > > relay :: Socket -> Socket -> IO () > relay s1 s2 = forever $ do > payload <- recv s1 4096 > sendAll s2 payload > > serverSocket :: HostName -> ServiceName -> IO Socket > serverSocket host port = do > let hints = defaultHints { > addrFlags = [AI_PASSIVE] > , addrSocketType = Stream > } > addr:_ <- getAddrInfo (Just hints) (Just host) (Just port) > sock <- socket (addrFamily addr) (addrSocketType addr) (addrProtocol > addr) > bind sock (addrAddress addr) > listen sock 1 > fst <$> accept sock > > clientSocket :: HostName -> ServiceName -> IO Socket > clientSocket host port = do > let hints = defaultHints { addrSocketType = Stream } > addr:_ <- getAddrInfo (Just hints) (Just host) (Just port) > sock <- socket (addrFamily addr) (addrSocketType addr) (addrProtocol > addr) > connect sock (addrAddress addr) > return sock > }}} > > GC frees sock while accepting. This occurs with GHC 8.2 or higher. New description: The network package uses mkWeakVar so that unreachable Sockets can be GCed. See the master branch of https://github.com/haskell/network {{{#!hs mkSocket :: CInt -> Family -> SocketType -> ProtocolNumber -> SocketStatus -> IO Socket mkSocket fd fam sType pNum stat = do mStat <- newMVar stat withSocketsDo $ return () let sock = Socket fd fam sType pNum mStat ##if MIN_VERSION_base(4,6,0) _ <- mkWeakMVar mStat $ close sock ##endif return sock }}} The following code cause "threadWait: invalid argument (Bad file descriptor)" in accept: {{{#!hs module Main where import Control.Concurrent (forkIO) import Control.Monad (void, forever) import Network.Socket hiding (recv) import Network.Socket.ByteString (recv, sendAll) main :: IO () main = do let localhost = "localhost" listenPort = "9876" connectPort = "6789" proxy localhost listenPort connectPort proxy :: HostName -> ServiceName -> ServiceName -> IO () proxy localhost listenPort connectPort = do fromClient <- serverSocket localhost listenPort toServer <- clientSocket localhost connectPort void $ forkIO $ relay toServer fromClient relay fromClient toServer relay :: Socket -> Socket -> IO () relay s1 s2 = forever $ do payload <- recv s1 4096 sendAll s2 payload serverSocket :: HostName -> ServiceName -> IO Socket serverSocket host port = do let hints = defaultHints { addrFlags = [AI_PASSIVE] , addrSocketType = Stream } addr:_ <- getAddrInfo (Just hints) (Just host) (Just port) sock <- socket (addrFamily addr) (addrSocketType addr) (addrProtocol addr) bind sock (addrAddress addr) listen sock 1 fst <$> accept sock clientSocket :: HostName -> ServiceName -> IO Socket clientSocket host port = do let hints = defaultHints { addrSocketType = Stream } addr:_ <- getAddrInfo (Just hints) (Just host) (Just port) sock <- socket (addrFamily addr) (addrSocketType addr) (addrProtocol addr) connect sock (addrAddress addr) return sock }}} GC frees sock while accepting. This occurs with GHC 8.2 or higher. -- Comment: This actually appears to be a bug in the `network` library which has been exposed by more aggressive optimization by GHC. Specifically, `accept` doesn't ensure that the `Socket`'s `status` field is kept alive while the `accept` system call is underway. Consequently the GC correctly concludes that it can be collected. I have opened [[https://github.com/haskell/network/issues/287|network #287]] to track this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 18:08:03 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 18:08:03 -0000 Subject: [GHC] #10731: System.IO.openTempFile is not thread safe on Windows In-Reply-To: <051.f6b2ae5c769c1cac9a336c0052f78eb7@haskell.org> References: <051.f6b2ae5c769c1cac9a336c0052f78eb7@haskell.org> Message-ID: <066.617df44c89f4862ab22f3e3810e5c0fc@haskell.org> #10731: System.IO.openTempFile is not thread safe on Windows -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4278 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D4278 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 18:59:10 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 18:59:10 -0000 Subject: [GHC] #14618: Higher rank typechecking is broken In-Reply-To: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> References: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> Message-ID: <059.b283e626d3bec9962fdfd369fcb21d2e@haskell.org> #14618: Higher rank typechecking is broken -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T14618 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.2.3 Comment: Merged to ghc-8.4 with 1779e3bf4876d8ac46657275e5f0f2ee6877a5c9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 19:02:39 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 19:02:39 -0000 Subject: [GHC] #14618: Higher rank typechecking is broken In-Reply-To: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> References: <044.8df733da1b261c7e7a895e116fd02062@haskell.org> Message-ID: <059.169a0d590b59bcd84262854d3409eac5@haskell.org> #14618: Higher rank typechecking is broken -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T14618 Blocked By: 14620 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * blockedby: => 14620 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 19:03:02 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 19:03:02 -0000 Subject: [GHC] #14610: newtype wrapping of a monadic stack kills performance In-Reply-To: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> References: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> Message-ID: <060.871723ae5e425278d1b262e7423e1db6@haskell.org> #14610: newtype wrapping of a monadic stack kills performance -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: 14620 | Blocking: Related Tickets: #14620 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * blockedby: => 14620 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 19:05:51 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 19:05:51 -0000 Subject: [GHC] #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE In-Reply-To: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> References: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> Message-ID: <064.8c9b55d0da2903afddb2704bb4846fec@haskell.org> #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: performance, | inline, bits Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Perhaps we should close this in that case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 19:35:06 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 19:35:06 -0000 Subject: [GHC] #14610: newtype wrapping of a monadic stack kills performance In-Reply-To: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> References: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> Message-ID: <060.4fbd9c00f7cb60ba897e683d9218ea0d@haskell.org> #14610: newtype wrapping of a monadic stack kills performance -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14620 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * blockedby: 14620 => Comment: bgamari, I don't think this is actually blocking on #14620. Why do you think it is? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 21:13:57 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 21:13:57 -0000 Subject: [GHC] #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE In-Reply-To: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> References: <049.42a90b3c14f1511ae118c95e3415d83f@haskell.org> Message-ID: <064.0072a99b5270b51338154ad0b2fa3644@haskell.org> #12022: unsafeShiftL and unsafeShiftR are not marked as INLINE -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: dfeuer Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: performance, | inline, bits 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): * owner: (none) => dfeuer Comment: I'll run `containers` benchmarks with and without the custom shifts and see if it matters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 22:07:56 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 22:07:56 -0000 Subject: [GHC] #13002: :set -O does not work in .ghci file In-Reply-To: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> References: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> Message-ID: <060.e501265cc1e571a3dfcfe18d3cd94709@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.0.3 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: | RecompilationCheck 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 George): * status: closed => new * resolution: worksforme => Comment: Thanks for taking the time to investigate, I should have been more explicit, the bug is not about the small timing difference; it is about the large allocation difference: 8,885,888 bytes vs 98,400 bytes. That is not insignficant right? think it is the difference between fusion occurring and not occurring. I agree that the ddump-simpl output seems to show that it is not a bug but the allocation difference indicates to me that it is not optimizing i.e.doing list fusion. I thought it worth double checking. If you are still not convinced feel free to close and I will try to come up with a more robust test case or convince myself that I am wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 22:58:32 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 22:58:32 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.a4827d86af7d0da9dcf28d25ba73004f@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): @nomeata, I have {{{#!hs data Boo = Tru | Fal quux True = Fal quux False = Tru {-# NOINLINE quux #-} }}} which compiles to STG {{{ quux_rCA :: GHC.Types.Bool -> Main.Boo [GblId, Arity=1, Caf=NoCafRefs, Str=, Unf=OtherCon []] = sat-only [] \r [ds_s48C] ds_s48C; }}} I may be mistaken, but does this preserve the original strictness? I looks like a regular lambda to me (non-strict). The optimization is implemented by `mkStgCase`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 23:08:49 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 23:08:49 -0000 Subject: [GHC] #14610: newtype wrapping of a monadic stack kills performance In-Reply-To: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> References: <045.5ed9746f86f3774a95fff79094d26517@haskell.org> Message-ID: <060.5df648df71d8d83f993361244c3691cc@haskell.org> #14610: newtype wrapping of a monadic stack kills performance -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14620 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, indeed you are right. It's an orthogonal concern. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 28 23:58:05 2017 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Dec 2017 23:58:05 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.b21967dc56445767ee8c94211e82416a@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: nomeata Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Yes, it preserves the strictness: `id = \x. x` is strict in `x` , since `id ⊥ = ⊥`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 29 06:54:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Dec 2017 06:54:54 -0000 Subject: [GHC] #14621: GHC 8.2 GCed too early In-Reply-To: <052.2adf9e24fc3980219ad915eaf6b9afc5@haskell.org> References: <052.2adf9e24fc3980219ad915eaf6b9afc5@haskell.org> Message-ID: <067.a02cb0777d37c0a5344dda1edea2b3c0@haskell.org> #14621: GHC 8.2 GCed too early -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kazu-yamamoto): Thanks. Let's close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 29 06:56:19 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Dec 2017 06:56:19 -0000 Subject: [GHC] #14621: GHC 8.2 GCed too early In-Reply-To: <052.2adf9e24fc3980219ad915eaf6b9afc5@haskell.org> References: <052.2adf9e24fc3980219ad915eaf6b9afc5@haskell.org> Message-ID: <067.22b2a64580036f08999d0603e31fbef6@haskell.org> #14621: GHC 8.2 GCed too early -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kazu-yamamoto): * status: upstream => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 29 08:29:35 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Dec 2017 08:29:35 -0000 Subject: [GHC] #8642: Allow GHCi to print non-pretty forms of things. In-Reply-To: <047.ccc9b115bdd88e90ed55051a25f1a4ce@haskell.org> References: <047.ccc9b115bdd88e90ed55051a25f1a4ce@haskell.org> Message-ID: <062.2d0356bbf9cf43edad3852b66878df6d@haskell.org> #8642: Allow GHCi to print non-pretty forms of things. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.9 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Fuuzetsu): * status: new => closed * resolution: => wontfix Comment: I don't really need this anymore and it was questionable in first place so I'm just closong as wontfix rather than lettin it sit around indefinitely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 29 19:26:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Dec 2017 19:26:50 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.6bd545ab6221539092c472b94b089679@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Which windows architecture is this on? What’s the abi afoot / registers involved ? Aka what’s the assembly for that module ? Does the answer change if the sphere calc is marked noinline? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 29 19:38:42 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Dec 2017 19:38:42 -0000 Subject: [GHC] #13032: Redundant forcing of Given dictionaries In-Reply-To: <046.811080f481e777da656f14add09b1cc8@haskell.org> References: <046.811080f481e777da656f14add09b1cc8@haskell.org> Message-ID: <061.1967e2120ac91a5788349c79ab4f66ef@haskell.org> #13032: Redundant forcing of Given dictionaries -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: mpickering (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 29 21:06:03 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Dec 2017 21:06:03 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.85b937edc47db4d18b5646b1b5920388@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): It's x64, I haven't had the time to look at this yet. Marking it inline does indeed fix it. I'll attach the two disassembly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 29 21:06:50 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Dec 2017 21:06:50 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.28e0361b0f2a9d4223a40ac9ce4628e9@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * Attachment "Bug.s" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 29 21:07:08 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Dec 2017 21:07:08 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.e7477b2cfbf17f227f8683e80dc3a2a8@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * Attachment "Bug-working.s" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 29 21:37:41 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Dec 2017 21:37:41 -0000 Subject: [GHC] #14623: Allow qAddDependentFile on directories Message-ID: <050.1d58a13989e0d245575ac398dad3e147@haskell.org> #14623: Allow qAddDependentFile on directories -------------------------------------+------------------------------------- Reporter: ryantrinkle | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.2.2 Haskell | 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, qAddDependentFile can only be applied to files; when applied to a directory, the following exception occurs: {{{ *** Exception: path/to/dir: openBinaryFile: inappropriate type (is a directory) }}} However, it can be useful to walk directory trees at compile time with TemplateHaskell, and it would be nice to ensure that rebuilds reflect changes to directory structure, even when files are not changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 29 22:25:54 2017 From: ghc-devs at haskell.org (GHC) Date: Fri, 29 Dec 2017 22:25:54 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.35e2f4550fbf66a8afbdf1edd1e73061@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Other flags that cause the issue to disappear: * `-fllvm` * `-fno-cmm-sink` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 02:14:06 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 02:14:06 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.208e8eafb0162766ea92d25318022313@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * priority: high => highest * milestone: 8.6.1 => 8.4.1 Comment: Slyfox on irc was suggesting this is some sort of bug in caller/callee save convention on the 64bit windows mingw path. That disabling the cmm sink pass or using llvm backend resolve this issue is evidence that some register allocation related error only on that platform. Since this is a tier 1 platform And this seems to be a case of silently incorrect programs on a tier 1 platform , I’m marking this as highest priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 02:16:01 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 02:16:01 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.b97597da8bdf0805da7245dce0ae7f2f@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): To further clarify: it’s not something about floating point per se, but a bug related to optimizations after register allocation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 02:22:19 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 02:22:19 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.d776e166f144a1327f8120fecbd00a41@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): That's fine, Carter. I didn't want a subtle platform-specific numerical stability issue to hold up the release; if it's more than that, I agree it's highest priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 02:35:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 02:35:25 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.14bacc85fdd0f4d46e43ed789ff1f873@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Agreed. :) It’s not a stability or rounding issue. ESP since disabling cmm sink pass makes the issue go away as per Ryan’s testing I’ll try to look more later this evening -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 09:34:56 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 09:34:56 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.9a2b311780f178e3ded2385ebf586eb8@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * Attachment "Bug-no.dump-cmm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 09:35:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 09:35:08 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.102aba4ab106a59d61246ca2b23e6bd0@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * Attachment "Bug-ok.dump-cmm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 09:45:35 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 09:45:35 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.16de0740e4a8d6254c2d04812e46cc68@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) Comment: I've attached two cmm files one that work and one that doesn't. My initial thought is register pressure, but the working version seems to have higher pressure. Looking at the working one, I see only two differences, 1) it uses 8 bytes more of stack space for each function call 2) it does a lot of redundant moves. {{{ movq 24(%rbx),%rbx movq %rbx,%rcx movq %rcx,-24(%rbp) }}} instead of simply {{{ movq 24(%rbx),%rax movq %rax,-24(%rbp) }}} but aside from these two I can't seem to find any real differences. There's also slightly different scheduling. Can scheduling be turned off in GHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 10:05:09 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 10:05:09 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.556954678a46eb2c484750fa21217586@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * Attachment "Bug-head-nog.dump-cmm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 10:05:22 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 10:05:22 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.443b69ac9112c3726d6f63f569cb42a9@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * Attachment "Bug-8.2.2-nog.dump-cmm" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 10:09:23 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 10:09:23 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.5f14da41e7aad0c6baf07b90c0d1ca25@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I'm starting to think this isn't a GHC bug. I've attached two dumps created with the current `HEAD` and `8.2.2`. Because the representation of `show` for `Float` seems to have changed I'm avoiding using it. My repro is {{{ module Main where import Prelude hiding((*>), (<*)) type V3 = (Double, Double, Double) infixl 6 <+> infixl 7 <.> infix 8 *> (<+>) :: V3 -> V3 -> V3 (<+>) (x, y, z) (x', y', z') = (x+x', y+y', z+z') (*>) :: Double -> V3 -> V3 (*>) a (x', y', z') = (a*x', a*y', a*z') (<.>) :: V3 -> V3 -> Double (<.>) (x, y, z) (x', y', z') = x*x'+y*y'+z*z' sphereIntersection :: V3 -> V3 -> V3 -> Maybe (V3, Double) sphereIntersection orig dir@(_, _, dirz) c | b < 0 = Nothing | t1 > 0 = Just (t1 *> dir, dirz) | t2 > 0 = Just (t2 *> orig, dirz) | otherwise = Nothing where oc = c <+> orig b = oc <.> dir sqrtDisc = sqrt b t1 = b - sqrtDisc t2 = b + sqrtDisc result = sphereIntersection (0, 0, 0) (0, 0, 1) (0, 0, 200) main :: IO (Maybe (V3, Double)) main = return result }}} Both are compiled with `-fforce-recomp -O2 -ddump-cmm -ddump-to-file` and there is no meaningful difference in code gen. only label names. The only remaining difference is in toolchain. 8.4.1 has an upgraded toolchain (and so head) vs 8.2.2. So this is looking like an upstream issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 10:38:08 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 10:38:08 -0000 Subject: [GHC] #14619: Output value of program changes upon compiling with -O optimizations In-Reply-To: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> References: <044.7bc7afdc77e978715c67bc6238b57042@haskell.org> Message-ID: <059.aa90eedb8c32db8e3b5f00e0c2264d96@haskell.org> #14619: Output value of program changes upon compiling with -O optimizations -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): However, using the newer toolchain with the same Haskell libraries as before (e.g. base, GHC-prim) etc generates the same wrong result. So It's unlikely to be a `mingw-w64` bug. Back to GHC it is.. but likely now should look at the code in base. I also swapped out GHC-prim from 8.2.2 with the one from head and that didn't work. So the difference must be in base? I'm grasping at straws here :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 12:06:47 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 12:06:47 -0000 Subject: [GHC] #14338: Simplifier fails with "Simplifier ticks exhausted" In-Reply-To: <049.819ef8e60a65cb9f3e29afb8f69166a7@haskell.org> References: <049.819ef8e60a65cb9f3e29afb8f69166a7@haskell.org> Message-ID: <064.a7c1349f8561b925179beefccf47c58a@haskell.org> #14338: Simplifier fails with "Simplifier ticks exhausted" -------------------------------------+------------------------------------- Reporter: dredozubov | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think this regression is caused by https://git.haskell.org/ghc.git/commitdiff/1722fa106e10e63160bb2322e2ccb830fd5b9ab3 I built a compiler which comments out the relevant two lines from that patch and the number of ticks for n=10 is around 1500 vs 75000 for an unpatched compiler. So, relevant tickets are #13032 and #11230 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 12:14:33 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 12:14:33 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.cb7ced72e1409edaef79db792230c6b4@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Reverting 1722fa106e10e63160bb2322e2ccb830fd5b9ab3 improves the situation somewhat but -DBIG is still quite a bit slower. Pre-revert 12s without -DBIG 1m12 with -DBIG Post-revert 8s without -DBIG 28s with -DBIG -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 12:22:32 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 12:22:32 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.ccf6b2fe391e3ff82a512b35dd084773@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Adding an extra field leads to {{{ 8714 UnfoldingDone 8201 $c<*>_a4Ng }}} So each extra field leads to double the number of `<*>`s being inlined and hence the exponential behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 12:24:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 12:24:25 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.a909a45627a4abbadecdf70b753d9a27@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Adding a `NOINLINE` to `<*>` for `FormResult` predictably fixes the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 14:16:52 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 14:16:52 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.a21eaf1b1c5191876cee6d2d301ce04a@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Looking at the n=2 case for simplicity. At one stage of the compilation we have some core which looks like {{{ ($c<*>_a4dL (case x01_a2dZ of { FormMissing -> FormMissing; FormFailure errs_a2dS -> FormFailure errs_a2dS; FormSuccess a_a2dU -> FormSuccess (\ dt_a2M6 -> case a_a2dU of dt_X2M8 { PS ipv_s5JI ipv_s5JJ ipv_s5JK ipv_s5JL -> case dt_a2M6 of dt_X2Ma { PS ipv_s5JO ipv_s5JP ipv_s5JQ ipv_s5JR -> HugeStruct dt_X2M8 dt_X2Ma } }) }) x02_a2e0 }}} Next thing we know, the expression has been commuted and the call to $c<*> has been pushed into the branches !? {{{ (case x01_a2dZ of { FormMissing -> $c<*>_a4dL FormMissing x02_a2e0; FormFailure errs_a2dS -> $c<*>_a4dL (FormFailure errs_a2dS) x02_a2e0; FormSuccess a_a2dU -> $c<*>_a4dL (FormSuccess (\ dt_a2M6 -> case a_a2dU of dt_X2M8 { PS ipv_s5JI ipv_s5JJ ipv_s5JK ipv_s5JL -> case dt_a2M6 of dt_X2Ma { PS ipv_s5JO ipv_s5JP ipv_s5JQ ipv_s5JR -> HugeStruct a_a2dU dt_a2M6 } })) x02_a2e0 }}} and then `$c<*>_a4dL` is inlined individually in each branch rather than once at the top level. I don't know where in the compiler performs this transformation, perhaps you know where it happens David? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 15:32:11 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 15:32:11 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.d77e6afa668baaeb632b8be72af327ba@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The reason why `-O2` is needed is because an extra pass of the simplifer is ran after the `-fliberate-case` pass. If you don't run this extra pass, there are lots of uninlined calls to `c<*>` left over. The core running with `-O` is here. Starting on about line 950 you can see all the nested calls to `<*>` which have been duplicated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 30 16:02:25 2017 From: ghc-devs at haskell.org (GHC) Date: Sat, 30 Dec 2017 16:02:25 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.13947f73868ca767efb1d394d8254385@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The code duplication alluded to in comment:12 is a result of the special case in `rebuildCall` for a strict argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 31 03:07:54 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Dec 2017 03:07:54 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.83da8c2caaa7671843b5671a5468fcde@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Hey, a question about `sched_yield()`: I just read the [http://man7.org/linux/man-pages/man2/sched_yield.2.html man page] for `sched_yield()` again. It says: > `sched_yield()` is intended for use with read-time scheduling policies (i.e., `SCHED_FIFO` or `SCHED_RR`). Use of `sched_yield()` with nondeterministic scheduling policies such as `SCHED_OTHER` is unspecified and very likely means your application design is broken. Does GHC set the `FIFO` or`RR` policy? If not, then according to that our "application design is broken". I also found some interesting info on http://www.informit.com/articles/article.aspx?p=101760&seqNum=5 (emphasis mine): > Linux provides the `sched_yield()` system call as a mechanism for a process to explicitly yield the processor to other waiting processes. It works by removing the process from the active array (where it currently is, because it is running) and inserting it into the expired array. This has the effect of not only preempting the process and putting it at the end of its priority list, but putting it on the expired list — **guaranteeing it will not run for a while**. Because real-time tasks never expire, they are a special case. Therefore, they are merely moved to the end of their priority list (and not inserted into the expired array). **In earlier versions of Linux, the semantics of the `sched_yield()` call were quite different; at best, the task was only moved to the end of their priority list**. The yielding was often not for a very long time. Nowadays, applications and even kernel code should be certain they truly want to give up the processor before calling `sched_yield()`. A similar article on LWN: https://lwn.net/Articles/31462/ > This call used to simply move the process to the end of the run queue; now it moves the process to the "expired" queue, effectively cancelling the rest of the process's time slice. So a process calling `sched_yield()` now must wait until all other runnable processes in the system have used up their time slices before it will get the processor again. The article goes on to explain that this resulted bad performance especially for > threaded applications [that] implement busy-wait loops with `sched_yield()` Might this be relevant here? Also, can someone explain me why GHC is using `sched_yield()` at all? If the purpose is to wait until other GC threads are done, wouldn't `futex()` be enough? Or is that what's explained in https://ghcmutterings.wordpress.com/2010/01/25/yielding-more-improvements- in-parallel-performance/ ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 31 16:44:59 2017 From: ghc-devs at haskell.org (GHC) Date: Sun, 31 Dec 2017 16:44:59 -0000 Subject: [GHC] #14603: GHC segfaults building store with profiling In-Reply-To: <046.7db770ba92a42deacd0ed35af7d6c965@haskell.org> References: <046.7db770ba92a42deacd0ed35af7d6c965@haskell.org> Message-ID: <061.ae22481c4341c8eae603321c729963a0@haskell.org> #14603: GHC segfaults building store with profiling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1-alpha1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Compile-time crash or panic -- Ticket URL: GHC The Glasgow Haskell Compiler