From ghc-devs at haskell.org Fri Feb 1 00:11:09 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 00:11:09 -0000 Subject: [GHC] #16259: Hadrian does not work with a cabal v2-installed "Happy" In-Reply-To: <049.ec13a85dcdc8dc8a560ef06cae684380@haskell.org> References: <049.ec13a85dcdc8dc8a560ef06cae684380@haskell.org> Message-ID: <064.965992e3fbf1fd19a2c389fdb1595f85@haskell.org> #16259: Hadrian does not work with a cabal v2-installed "Happy" -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: snowleopard, alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 00:11:24 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 00:11:24 -0000 Subject: [GHC] #16262: Hadrian: respect dynamicGhcPrograms In-Reply-To: <045.a205c1b586695ffcc676bcf3f8335360@haskell.org> References: <045.a205c1b586695ffcc676bcf3f8335360@haskell.org> Message-ID: <060.e4edec54672af8d264dc6384206810b0@haskell.org> #16262: Hadrian: respect dynamicGhcPrograms -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: hadrian Resolution: | dynamic ghc programs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: snowleopard, alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 00:23:29 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 00:23:29 -0000 Subject: [GHC] #16247: GHC 8.6 Core Lint regression (Kind application error) In-Reply-To: <050.86450994402b394920f8cc11311bffbb@haskell.org> References: <050.86450994402b394920f8cc11311bffbb@haskell.org> Message-ID: <065.fb79d594e0af1fba4bf2a715d93ac275@haskell.org> #16247: GHC 8.6 Core Lint regression (Kind application error) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.6.3 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: This regression was introduced in commit 2bbdd00c6d70bdc31ff78e2a42b26159c8717856 (`Orient TyVar/TyVar equalities with deepest on the left`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 01:50:42 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 01:50:42 -0000 Subject: [GHC] #13834: Error cascade with type applications In-Reply-To: <049.1249ca55bb94d4476098b14993c34065@haskell.org> References: <049.1249ca55bb94d4476098b14993c34065@haskell.org> Message-ID: <064.047837a0c182a4bd94f7263c18ffd22b@haskell.org> #13834: Error cascade with type applications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12794 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, but the regression has disappeared on GHC HEAD! {{{ $ ghc4/inplace/bin/ghc-stage2 -XTypeApplications -e "notInScope @Bool" :0:1: error: Variable not in scope: notInScope :0:1: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Bool’ • In the expression: notInScope @Bool In an equation for ‘it’: it = notInScope @Bool }}} So... false alarm? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 04:30:01 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 04:30:01 -0000 Subject: [GHC] #16261: [] interpreted as an overloaded list in rule LHS In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.c805e6d4e3f9613a58b6acd09e1ffef2@haskell.org> #16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:10 simonpj]: > > Yes, that's it. But the module doesn't even enable OverloadedLists. > > That is indeed odd. Digging into why would be v helpful. I don't know anything about the implementation of the `RULES` system. What determines which extensions are in play in `RULES`? Do you agree with my opinion that `OverloadedLists` should ''never'' be enabled in a rule LHS, regardless of which extensions are enabled in the module? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 07:12:37 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 07:12:37 -0000 Subject: [GHC] #16266: Allow definition of functions with absurd contexts Message-ID: <045.ce73adc48fe7afd3c48489be08ce60b1@haskell.org> #16266: Allow definition of functions with absurd contexts -------------------------------------+------------------------------------- Reporter: So8res | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} type family Head xxs where Head (x ': xs) = x type family Tail xxs where Tail (x ': xs) = xs class IsList xs where isList :: (xs ~ '[] => r) -> ((xs ~ (Head xs ': Tail xs), IsList (Tail xs)) => r) -> r instance IsList '[] where isList r _ = r instance IsList xs => IsList (x ': xs) where isList _ r = r nonEmptyListsAreNotEmpty :: (xs ~ '[], xs ~ (Head xs ': Tail xs)) => r nonEmptyListsAreNotEmpty = error "you convinced GHC that '[] ~ (_ ': _)!" sillyExample :: forall x xs. IsList (x ': xs) => () sillyExample = isList @(x ': xs) nonEmptyListsAreNotEmpty () }}} In this code, we define a class IsList which serves as a proof that something is a type-level list, via the function isList. When using this, we may occasionally get into a situation where the types guarantee that we're working with a non-empty list, but we're asked to handle the empty- list case anyway. Suppose we want to define a nice little "absurd" function that serves as a reminder to readers that this code branch is impossible, in a way that GHC can verify. This function is named "nonEmptyListsAreNonEmpty" above. Unfortunately, this code fails with {{{ Main.hs:25:34: error: • Couldn't match type ‘'[]’ with ‘Head '[] : Tail '[]’ arising from a use of ‘nonEmptyListsAreNotEmpty’ • In the second argument of ‘isList’, namely ‘nonEmptyListsAreNotEmpty’ In the expression: isList @(x : xs) nonEmptyListsAreNotEmpty () In an equation for ‘sillyExample’: sillyExample = isList @(x : xs) nonEmptyListsAreNotEmpty () | 25 | sillyExample = isList @(x ': xs) nonEmptyListsAreNotEmpty () | ^^^^^^^^^^^^^^^^^^^^^^^^ }}} And indeed, the fact that [] can't be matched against (_ : _) is in some sense the point. More generally, whenever I'm fooling around with this sort of Haskell code (in which classes are being used to provide runtime witnesses of type-level structure), I relatively regularly find myself in a branch of code where the context is obviously inconsistent, wishing that I had some way to say "search your heart, GHC; you know this case to be impossible". The fact that I can't even factor out this dead code into a function like nonEmptyListsAreNonEmpty just seems like insult added to injury. This is a minor concern, to be sure. Nevertheless, it seems to me that we should be able to write this function somehow, especially given that there are various ways to trick GHC into accepting something analogous (by clever use of GADTs such as :~:, perhaps). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 09:19:05 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 09:19:05 -0000 Subject: [GHC] #16263: GHC accepts illegal constraint in kind In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.bccbbaa441972acdc59391438a9e9518@haskell.org> #16263: GHC accepts illegal constraint in kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | 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 simonpj): Good spot! But there is code in GHC that specifically deals with equality constraints (only) in kinds: see * `Inst.tcInstTyBinder`. * `dc_theta_illegal_constraint` in `TcHsType.tcTyVar` (which deals with promoting data constructors) I talked with Richard about this last night. I think we agreed that we can systematically and consistently support equality constraints in types. If so, we should un-do the commit you reference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 09:27:44 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 09:27:44 -0000 Subject: [GHC] #13834: Error cascade with type applications In-Reply-To: <049.1249ca55bb94d4476098b14993c34065@haskell.org> References: <049.1249ca55bb94d4476098b14993c34065@haskell.org> Message-ID: <064.e20b4e4189c119df81ef5d27d428e773@haskell.org> #13834: Error cascade with type applications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12794 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well * I think it'd be better to suppress the "Cannot apply" error. That is what the origina ticket Description was asking for, and I think I can see how to do so. (Suppress the error in `TcExpr.tcArgs` if the `fun` is a `HsUnboundVar`.) * But a harder problem is that if you try with `-fdefer-type-errors` then we get {{{ bash$ ghc -c T13834.hs -fdefer-type-errors T13834.hs:5:7: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Bool’ • In the expression: notInScope @Bool In an equation for ‘foo’: foo = notInScope @Bool | 5 | foo = notInScope @Bool | ^^^^^^^^^^^^^^^^ }}} The out-of-scope thing has turned into a warning, with deferred evidence. And rightly so in a way: you can run a program with an out-of- scope variable, provided you don't evaluate it. But the "cannot apply" error is still an error: it can't be deferred. I have not thought deeply about this, but I can't see an easy fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 09:30:03 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 09:30:03 -0000 Subject: [GHC] #16261: [] interpreted as an overloaded list in rule LHS In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.a014c32407821d3d6ae2c09eff08d1da@haskell.org> #16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Do you agree with my opinion that OverloadedLists should never be enabled in a rule LHS, regardless of which extensions are enabled in the module? No: I think the same extensions should be in scope everywhere otherwise people will say "but I wrote `f []` and it didn't match a rule whose LHS was `f []`". However I do agree that it's bizarre that `OverloadedLists` seems to be enabled on the rule LHS but not in the rest of the module. Deeply strange. We just need to understand more about what is happening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 09:53:39 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 09:53:39 -0000 Subject: [GHC] #16261: [] interpreted as an overloaded list in rule LHS In-Reply-To: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> References: <045.f552aedee8e7265233e06bc64e9a95a2@haskell.org> Message-ID: <060.fa0733a39f58f6da5268cb9f421a1d31@haskell.org> #16261: [] interpreted as an overloaded list in rule LHS -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => invalid Comment: Oh, what a fool I am! In all the test compilations, I was (by relic of a previous thing) enabling overloaded lists myself! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 11:16:05 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 11:16:05 -0000 Subject: [GHC] #13834: Error cascade with type applications In-Reply-To: <049.1249ca55bb94d4476098b14993c34065@haskell.org> References: <049.1249ca55bb94d4476098b14993c34065@haskell.org> Message-ID: <064.4354872ee50489e429cb4d1b81f6c1e9@haskell.org> #13834: Error cascade with type applications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, TypeErrorMessages Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12794 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Sure, I didn't want to suggest that this ticket was fixed completely, only that the particular buglet that the `Variable not in scope` message disappearing (without `-fdefer-type-errors`) had been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 11:19:18 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 11:19:18 -0000 Subject: [GHC] #16263: GHC accepts illegal constraint in kind In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.ada211096edb597ef166649e268503af@haskell.org> #16263: GHC accepts illegal constraint in kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | 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 RyanGlScott): OK, and that's all well and good, but surely that ought to be the subject of a separate ticket? This one is just about GHC blindly accepting a (non- equality) constraint in a kind, which is something that we ought to just reject. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 13:20:57 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 13:20:57 -0000 Subject: [GHC] #16267: EXTRA_HC_OPTS workflow under hadrian. Message-ID: <047.f8e92d85bf6f649ce2f222e3ea228676@haskell.org> #16267: EXTRA_HC_OPTS workflow under hadrian. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This allows passing of arbitrary flags to ghc from the command line. The main use case for me so far is to generate dumps for an arbitrary combination of dump flags. Sometimes I wanted to look at the simplifier output for a certain file. Sometimes I wanted to dump the asm code for all files to see how common certain patterns are. Sometimes the same for Cmm. Sometimes I want to dump two passes to be able to cross reference between them. These are usually on-off things and the exact flags often differ. So imo custom build profiles are not a good solution for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 13:43:48 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 13:43:48 -0000 Subject: [GHC] #16152: Core lint error from PartialTypeSignatures In-Reply-To: <051.267e28704195fd373b6028bcf6ae94c9@haskell.org> References: <051.267e28704195fd373b6028bcf6ae94c9@haskell.org> Message-ID: <066.a1d0ac050e20c7150136a3785514bc4e@haskell.org> #16152: Core lint error from PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: | PartialTypeSignatures Operating System: 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): The program in comment:1 has some strange interactions w.r.t. `MonoLocalBinds`. This program compiles: {{{#!hs {-# Language PartialTypeSignatures #-} {-# Language PolyKinds #-} {-# Language ScopedTypeVariables #-} {-# Language TypeApplications #-} import GHC.Exts top :: forall f. _ top = undefined f = top @Any }}} But if you compile it with `MonoLocalBinds`, then it doesn't: {{{ $ /opt/ghc/8.6.3/bin/ghci Bug.hs -XMonoLocalBinds GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:11:10: error: • Expected kind ‘k’, but ‘Any’ has kind ‘k00’ • In the type ‘Any’ In the expression: top @Any In an equation for ‘f’: f = top @Any | 11 | f = top @Any | ^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 17:24:42 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 17:24:42 -0000 Subject: [GHC] #16268: Potential race condition in Hadrian? Message-ID: <049.4158cf1250b71ff9622c1ac6157ded0e@haskell.org> #16268: Potential race condition in Hadrian? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- It seems that sometimes CI jobs fail because of a race condition in Hadrian. https://gitlab.haskell.org/ghc/ghc/-/jobs/20254 Here, array finishes before `deepseq` starts to be built but the configure step for `deepseq` fails to find the library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 17:32:33 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 17:32:33 -0000 Subject: [GHC] #16269: Postfix operator precedence Message-ID: <045.86b73bdf13b4e3c727058e8cec5f9492@haskell.org> #16269: Postfix operator precedence -------------------------------------+------------------------------------- Reporter: anuyts | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Parser) | Keywords: fixity | Operating System: Unknown/Multiple PostfixOperators | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to define a postfix operator $- that feeds a default argument (obtained from a typeclass) to a given function. However, I would like to be able to write things like (f $ g $ h $-) for (f (g (h (defaultArg)))). This is not allowed, as $ has precedence 0 and $- is required to have lower precedence, which is impossible. I think it would be sensible if $- was required to have precedence at most infixr 0 (which is the precedence of $). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 17:35:48 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 17:35:48 -0000 Subject: [GHC] #16270: Report multiple errors during parsing Message-ID: <048.8241d0d6fb8bb59986f0e3aa22e6e182@haskell.org> #16270: Report multiple errors during parsing -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Parsing failures currently abort the parsing process (with `parseErrorSDoc`) even if it can continue and report multiple errors at once. This is easy to fix by creating a new combinator, `addError`, similar to `addWarning`, which would add the error message to the accumulator but continue parsing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 18:07:11 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 18:07:11 -0000 Subject: [GHC] #16271: Building stage1:lib:text target is not robust Message-ID: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> #16271: Building stage1:lib:text target is not robust -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems the dependency on `cabal_macros.h` is not properly specified in the logic to build the libraries. If I start a build, build a library and then remove the library dir, the target fails to build. {{{ ./hadrian/build.sh stage1:lib:text rm -r _build/stage1/ ./hadrian/build.sh stage1:lib:text }}} {{{ cc1: fatal error: integersimple/stage1/libraries/text/build/autogen/cabal_macros.h: No such file or directory compilation terminated. `cc' failed in phase `C pre-processor'. (Exit code: 1) shakeArgsWith 0.000s 0% Function shake 0.006s 0% Database read 0.831s 23% ======== With database 0.100s 2% Running rules 2.545s 73% ========================= Total 3.482s 100% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: stage1:lib:text at src/Rules/SimpleTargets.hs:31:5-15: * Depends on: integersimple/stage1/lib/package.conf.d/text-1.2.3.1.conf * Depends on: integersimple/stage1/libraries/text/build/libHStext-1.2.3.1.a * Depends on: integersimple/stage1/libraries/text/build/Data/Text/Show.o * Depends on: OracleQ (KeyValues ("integersimple/stage1/libraries/text/.dependencies","integersimple/stage1/libraries/text/build/Data/Text/Show.o")) * Depends on: integersimple/stage1/libraries/text/.dependencies * Depends on: integersimple/stage1/libraries/text/.dependencies.mk * Raised the exception: user error (Development.Shake.cmd, system command failed Command: integersimple/stage0/bin/ghc -M -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-db integersimple/stage1/lib/package.conf.d' '-this-unit-id text-1.2.3.1' '-package-id array-0.5.2.0' '-package-id base-4.12.0.0' '-package-id binary-0.8.6.0' '-package-id bytestring-0.10.9.0' '-package-id deepseq-1.4.4.0' '-package-id ghc-prim-0.5.3' '-package-id integer- simple-0.1.1.1' -i -iintegersimple/stage1/libraries/text/build -iintegersimple/stage1/libraries/text/build/autogen -ilibraries/text/. -Iincludes -Iintegersimple/generated -Iintegersimple/stage1/libraries/text/build -I/nix/store /f97ls1qx6vxf75304874843ysdcyimnn-ghc-build-environment/include -Iintegersimple/stage1/libraries/text/build/include -Ilibraries/text/include -I/root/ghc/integersimple/stage1/lib/x86_64 -linux-ghc-8.7.20190124/bytestring-0.10.9.0/include -I/root/ghc/integersimple/stage1/lib/x86_64-linux- ghc-8.7.20190124/base-4.12.0.0/include -I/root/ghc/integersimple/stage1/lib/x86_64-linux- ghc-8.7.20190124/rts-1.0/include -Iintegersimple/generated -optc- Iintegersimple/generated -optP-include -optPintegersimple/stage1/libraries/text/build/autogen/cabal_macros.h -optP-DINTEGER_SIMPLE -outputdir integersimple/stage1/libraries/text/build -include-pkg-deps -dep-makefile integersimple/stage1/libraries/text/.dependencies.mk -dep-suffix '' -dep- suffix dyn_ libraries/text/Data/Text.hs libraries/text/Data/Text/Array.hs libraries/text/Data/Text/Encoding.hs libraries/text/Data/Text/Encoding/Error.hs libraries/text/Data/Text/Foreign.hs libraries/text/Data/Text/IO.hs libraries/text/Data/Text/Internal.hs libraries/text/Data/Text/Internal/Builder.hs libraries/text/Data/Text/Internal/Builder/Functions.hs libraries/text/Data/Text/Internal/Builder/Int/Digits.hs libraries/text/Data/Text/Internal/Builder/RealFloat/Functions.hs libraries/text/Data/Text/Internal/Encoding/Fusion.hs libraries/text/Data/Text/Internal/Encoding/Fusion/Common.hs libraries/text/Data/Text/Internal/Encoding/Utf16.hs libraries/text/Data/Text/Internal/Encoding/Utf32.hs libraries/text/Data/Text/Internal/Encoding/Utf8.hs libraries/text/Data/Text/Internal/Functions.hs libraries/text/Data/Text/Internal/Fusion.hs libraries/text/Data/Text/Internal/Fusion/CaseMapping.hs libraries/text/Data/Text/Internal/Fusion/Common.hs libraries/text/Data/Text/Internal/Fusion/Size.hs libraries/text/Data/Text/Internal/Fusion/Types.hs libraries/text/Data/Text/Internal/IO.hs libraries/text/Data/Text/Internal/Lazy.hs libraries/text/Data/Text/Internal/Lazy/Encoding/Fusion.hs libraries/text/Data/Text/Internal/Lazy/Fusion.hs libraries/text/Data/Text/Internal/Lazy/Search.hs libraries/text/Data/Text/Internal/Private.hs libraries/text/Data/Text/Internal/Read.hs libraries/text/Data/Text/Internal/Search.hs libraries/text/Data/Text/Internal/Unsafe.hs libraries/text/Data/Text/Internal/Unsafe/Char.hs libraries/text/Data/Text/Internal/Unsafe/Shift.hs libraries/text/Data/Text/Lazy.hs libraries/text/Data/Text/Lazy/Builder.hs libraries/text/Data/Text/Lazy/Builder/Int.hs libraries/text/Data/Text/Lazy/Builder/RealFloat.hs libraries/text/Data/Text/Lazy/Encoding.hs libraries/text/Data/Text/Lazy/IO.hs libraries/text/Data/Text/Lazy/Internal.hs libraries/text/Data/Text/Lazy/Read.hs libraries/text/Data/Text/Read.hs libraries/text/Data/Text/Show.hs libraries/text/Data/Text/Unsafe.hs -O0 -H64m -Wall -fwarn-tabs -funbox-strict-fields -O2 -XHaskell98 -ghcversion- file=/root/ghc/integersimple/generated/ghcversion.h -O -Wno-deprecated- flags -Wno-unused-imports -Werror Exit code: 1 Stderr: cc1: fatal error: integersimple/stage1/libraries/text/build/autogen/cabal_macros.h: No such file or directory compilation terminated. `cc' failed in phase `C pre-processor'. (Exit code: 1) ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 18:11:29 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 18:11:29 -0000 Subject: [GHC] #16272: libffi copies files into rts build tree Message-ID: <049.e3bdaa5cd1e51cb6774df0e029e2b534@haskell.org> #16272: libffi copies files into rts build tree -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `rts` should explicitly depend on `ffi.h` and `ffitarget.h`, then use this path to copy in these two header files itself rather than relying on the libffi build rule to copy them into the `rts/build` directory. You can see this happening in `Rules.Libffi.libffiRules` This often results in a failure where the `rts` rule will fail to produce these files after deleting build products in `_build`. {{{ shakeArgsWith 0.000s 0% Function shake 0.006s 0% Database read 1.051s 0% Database compression 0.146s 0% With database 0.031s 0% Running rules 121.010s 98% ========================= Total 122.244s 100% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: stage1:lib:text at src/Rules/SimpleTargets.hs:31:5-15: * Depends on: integersimple/stage1/lib/package.conf.d/text-1.2.3.1.conf * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Library, pkgName = "text", pkgPath = "libraries/text"}, way = v})) * Depends on: integersimple/stage1/libraries/text/setup-config * Depends on: integersimple/stage1/lib/package.conf.d/base-4.12.0.0.conf * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Library, pkgName = "base", pkgPath = "libraries/base"}, way = v})) * Depends on: integersimple/stage1/libraries/base/setup-config * Depends on: integersimple/stage1/lib/package.conf.d/rts-1.0.conf * Depends on: integersimple/stage1/rts/build/libHSrts-1.0_thr_l.a * Depends on: integersimple/stage1/rts/build/c/Interpreter.thr_l_o * Depends on: integersimple/stage1/rts/build/ffi.h * Depends on: integersimple/stage1/rts/build/ffi.h integersimple/stage1/rts/build/ffitarget.h * Raised the exception: Error, &%> rule failed to produce 2 files (out of 2) integersimple/stage1/rts/build/ffi.h - MISSING integersimple/stage1/rts/build/ffitarget.h - MISSING CallStack (from HasCallStack): error, called at src/Development/Shake/Internal/Rules/Files.hs:245:13 in shake-0.17.2-586622e6ae1d899ec790b1028cae3413c00a616f124bac634769a9607581e631:Development.Shake.Internal.Rules.Files }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 18:37:47 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 18:37:47 -0000 Subject: [GHC] #16271: Building stage1:lib:text target is not robust In-Reply-To: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> References: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> Message-ID: <064.27cd47b1e116d488cc6a278adc66c895@haskell.org> #16271: Building stage1:lib:text target is not robust -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It works starting from scratch thankfully. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 18:55:03 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 18:55:03 -0000 Subject: [GHC] #16216: readHexRational missing from Numeric In-Reply-To: <045.c5090807f6ac2e49f2a7ca86acd5fa4d@haskell.org> References: <045.c5090807f6ac2e49f2a7ca86acd5fa4d@haskell.org> Message-ID: <060.45821dd3732947e1ffb04202df27a7d1@haskell.org> #16216: readHexRational missing from Numeric -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by toonn): I've started [https://gitlab.haskell.org/ghc/ghc/merge_requests/268/pipelines work on this here]. I've tried to copy `readFloat` as closely as possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 19:19:36 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 19:19:36 -0000 Subject: [GHC] #16273: Hadrian turns on `-Wno-unused-imports` for text when using integer-simple Message-ID: <049.1356995cc5ed8156810433d86ccdcea9@haskell.org> #16273: Hadrian turns on `-Wno-unused-imports` for text when using integer-simple -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `Settings.Warnings`, hadrian turns on `-Wno-unused-imports` for the `text` package when building with `integer-simple`. It would be good to fix `text` so we can remove this special case. 1. Build GHC with `integer-simple` and `-Werror` 2. Remove the special case for `text` in `Settings.Warnings`. 3. Fix the warnings in `text` appropriately so the build finishes. 4. Push the fix upstream and then update the submodule. This could also be debugged without having to build ghc by downloading an [https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/download?job =validate-x86_64-linux-deb9-integer-simple integer-simple bindist]. Also see: https://github.com/haskell/text/issues/250 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 20:45:35 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 20:45:35 -0000 Subject: [GHC] #16274: Remove ghctags Message-ID: <051.60fcdc3e4ceedcac5234a746e3c693c6@haskell.org> #16274: Remove ghctags -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.6.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This was suggested by Ben in the ghc-devs list. Does anyone desire to preserve it? As a newcomer, I think the existence of dead tools adds confusion. I didn't know what to peek at some point (try make etags work / hasktags / ghctags). I tentatively mark this as a newcomer task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 21:43:47 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 21:43:47 -0000 Subject: [GHC] #16275: type hole in hs-boot file triggers GHC internal error Message-ID: <049.78608be60f6350c2200471d3e1d83ee5@haskell.org> #16275: type hole in hs-boot file triggers GHC internal error -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Put each line in a separate file, the last one is B.hs-boot {{{ module A where { import {-# SOURCE #-} B } module B where { } module B where { data T a ; foo :: T _ } }}} then {{{ $ ghci A.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 3] Compiling B[boot] ( B.hs-boot, interpreted ) B.hs-boot:1:38: error: • GHC internal error: ‘_’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] • In the first argument of ‘T’, namely ‘_’ In the type signature: foo :: T _ | 1 | module B where { data T a ; foo :: T _ } | ^ }}} I know the program is invalid (the hole has no valid instance) but still it should not produce an internal error? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 21:59:44 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 21:59:44 -0000 Subject: [GHC] #16240: Core visible conditional compilation/static definition/code selection based upon static key values In-Reply-To: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> References: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> Message-ID: <060.129cfd5dc8dbaf1ddb7153ed8cc86eab@haskell.org> #16240: Core visible conditional compilation/static definition/code selection based upon static key values -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 22:13:59 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 22:13:59 -0000 Subject: [GHC] #16240: Core visible conditional compilation/static definition/code selection based upon static key values In-Reply-To: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> References: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> Message-ID: <060.4aa1171bc12050813eb7fe99296f2aa0@haskell.org> #16240: Core visible conditional compilation/static definition/code selection based upon static key values -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): I think we should consider separately the operation of conditionals to enable/disable/switch out blocks of code, and the use of other (CPP) primitives such as `#define` as a shortcut for configuring code. I regard the former as "low-power" and potentially able to be manageable integrated into tooling, if we assume that the inactive block must meet some minimal syntactic requirements, but not necessarily be able to be fully parsed or type checked. The latter should be discouraged, and if needed fall back to CPP as we have now, with the understanding that certain classed of tooling are then not possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 22:21:06 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 22:21:06 -0000 Subject: [GHC] #16240: Core visible conditional compilation/static definition/code selection based upon static key values In-Reply-To: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> References: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> Message-ID: <060.39292287a1a4474b941b13c7feb7827f@haskell.org> #16240: Core visible conditional compilation/static definition/code selection based upon static key values -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): after speaking with alanz on IRC a smidge, he's meaning "CPP as a support tool for portable code across platforms/configurations ghc versions", vs #define'd names/procedures as a poor mans macrosystem that lighter weight than TH and simpler to use/write this ticket is about the former, though its definitely true we would benefit from thinking about a decent macro systemy thing for syntactic abstraction -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 22:24:27 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 22:24:27 -0000 Subject: [GHC] #16276: Feature request: Polymorphic kinds in Data.Functor.Classes Message-ID: <051.87ec3e4fabc2b4701a886514ad6d119b@haskell.org> #16276: Feature request: Polymorphic kinds in Data.Functor.Classes -------------------------------------+------------------------------------- Reporter: siddharthist | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: polykinds | 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 classes in Data.Functor.Classes have a somewhat restrictive kind signature: {{{ *Data.Functor.Classes> :k Eq1 Eq1 :: (* -> *) -> Constraint }}} As a result, we redefine [1] many of them in the [https://hackage.haskell.org/package/parameterized-utils-1.0.1/docs/Data- Parameterized-Classes.html parameterized-utils] library. It would be quite easy to make more polymorphic (have kind "(k -> *) -> Constraint"). If everyone thinks this is a good idea, I'm happy to submit a pull request. [1]: To be precise, there are actually a few axes along which the classes in parameterized-utils vary from those in base. Some, like OrdF, require more type-level evidence. Others, like EqF, don't require their type parameter to have the corresponding instance. There are a lot of points in the design space here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 22:33:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 22:33:41 -0000 Subject: [GHC] #16240: Core visible conditional compilation/static definition/code selection based upon static key values In-Reply-To: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> References: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> Message-ID: <060.146713fa050b3d14679934598ce71a8b@haskell.org> #16240: Core visible conditional compilation/static definition/code selection based upon static key values -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): part of the intent / context is to make it easier for a single GHC compiler better able to check/(?compile) multiple platform targets -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 22:44:13 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 22:44:13 -0000 Subject: [GHC] #15514: Older Trac ticket links redirect to this site, but not to the specific ticket In-Reply-To: <047.28955a11ad343c28afe5b086a77914a5@haskell.org> References: <047.28955a11ad343c28afe5b086a77914a5@haskell.org> Message-ID: <062.ce65de5730a9ac1a2bd664fae514f40c@haskell.org> #15514: Older Trac ticket links redirect to this site, but not to the specific ticket -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gbaz): Sorry. By "soon" I guess I meant 6 months. Should be fixed now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 22:44:35 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 22:44:35 -0000 Subject: [GHC] #15514: Older Trac ticket links redirect to this site, but not to the specific ticket In-Reply-To: <047.28955a11ad343c28afe5b086a77914a5@haskell.org> References: <047.28955a11ad343c28afe5b086a77914a5@haskell.org> Message-ID: <062.0febafadedf519bc11a7aed7cf3ffba7@haskell.org> #15514: Older Trac ticket links redirect to this site, but not to the specific ticket -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: hvr Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gbaz): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 22:45:43 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 22:45:43 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly In-Reply-To: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> References: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> Message-ID: <059.4d3ade9294ca6388dc15bc247d497132@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: hsc2hs | Version: 7.10.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: hsc2hs/T11004 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/173 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => hsc2hs/T11004 * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/173 * resolution: => fixed * milestone: => 8.8.1 Comment: A test was added (and the `hsc2hs` submodule bumped) in [https://gitlab.haskell.org/ghc/ghc/commit/79a5afb613235e93bc2c580987595b9c1324db15 79a5afb613235e93bc2c580987595b9c1324db15]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 1 23:59:12 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Feb 2019 23:59:12 -0000 Subject: [GHC] #16077: AvailTC Invariant being violated In-Reply-To: <050.e27325be4d9bf8b20310c66c423e8dec@haskell.org> References: <050.e27325be4d9bf8b20310c66c423e8dec@haskell.org> Message-ID: <065.9a4627e55f8dde5fe7cce103053aa988@haskell.org> #16077: AvailTC Invariant being violated -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): I've begun to investigate this and none of this actually requires `cabal`. Using `A.hs` and `B.hs` from the bug summary, just run {{{ $ ghc -fforce-recomp -ddump-rn-trace A.hs B.hs | grep rnExports rnExports: Exports: [error, C{C, T;}, T{T, TI;}] rnExports: Exports: [C{C, T;}, T{TI;}] }}} The asymmetry is pretty clear. Also, this is reproducible on HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 00:15:24 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 00:15:24 -0000 Subject: [GHC] #16255: Visible kind application defeats type family with higher-rank result kind In-Reply-To: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> References: <050.e1b2cb59efffd21e6439cc86529c2494@haskell.org> Message-ID: <065.a4641fe0ea5377046b6bb881285ec686@haskell.org> #16255: Visible kind application defeats type family with higher-rank result kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Keywords: Resolution: | TypeApplications, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T16255 Blocked By: | Blocking: Related Tickets: #15740 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/260 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => typecheck/should_fail/T16255 * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 06:38:17 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 06:38:17 -0000 Subject: [GHC] #16240: Core visible conditional compilation/static definition/code selection based upon static key values In-Reply-To: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> References: <045.13d2183fb480a36d6fb29294b9840f81@haskell.org> Message-ID: <060.2fb985f42778a563362c6cb8244589de@haskell.org> #16240: Core visible conditional compilation/static definition/code selection based upon static key values -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 08:33:03 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 08:33:03 -0000 Subject: [GHC] #16077: AvailTC Invariant being violated In-Reply-To: <050.e27325be4d9bf8b20310c66c423e8dec@haskell.org> References: <050.e27325be4d9bf8b20310c66c423e8dec@haskell.org> Message-ID: <065.990100ed650948df39c8623901ada9dd@haskell.org> #16077: AvailTC Invariant being violated -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/276 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/276 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 08:41:18 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 08:41:18 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled In-Reply-To: <043.bd7f9da23904789b86411de4cb766153@haskell.org> References: <043.bd7f9da23904789b86411de4cb766153@haskell.org> Message-ID: <058.025a1bd2131144cc557319e69f62d84e@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): There was a (probably) spurious failure of this in https://gitlab.haskell.org/ghc/ghc/-/jobs/20475. Let's see if this happens again (https://gitlab.haskell.org/ghc/ghc/-/jobs/20799). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 10:20:21 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 10:20:21 -0000 Subject: [GHC] #16277: Make JUnit report stdout/stderr in more cases Message-ID: <049.40a6f3d57e64a67ad36500d6a5e6617b@haskell.org> #16277: Make JUnit report stdout/stderr in more cases -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In https://gitlab.haskell.org/ghc/ghc/merge_requests/210 we made a start to improve the junit output to also include stderr/stdout when appropriate. However, the patch only handles a few cases, it is reasonably straightforward to handle more cases but the refactoring was a bit more involved than I was prepared to do at the time. To find more places, look in `testlib.py` and grep for `failBecause`. There are examples such as `bad stderr` and `bad stdout` which would also benefit from reporting the stderr. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 11:47:38 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 11:47:38 -0000 Subject: [GHC] #16278: Exhaustivity checking GADT with free variables Message-ID: <049.199fd933d706220cb9a06244d6ddd756@haskell.org> #16278: Exhaustivity checking GADT with free variables -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider the following example: {{{#!hs {-# language DataKinds #-} {-# language TypeFamilies #-} {-# language GADTs #-} {-# language KindSignatures #-} {-# OPTIONS_GHC -Wall -fforce-recomp #-} module GadtException where import Data.Kind (Type) import GHC.Exts data Send = Send data SocketException :: Send -> Type where LocalShutdown :: SocketException 'Send OutOfMemory :: SocketException a someSocketException :: SocketException a someSocketException = OutOfMemory foo :: Int foo = case someSocketException :: SocketException Any of LocalShutdown -> 2 OutOfMemory -> 1 }}} In `foo`, GHC's exhaustivity checker requires a pattern match on `LocalShutdown`. However, `LocalShutdown` is not an inhabitant of `SocketException Any`. What I would really like is for this to go one step further. I shouldn't even need to write the type annotation. That is, with the above code otherwise unchanged, GHC should recognize that {{{#!hs foo :: Int foo = case someSocketException of OutOfMemory -> 1 }}} handles all possible cases. Since fully polymorphic type variables become `Any` at some point during typechecking, I would expect that if this worked with the `SocketException Any` type signature, it would work without it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 14:16:18 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 14:16:18 -0000 Subject: [GHC] #16278: Exhaustivity checking GADT with free variables In-Reply-To: <049.199fd933d706220cb9a06244d6ddd756@haskell.org> References: <049.199fd933d706220cb9a06244d6ddd756@haskell.org> Message-ID: <064.543780cd1b345e7e84152b3c3c4fac97@haskell.org> #16278: Exhaustivity checking GADT with free variables -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The pattern-match coverage checker is only able to conclude that `LocalShutdown` is an unreachable case if it can reason that `Send` and `Any` are //apart// as types (i.e., they can never possibly unify). For whatever reason, GHC appears to be unable to do this, even though `Any` is a closed type family. For most type families, this makes sense—imagine if you had: {{{#!hs type family F :: Send }}} And tried matching on a value of type `SocketException F`. GHC would be completely justified in declaring `LocalShutdown` to be a reachable case here. Even if the module you're writing didn't have any instances for `F`, due to the open-world assumption, it's possible that you might bring in another module later which declares `type instance F = 'Send`. Closed type families add an interesting wrinkle since they're, well, not open. That is, no one can write `type instance Any = 'Send`, so in theory, it should never be the case that `Any ~ 'Send`. That being said, teaching GHC to reason like this for arbitrary closed type families sounds challenging. Consider the following example: {{{#!hs data Nat = Z | S Nat type family Id (a :: k) :: k where Id x = x type family G (a :: Nat) :: k G Z = () G (S n) = Id (G n) }}} Is `G a` ever equal to `'Send`? The answer is no, but determining this requires some nontrivial reasoning. GHC would need to be able to figure out that `G a` cannot ever reduce to `'Send` by a sort of inductive argument. Moreover, GHC would also need to be aware of how `Id`, a different type family, reduces. Bottom line: while I can sympathize with your desire not to write a case for `LocalException`, actually teaching GHC the smarts to reason about this seems quite tricky. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 14:40:17 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 14:40:17 -0000 Subject: [GHC] #16265: API Annotations: parens anns discarded for `(*)` operator In-Reply-To: <044.e28d1a2b447340e3749a232e774365bf@haskell.org> References: <044.e28d1a2b447340e3749a232e774365bf@haskell.org> Message-ID: <059.34785257884af118bf802ef0f345b2fd@haskell.org> #16265: API Annotations: parens anns discarded for `(*)` operator -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): gitlab MR is https://gitlab.haskell.org/ghc/ghc/merge_requests/278 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 15:52:13 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 15:52:13 -0000 Subject: [GHC] #16279: Lexer: Alternate Layout Rule injects actual not virtual braces Message-ID: <044.73378e875f9cb441e9847c7b1258c533@haskell.org> #16279: Lexer: Alternate Layout Rule injects actual not virtual braces -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect API Unknown/Multiple | annotation Test Case: | Blocked By: Blocking: | Related Tickets: #13807 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When the alternate layout rule is activated via a pragma, it injects tokens for `{` and `}` to make sure that the source is parsed properly. But it injects `ITocurly` and `ITccurly`, rather than their virtual counterparts `ITvocurly` and `ITvccurly`. This causes problems for `ghc-exactprint`, which tries to print these. Test case (the existing T13087.hs) {{{#!hs {-# LANGUAGE AlternativeLayoutRule #-} {-# LANGUAGE LambdaCase #-} isOne :: Int -> Bool isOne = \case 1 -> True _ -> False main = return () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 15:52:35 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 15:52:35 -0000 Subject: [GHC] #16279: Lexer: Alternate Layout Rule injects actual not virtual braces In-Reply-To: <044.73378e875f9cb441e9847c7b1258c533@haskell.org> References: <044.73378e875f9cb441e9847c7b1258c533@haskell.org> Message-ID: <059.ba9289771a1712793fb048c9f824e9f9@haskell.org> #16279: Lexer: Alternate Layout Rule injects actual not virtual braces -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: #13807 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: (none) => alanz * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 16:12:49 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 16:12:49 -0000 Subject: [GHC] #16278: Exhaustivity checking GADT with free variables In-Reply-To: <049.199fd933d706220cb9a06244d6ddd756@haskell.org> References: <049.199fd933d706220cb9a06244d6ddd756@haskell.org> Message-ID: <064.305066ea12b9371795328071e8f00d26@haskell.org> #16278: Exhaustivity checking GADT with free variables -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Thanks for the insights! I’m not certain that GHC replaces the polymorphic type variable with Any before the exhaustiveness check happens. (Although I suspect it does). If it does, then is unfortunate that we end up doing an apartness check for `'Send` an `Any` when what should actually happen is an apartness check for `'Send` and `forall (s :: Send). s` (talking about the second example where I omitted the type annotation). You make a good argument that teaching the compiler about apartness involving type families in the general case is difficult or maybe in possible. But there are more specific cases where deciding apartness is a more tractable problem. You could consider only non-recursive type families, only type families that don’t mention other type families, nullary type families, or the combination of all three (aka Any). From what I’ve found in the GHC wiki, it looks like the apartness check is an approximation anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 17:29:12 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 17:29:12 -0000 Subject: [GHC] #16227: T15897 causes CI failures due to timing out In-Reply-To: <049.83b38b7e4fac1d345415f88c07f804e1@haskell.org> References: <049.83b38b7e4fac1d345415f88c07f804e1@haskell.org> Message-ID: <064.3eec3b4cc194399bdb93114174f2e2c1@haskell.org> #16227: T15897 causes CI failures due to timing out -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16193 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #16193 Comment: Duplicate of #16193. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 2 22:54:02 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 22:54:02 -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.3b9f57893fc27f715ee20a5ab2360531@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 <- (isInfinite -> True) > where Infinity = 1 / 0 > }}} > > Used > [https://github.com/cchalmers/optical/blob/a85484ad23a7f4d6b5da1dcb78781ea9c488a246/src/Optical/Patterns.hs#L37 > here] 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 === Foreign.Ptr === {{{#!hs pattern NullPtr :: Ptr a pattern NullPtr <- ((==) nullPtr -> True) where NullPtr = nullPtr }}} 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 Sat Feb 2 22:54:29 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Feb 2019 22:54:29 -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.8863dccc69656e6c321c92417b64aa12@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 <- (isInfinite -> True) > where Infinity = 1 / 0 > > === Foreign.Ptr === > {{{#!hs > pattern NullPtr :: Ptr a > pattern NullPtr <- ((==) nullPtr -> True) > where NullPtr = nullPtr > }}} > > Used > [https://github.com/cchalmers/optical/blob/a85484ad23a7f4d6b5da1dcb78781ea9c488a246/src/Optical/Patterns.hs#L37 > here] 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 }}} === Foreign.Ptr === {{{#!hs pattern NullPtr :: Ptr a pattern NullPtr <- ((==) nullPtr -> True) where NullPtr = nullPtr }}} 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 Sun Feb 3 05:28:48 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Feb 2019 05:28:48 -0000 Subject: [GHC] #16280: Update Latest page of User's Guide to GHC 8.6.3 Message-ID: <047.abc3e843d885dfc04721070285c01512@haskell.org> #16280: Update Latest page of User's Guide to GHC 8.6.3 -------------------------------------+------------------------------------- Reporter: wataru86 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Latest version of GHC is 8.6.3. However, latest page of User's Guide is 8.6.2(https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/index.html). Please Update to GHC 8.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 3 14:06:15 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Feb 2019 14:06:15 -0000 Subject: [GHC] #11084: Some type families don't reduce with :kind! In-Reply-To: <047.af59c4538fa4f004723d249cfac399d5@haskell.org> References: <047.af59c4538fa4f004723d249cfac399d5@haskell.org> Message-ID: <062.d8e7fc19db119ef01d8f7ce9c5afa4c4@haskell.org> #11084: Some type families don't reduce with :kind! -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've trimmed down this example even more: {{{#!hs {-# LANGUAGE TypeFamilies #-} module T11084Aux where type family F a type instance F a = Int }}} {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module T11084 where import T11084Aux type family G where G = F Char }}} Moreover, `cabal new-build` makes it much easier to reproduce this bug than it used to be. Now all you have to do is this: {{{ $ git clone https://github.com/RyanGlScott/ghc-t11084 $ cd ghc-t11084/ $ cabal new-build -w /opt/ghc/8.6.3/bin/ghc $ /opt/ghc/8.6.3/bin/ghci -package-env .ghc.environment.x86_64-linux-8.6.3 GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Loaded package environment from .ghc.environment.x86_64-linux-8.6.3 Loaded package environment from .ghc.environment.x86_64-linux-8.6.3 Loaded GHCi configuration from /home/rgscott/.ghci λ> import T11084 λ> :kind! G G :: * = ghc-t11084-0.1:T11084Aux.F Char λ> :kind! G G :: * = Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 3 15:46:45 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Feb 2019 15:46:45 -0000 Subject: [GHC] #16281: PatternSynonyms doesn't accept non-prenex quantified functions, doesn't float foralls Message-ID: <051.bf999c3bd41c3e4737fb5cffccc82bdc@haskell.org> #16281: PatternSynonyms doesn't accept non-prenex quantified functions, doesn't float foralls -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This works under GHC HEAD (8.7.20190115) {{{#!hs {-# Language RankNTypes #-} {-# Language ViewPatterns #-} {-# Language PatternSynonyms #-} newtype Logic a = Logic (forall xx. (a -> (xx -> xx)) -> (xx -> xx)) runLogic :: Logic a -> forall xx. (a -> xx -> xx) -> (xx -> xx) runLogic (Logic logic) = logic pattern L :: (forall xx. (a -> xx -> xx) -> xx -> xx) -> Logic a pattern L f <- (runLogic -> f) }}} I was under the impression that these would be equivalent {{{#!hs runLogic :: Logic a -> forall xx. (a -> xx -> xx) -> (xx -> xx) runLogic :: Logic a -> (a -> xx -> xx) -> (xx -> xx) }}} apart from the order of visible type application and such, but it fails: {{{#!hs {-# Language RankNTypes #-} {-# Language ViewPatterns #-} {-# Language PatternSynonyms #-} newtype Logic a = Logic (forall xx. (a -> (xx -> xx)) -> (xx -> xx)) runLogic :: Logic a -> (a -> xx -> xx) -> (xx -> xx) runLogic (Logic logic) = logic pattern L :: (forall xx. (a -> xx -> xx) -> xx -> xx) -> Logic a pattern L f <- (runLogic -> f) }}} {{{ $ ... -ignore-dot-ghci 1022_bug.hs GHCi, version 8.7.20190115: https://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 1022_bug.hs, interpreted ) 1022_bug.hs:11:29: error: • Couldn't match expected type ‘forall xx. (a -> xx -> xx) -> xx -> xx’ with actual type ‘(a -> xx0 -> xx0) -> xx0 -> xx0’ • In the declaration for pattern synonym ‘L’ • Relevant bindings include f :: (a -> xx0 -> xx0) -> xx0 -> xx0 (bound at 1022_bug.hs:11:29) | 11 | pattern L f <- (runLogic -> f) | ^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 3 22:56:23 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Feb 2019 22:56:23 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC In-Reply-To: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> References: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> Message-ID: <058.8228f3c6d08bc45ceae618d94f71b57e@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 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 mpickering): * priority: high => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 3 22:59:41 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Feb 2019 22:59:41 -0000 Subject: [GHC] #16282: all-missed-specializations doesn't suggest warning Message-ID: <047.dd59e0ffb2b5e177646617818ff04a7f@haskell.org> #16282: all-missed-specializations doesn't suggest warning -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- `-Weverything` turns on `-Wall-missed-specializations`. When most warnings print, they say, e.g., `warning: [-Wincomplete-uni-patterns]` which is helpful because I can then easily suppress all warnings of that type with an `-fno-warn-*`. But missed specializations do not show the warning flag: {{{ Foo.hs: warning: Could not specialise imported function `foo' Probable fix: add INLINABLE pragma on `foo' }}} There is no indication of what warning flag triggered the warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 08:57:15 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 08:57:15 -0000 Subject: [GHC] #16278: Exhaustivity checking GADT with free variables In-Reply-To: <049.199fd933d706220cb9a06244d6ddd756@haskell.org> References: <049.199fd933d706220cb9a06244d6ddd756@haskell.org> Message-ID: <064.b0d984b86ae32760286b546afbecd786@haskell.org> #16278: Exhaustivity checking GADT with free variables -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 09:22:51 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 09:22:51 -0000 Subject: [GHC] #16283: StaticPointers pragma changes generated code even when the feature is not used Message-ID: <043.e8090049b9015e07170f6eb0b71467b6@haskell.org> #16283: StaticPointers pragma changes generated code even when the feature is not used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tried with GHC HEAD. Program: {{{ module Main where import Control.Concurrent import System.Mem nats :: [Int] nats = [0 .. ] main = do let z = nats !! 400 print z performGC threadDelay 1000000 print (nats !! 900) }}} Compile without any flags: {{{ ==================== Tidy Core ==================== 2019-02-04 09:16:26.121849511 UTC Result size of Tidy Core = {terms: 45, types: 26, coercions: 0, joins: 0/0} -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule1_r1zg :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule1_r1zg = "main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} $trModule2_r1zt :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule2_r1zt = GHC.Types.TrNameS $trModule1_r1zg -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule3_r1zu :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule3_r1zu = "Main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} $trModule4_r1zv :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule4_r1zv = GHC.Types.TrNameS $trModule3_r1zu -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} Main.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs, Unf=OtherCon []] Main.$trModule = GHC.Types.Module $trModule2_r1zt $trModule4_r1zv -- RHS size: {terms: 4, types: 1, coercions: 0, joins: 0/0} nats :: [Int] [GblId] nats = enumFrom @ Int GHC.Enum.$fEnumInt (GHC.Types.I# 0#) -- RHS size: {terms: 22, types: 13, coercions: 0, joins: 0/0} main :: IO () [GblId] main = >> @ IO GHC.Base.$fMonadIO @ () @ () (print @ Int GHC.Show.$fShowInt (!! @ Int nats (GHC.Types.I# 400#))) (>> @ IO GHC.Base.$fMonadIO @ () @ () performGC (>> @ IO GHC.Base.$fMonadIO @ () @ () (threadDelay (GHC.Types.I# 1000000#)) (print @ Int GHC.Show.$fShowInt (!! @ Int nats (GHC.Types.I# 900#))))) -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} :Main.main :: IO () [GblId] :Main.main = GHC.TopHandler.runMainIO @ () main }}} Compile with `-XStaticPointers`: {{{ ==================== Tidy Core ==================== 2019-02-04 09:16:35.678350955 UTC Result size of Tidy Core = {terms: 67, types: 42, coercions: 0, joins: 0/0} -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule1_r1zg :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule1_r1zg = "main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} $trModule2_r1zF :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule2_r1zF = GHC.Types.TrNameS $trModule1_r1zg -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule3_r1zG :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule3_r1zG = "Main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} $trModule4_r1zH :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule4_r1zH = GHC.Types.TrNameS $trModule3_r1zG -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} Main.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs, Unf=OtherCon []] Main.$trModule = GHC.Types.Module $trModule2_r1zF $trModule4_r1zH -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} lvl_r1zI :: Int [GblId, Caf=NoCafRefs, Unf=OtherCon []] lvl_r1zI = GHC.Types.I# 0# -- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} nats :: [Int] [GblId] nats = enumFrom @ Int GHC.Enum.$fEnumInt lvl_r1zI -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} lvl1_r1zJ :: Int [GblId, Caf=NoCafRefs, Unf=OtherCon []] lvl1_r1zJ = GHC.Types.I# 400# -- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} lvl2_r1zK :: Int [GblId] lvl2_r1zK = !! @ Int nats lvl1_r1zJ -- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} lvl3_r1zL :: IO () [GblId] lvl3_r1zL = print @ Int GHC.Show.$fShowInt lvl2_r1zK -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} lvl4_r1zM :: Int [GblId, Caf=NoCafRefs, Unf=OtherCon []] lvl4_r1zM = GHC.Types.I# 1000000# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} lvl5_r1zN :: IO () [GblId] lvl5_r1zN = threadDelay lvl4_r1zM -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} lvl6_r1zO :: Int [GblId, Caf=NoCafRefs, Unf=OtherCon []] lvl6_r1zO = GHC.Types.I# 900# -- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} lvl7_r1zP :: Int [GblId] lvl7_r1zP = !! @ Int nats lvl6_r1zO -- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} lvl8_r1zQ :: IO () [GblId] lvl8_r1zQ = print @ Int GHC.Show.$fShowInt lvl7_r1zP -- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} lvl9_r1zR :: IO () [GblId] lvl9_r1zR = >> @ IO GHC.Base.$fMonadIO @ () @ () lvl5_r1zN lvl8_r1zQ -- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} lvl10_r1zS :: IO () [GblId] lvl10_r1zS = >> @ IO GHC.Base.$fMonadIO @ () @ () performGC lvl9_r1zR -- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} main :: IO () [GblId] main = >> @ IO GHC.Base.$fMonadIO @ () @ () lvl3_r1zL lvl10_r1zS -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} :Main.main :: IO () [GblId] :Main.main = GHC.TopHandler.runMainIO @ () main }}} Diff: {{{ --- no_static_ptrs/GcStaticPointers.dump-simpl 2019-02-04 12:16:26.120066655 +0300 +++ static_ptrs/GcStaticPointers.dump-simpl 2019-02-04 12:16:35.675924328 +0300 @@ -1,9 +1,9 @@ ==================== Tidy Core ==================== -2019-02-04 09:16:26.121849511 UTC +2019-02-04 09:16:35.678350955 UTC Result size of Tidy Core - = {terms: 45, types: 26, coercions: 0, joins: 0/0} + = {terms: 67, types: 42, coercions: 0, joins: 0/0} -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} $trModule1_r1zg :: GHC.Prim.Addr# @@ -11,55 +11,91 @@ $trModule1_r1zg = "main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} -$trModule2_r1zt :: GHC.Types.TrName +$trModule2_r1zF :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] -$trModule2_r1zt = GHC.Types.TrNameS $trModule1_r1zg +$trModule2_r1zF = GHC.Types.TrNameS $trModule1_r1zg -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} -$trModule3_r1zu :: GHC.Prim.Addr# +$trModule3_r1zG :: GHC.Prim.Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] -$trModule3_r1zu = "Main"# +$trModule3_r1zG = "Main"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} -$trModule4_r1zv :: GHC.Types.TrName +$trModule4_r1zH :: GHC.Types.TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] -$trModule4_r1zv = GHC.Types.TrNameS $trModule3_r1zu +$trModule4_r1zH = GHC.Types.TrNameS $trModule3_r1zG -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} Main.$trModule :: GHC.Types.Module [GblId, Caf=NoCafRefs, Unf=OtherCon []] -Main.$trModule = GHC.Types.Module $trModule2_r1zt $trModule4_r1zv +Main.$trModule = GHC.Types.Module $trModule2_r1zF $trModule4_r1zH --- RHS size: {terms: 4, types: 1, coercions: 0, joins: 0/0} +-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} +lvl_r1zI :: Int +[GblId, Caf=NoCafRefs, Unf=OtherCon []] +lvl_r1zI = GHC.Types.I# 0# + +-- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} nats :: [Int] [GblId] -nats = enumFrom @ Int GHC.Enum.$fEnumInt (GHC.Types.I# 0#) +nats = enumFrom @ Int GHC.Enum.$fEnumInt lvl_r1zI + +-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} +lvl1_r1zJ :: Int +[GblId, Caf=NoCafRefs, Unf=OtherCon []] +lvl1_r1zJ = GHC.Types.I# 400# + +-- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} +lvl2_r1zK :: Int +[GblId] +lvl2_r1zK = !! @ Int nats lvl1_r1zJ + +-- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} +lvl3_r1zL :: IO () +[GblId] +lvl3_r1zL = print @ Int GHC.Show.$fShowInt lvl2_r1zK + +-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} +lvl4_r1zM :: Int +[GblId, Caf=NoCafRefs, Unf=OtherCon []] +lvl4_r1zM = GHC.Types.I# 1000000# + +-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} +lvl5_r1zN :: IO () +[GblId] +lvl5_r1zN = threadDelay lvl4_r1zM + +-- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} +lvl6_r1zO :: Int +[GblId, Caf=NoCafRefs, Unf=OtherCon []] +lvl6_r1zO = GHC.Types.I# 900# + +-- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} +lvl7_r1zP :: Int +[GblId] +lvl7_r1zP = !! @ Int nats lvl6_r1zO + +-- RHS size: {terms: 3, types: 1, coercions: 0, joins: 0/0} +lvl8_r1zQ :: IO () +[GblId] +lvl8_r1zQ = print @ Int GHC.Show.$fShowInt lvl7_r1zP + +-- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} +lvl9_r1zR :: IO () +[GblId] +lvl9_r1zR + = >> @ IO GHC.Base.$fMonadIO @ () @ () lvl5_r1zN lvl8_r1zQ + +-- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} +lvl10_r1zS :: IO () +[GblId] +lvl10_r1zS + = >> @ IO GHC.Base.$fMonadIO @ () @ () performGC lvl9_r1zR --- RHS size: {terms: 22, types: 13, coercions: 0, joins: 0/0} +-- RHS size: {terms: 4, types: 3, coercions: 0, joins: 0/0} main :: IO () [GblId] -main - = >> - @ IO - GHC.Base.$fMonadIO - @ () - @ () - (print - @ Int GHC.Show.$fShowInt (!! @ Int nats (GHC.Types.I# 400#))) - (>> - @ IO - GHC.Base.$fMonadIO - @ () - @ () - performGC - (>> - @ IO - GHC.Base.$fMonadIO - @ () - @ () - (threadDelay (GHC.Types.I# 1000000#)) - (print - @ Int GHC.Show.$fShowInt (!! @ Int nats (GHC.Types.I# 900#))))) +main = >> @ IO GHC.Base.$fMonadIO @ () @ () lvl3_r1zL lvl10_r1zS -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0} :Main.main :: IO () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 09:53:08 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 09:53:08 -0000 Subject: [GHC] #16283: StaticPointers pragma changes generated code even when the feature is not used In-Reply-To: <043.e8090049b9015e07170f6eb0b71467b6@haskell.org> References: <043.e8090049b9015e07170f6eb0b71467b6@haskell.org> Message-ID: <058.0038c3af7437162aabd3065013e22eda@haskell.org> #16283: StaticPointers pragma changes generated code even when the feature is not used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The extension does turn on another partial run of the simplified so perhaps this isn't surprising. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 10:05:10 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 10:05:10 -0000 Subject: [GHC] #16283: StaticPointers pragma changes generated code even when the feature is not used In-Reply-To: <043.e8090049b9015e07170f6eb0b71467b6@haskell.org> References: <043.e8090049b9015e07170f6eb0b71467b6@haskell.org> Message-ID: <058.66e838bd3d8900f611766c802e1c775d@haskell.org> #16283: StaticPointers pragma changes generated code even when the feature is not used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): It's not surprising when you read the code, the question is whether this behavior makes sense or right from a user's point of view. I see no mentions of this in the user manual, and as a user I wouldn't expect enabling an unused feature to change runtime behavior of my programs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 10:47:46 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 10:47:46 -0000 Subject: [GHC] #15185: Enum instance for IntX / WordX are inefficient In-Reply-To: <045.8d849a48d67b73f64eaab8f541972e7c@haskell.org> References: <045.8d849a48d67b73f64eaab8f541972e7c@haskell.org> Message-ID: <060.9e74c0f0992c54ca8e13bf09d53d9ee8@haskell.org> #15185: Enum instance for IntX / WordX are inefficient -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Core Libraries | Version: 8.4.2 Resolution: | Keywords: Newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4820 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * keywords: => Newcomer Comment: The efficient implementation comes from `libraries/base/GHC/Enum.hs` where rules are defined. Implementing this should just be a matter of copying this approach for the other Int/Word variants. The correct place to put the rules for the Int/Word variants would be GHC.Int/GHC.Word in base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 11:12:08 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 11:12:08 -0000 Subject: [GHC] #16282: all-missed-specializations doesn't suggest warning In-Reply-To: <047.dd59e0ffb2b5e177646617818ff04a7f@haskell.org> References: <047.dd59e0ffb2b5e177646617818ff04a7f@haskell.org> Message-ID: <062.2995701e846c4cdb51d9d21893ee37f8@haskell.org> #16282: all-missed-specializations doesn't suggest warning -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 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): > There is no indication of what warning flag triggered the warning. Good point. Ought to be easy to fix, if someone feels like doing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 13:01:46 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 13:01:46 -0000 Subject: [GHC] #16259: Hadrian does not work with a cabal v2-installed "Happy" In-Reply-To: <049.ec13a85dcdc8dc8a560ef06cae684380@haskell.org> References: <049.ec13a85dcdc8dc8a560ef06cae684380@haskell.org> Message-ID: <064.8f06bce0d1d4394d7f6399ffd4838e6e@haskell.org> #16259: Hadrian does not work with a cabal v2-installed "Happy" -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Ok, so the problem here is that `happy` gets demoted into an inplace package (and this basically means that the resulting executable can't be invoked without setting a couple of env-vars, which `cabal {run,exec}` would do -- but if you don't invoke it that way you'd be responsible for doing this... long story), because it picked up a local dependency, namely the intree-`Cabal` for its `setup-depends`; a simple way to workaround this is inject a constraint to prevent Setup.hs scripts from using an unreleased version of lib:Cabal, via e.g. {{{#!diff diff --git a/hadrian/cabal.project b/hadrian/cabal.project index 176d1ee..d8e5e79 100644 --- a/hadrian/cabal.project +++ b/hadrian/cabal.project @@ -1,2 +1,4 @@ packages: ./ ../libraries/Cabal/Cabal/ + +constraints: setup.Cabal < 2.5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 13:19:31 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 13:19:31 -0000 Subject: [GHC] #16282: all-missed-specializations doesn't suggest warning In-Reply-To: <047.dd59e0ffb2b5e177646617818ff04a7f@haskell.org> References: <047.dd59e0ffb2b5e177646617818ff04a7f@haskell.org> Message-ID: <062.15dbeaf7fa5429835eacc632b48b3fd3@haskell.org> #16282: all-missed-specializations doesn't suggest warning -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 14:59:28 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 14:59:28 -0000 Subject: [GHC] #16270: Report multiple errors during parsing In-Reply-To: <048.8241d0d6fb8bb59986f0e3aa22e6e182@haskell.org> References: <048.8241d0d6fb8bb59986f0e3aa22e6e182@haskell.org> Message-ID: <063.c0989c2539d3536bf8804bed54daf678@haskell.org> #16270: Report multiple errors during parsing -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | 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 int-index): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 15:22:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 15:22:34 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.c3eb56dae6e371cca273fb9c527b0f8c@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 15:28:23 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 15:28:23 -0000 Subject: [GHC] #16278: Exhaustivity checking GADT with free variables In-Reply-To: <049.199fd933d706220cb9a06244d6ddd756@haskell.org> References: <049.199fd933d706220cb9a06244d6ddd756@haskell.org> Message-ID: <064.6e2906efcc5bc7cd8def924eda885eb6@haskell.org> #16278: Exhaustivity checking GADT with free variables -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): I guess `Any` isn't really a nullary type family since the `k` argument is invisible. So, the special case that needs to be handled to make this work is "all empty type families, regardless of arity". But I think it could be done a little more broadly. Playing with the type checker, I found that this compiles: {{{#!haskell {-# language DataKinds #-} {-# language TypeFamilies #-} module TypeEqualities where type family Foo (b :: Bool) :: Bool foo :: (Foo 'True ~ 'True, Foo 'True ~ Foo 'False) => Int foo = 5 }}} My interpretation of this is that type family applications that do not reduce are not considered apart from anything. The behavior that would help me is for non-reducing type family applications with constant arguments to be considered apart from everything except for themselves. Using the above example, `Foo 'True ~ Foo 'True` would typecheck, but `Foo 'True ~ 'True` and `Foo 'True ~ Foo 'False` would both be rejected. In bulleted form, the requirement I listed are: * Non-reducing (or stuck) * Constant arguments (yes: `Foo 'True`, no: `Foo x`) I'm not sure if this is introduces inconsistencies or has any negative side effects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 16:04:49 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 16:04:49 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.ce10813f0047ef2c8548be70748e4040@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: RolandSenn Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TESTS="T10857a T10857b" Blocked By: | Blocking: Related Tickets: #3202, #3217, | Differential Rev(s): Gitlab Merge #14551 | Request 35 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 16:24:47 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 16:24:47 -0000 Subject: [GHC] #16284: Abortion of fixed-point iteration in Demand Analyser discards sound results Message-ID: <044.1b1640b134063ede257d06bf3299fb76@haskell.org> #16284: Abortion of fixed-point iteration in Demand Analyser discards sound results -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple DemandAnalysis | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs -- Extracted from T4903 module Foo where data Tree = Bin Tree Tree tree :: Tree tree = Bin tree tree eq :: Tree -> Bool eq (Bin l r) = eq l && eq r }}} `eq` amounts to the following Core: {{{#!hs eq = \ (ds_d20O :: Tree) -> case ds_d20O of { Bin l_aY8 r_aY9 -> case eq l_aY8 of { False -> False; True -> eq r_aY9 } } }}} It clearly diverges. That's also what pure strictness/termination/CPR analysis would find out. But because usage analysis can't find out in finite time (and that's fine) that `eq` uses its argument completely, we abort fixed-point iteration [1] and return `nopSig`, discarding useful and sound strictness information we found out along the way, like the fact that it diverges. This isn't hard to fix: Just track which parts of the signature were still unsound during abortion and only zap them. I'm only recording this for posterity and as an argument in a discussion I'll maybe start in a few months of time... [1] This is the ascending chain of demands on `ds_d20O` during fixed-point iteration: {{{ H U(1*H,1*H) U(1*U(1*H,1*H),1*U(1*H,1*H)) ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 16:32:15 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 16:32:15 -0000 Subject: [GHC] #16205: Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault In-Reply-To: <050.d7b057846385022a46b6bbbc0d3f3d2b@haskell.org> References: <050.d7b057846385022a46b6bbbc0d3f3d2b@haskell.org> Message-ID: <065.65e2fc1a786be06bc7d82edd99b80879@haskell.org> #16205: Printing a large (GMP) Integer in ghci-ext with LLVM causes a segfault -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: llvm integer- | gmp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I think this is the same issue as #16087 really. I bet they all pass with `integer-simple`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 16:36:30 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 16:36:30 -0000 Subject: [GHC] #16285: Hadrian fails to run the testsuite. Message-ID: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> #16285: Hadrian fails to run the testsuite. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is on windows with a tree based on the commit below. {{{ commit a5373c1f (master) Author: Simon Peyton Jones Date: Wed Jan 16 16:34:24 2019 +0000 Fix bogus worker for newtypes }}} Output as follows. {{{ $ hadrian/build.bat -c -j8 --flavour=quick test Up to date Up to date hadrian: Encountered missing dependencies: libiserv ==8.7 shakeArgsWith 0.001s 0% Function shake 0.010s 0% Database read 0.516s 13% === Database compression 0.074s 1% With database 0.018s 0% Running rules 3.280s 84% ========================= Total 3.900s 100% Error when running Shake build system: at src/Main.hs:58:30-42: * Depends on: test at src/Rules/Test.hs:90:5-17: * Depends on: _build/stage1/lib/bin/ghc-iserv.exe at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68: * Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Program, pkgName = "iserv", pkgPath = "utils/iserv"}, way = v})) at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36: * Depends on: _build/stage1/utils/iserv/setup-config * Raised the exception: ExitFailure 1 }}} Regular build with hadrian works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 16:40:47 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 16:40:47 -0000 Subject: [GHC] #16285: Hadrian fails to run the testsuite. In-Reply-To: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> References: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> Message-ID: <062.0abd34eda596c1f8a54c40d56e20a85a@haskell.org> #16285: Hadrian fails to run the testsuite. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * os: Unknown/Multiple => Windows * component: Compiler => Build System (Hadrian) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 17:27:27 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 17:27:27 -0000 Subject: [GHC] #16285: Hadrian fails to run the testsuite. In-Reply-To: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> References: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> Message-ID: <062.e7f0f5dae3bd9a6f846f53645dc0bae4@haskell.org> #16285: Hadrian fails to run the testsuite. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 17:51:51 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 17:51:51 -0000 Subject: [GHC] #16285: Hadrian fails to run the testsuite. In-Reply-To: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> References: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> Message-ID: <062.f1d084bd8ff9e119e49bf61b6bb80621@haskell.org> #16285: Hadrian fails to run the testsuite. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Verbose output: https://www.irccloud.com/pastebin/rWn7WMsx/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 18:06:46 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 18:06:46 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.9061d1ce82eed385359d4a9e2454f8dd@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Runtime System | Version: 8.0.1 (Linker) | Keywords: linker, Resolution: | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 8949 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by artempyanykh): I've adjusted section mapping and relocations for x64 Mach-O - the attached program runs fine and ghci, rts, TH tests are green. I've found some other issues along the way, but no show stoppers. I'll assign this ticket to myself and hope to prepare a MR soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 18:07:20 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 18:07:20 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.93c96d20c6643cef8f58f232ed92e304@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: artempyanykh Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Runtime System | Version: 8.0.1 (Linker) | Keywords: linker, Resolution: | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 8949 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by artempyanykh): * owner: (none) => artempyanykh -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 18:12:55 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 18:12:55 -0000 Subject: [GHC] #14180: Strange/bad error message binding unboxed type variable In-Reply-To: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> References: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> Message-ID: <060.82672a44d4be3e3193f67a43ed3b5ae5@haskell.org> #14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To motivate why I want this, it's because the [http://hackage.haskell.org/package/kind-generics kind-generics] library (described in the paper //Generics of All Kinds//) is attempting to come up with a uniform representation of both lifted and unlifted types. Due to the way `kind-generics` works, we need to implement a type family with this shape: {{{#!hs type family Interpret (t :: Atom d k) (tys :: LoT d) :: k where }}} Where `k` is the type of the type being interpreted. At the moment, since `k :: Type`, `Interpret` is exclusively limited to use with lifted types. I'd like to be able to instead say: {{{#!hs type family Interpret (t :: Atom d (k :: TYPE r)) (tys :: LoT d) :: (k :: TYPE r) where }}} But GHC won't let me do so for the same reasons as in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 18:37:27 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 18:37:27 -0000 Subject: [GHC] #16004: Vector performance regression in GHC 8.6 In-Reply-To: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> References: <045.dc25793e8a1045771ce2b64f57c00196@haskell.org> Message-ID: <060.7e84818a7a2af404908d4f206a2892e6@haskell.org> #16004: Vector performance regression in GHC 8.6 -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 18:46:22 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 18:46:22 -0000 Subject: [GHC] #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail In-Reply-To: <047.ee50015c31757be835f8de5387a42628@haskell.org> References: <047.ee50015c31757be835f8de5387a42628@haskell.org> Message-ID: <062.cd70f6b40592494d2c5c3aa8004f3623@haskell.org> #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Big-endian Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | primops/should_run/ArithInt16, | primops/should_run/ArithWord16, | primops/should_run/ArithWord8, | primops/should_run/ArithInt8 Blocked By: | Blocking: Related Tickets: #16222 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/286 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/286 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 18:47:31 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 18:47:31 -0000 Subject: [GHC] #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail In-Reply-To: <047.ee50015c31757be835f8de5387a42628@haskell.org> References: <047.ee50015c31757be835f8de5387a42628@haskell.org> Message-ID: <062.f9a5f6c0f3b88bad5706a8e9e7db8b5a@haskell.org> #16258: PowerPC Big-Endian: ArithInt16, ArithInt8, ArithWord16, and ArithWord8 fail -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: Big-endian Operating System: Unknown/Multiple | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: at runtime | primops/should_run/ArithInt16, | primops/should_run/ArithWord16, | primops/should_run/ArithWord8, | primops/should_run/ArithInt8 Blocked By: | Blocking: Related Tickets: #16222 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/286 -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 4 19:36:40 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Feb 2019 19:36:40 -0000 Subject: [GHC] #16075: Weverything ignores some OPTIONS_GHC flags In-Reply-To: <047.71239b51b70aad041042b035411a0e7b@haskell.org> References: <047.71239b51b70aad041042b035411a0e7b@haskell.org> Message-ID: <062.83da01c7ccb26f649f4f105e6a5deb14@haskell.org> #16075: Weverything ignores some OPTIONS_GHC flags -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > When I enable `-Weverything`, some `OPTIONS_GHC` pragmas are respected, > while others are ignored. For example, with `-Weverything`, this file > > {{{ > main = print "hello" > > foo :: (Num a, Show a) => a -> IO () > foo = print . show > }}} > > generates warnings about: > > 1. missing an export list > 2. top-level binding [main] with no type sig > 3. redundant constraint [Num a] > > If I add `{-# OPTIONS_GHC -fno-warn-missing-signatures -fno-warn-missing- > export-lists -fno-warn-redundant-constraints #-}` to the top of the file > and recompile, I expect all warnings to go away. But GHC still reports > that `main` has no signature. > > Note that this problem doesn't occur with `-Wall`. With `-Wall`, the code > snippet warns about the missing signature on `main`, but when I add the > `OPTIONS_GHC`, the warning goes away. Thus this problem appears to be > unique to `Weverything`. New description: When I enable `-Weverything`, some `OPTIONS_GHC` pragmas are respected, while others are ignored. For example, with `-Weverything`, this file {{{ main = print "hello" foo :: (Num a, Show a) => a -> IO () foo = print . show }}} generates warnings about: 1. missing an export list 2. top-level binding [main] with no type sig 3. redundant constraint [Num a] If I add `{-# OPTIONS_GHC -fno-warn-missing-signatures -fno-warn-missing- export-lists -fno-warn-redundant-constraints #-}` to the top of the file and recompile, I expect all warnings to go away. But GHC still reports that `main` has no signature. Note that this problem doesn't occur with `-Wall`. With `-Wall`, the code snippet warns about the missing signature on `main`, but when I add the `OPTIONS_GHC`, the warning goes away. Thus this problem appears to be unique to `Weverything`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 03:04:52 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 03:04:52 -0000 Subject: [GHC] #16193: Nondeterministic T15897 timeout failures In-Reply-To: <050.6b50375f06c0c1355a5fdb64d26cefc5@haskell.org> References: <050.6b50375f06c0c1355a5fdb64d26cefc5@haskell.org> Message-ID: <065.6eed016256b4a76a3a0e9accebeb8648@haskell.org> #16193: Nondeterministic T15897 timeout failures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm going to disable this test as it has been making CI extremely fragile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 06:22:32 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 06:22:32 -0000 Subject: [GHC] #16206: Run Haddock's test suite in CI In-Reply-To: <046.45e8b6d65ce692f099b4b1d0d1ad5d4b@haskell.org> References: <046.45e8b6d65ce692f099b4b1d0d1ad5d4b@haskell.org> Message-ID: <061.cf39339dd81892f6faab7746221d235b@haskell.org> #16206: Run Haddock's test suite in CI -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/291 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/291 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 06:56:46 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 06:56:46 -0000 Subject: [GHC] #16092: Bug when trying to combine two lists In-Reply-To: <046.c690ffcd5e903e27c6ba41e1ef0aeb27@haskell.org> References: <046.c690ffcd5e903e27c6ba41e1ef0aeb27@haskell.org> Message-ID: <061.726651a06c4c0614ae700548fb6bb062@haskell.org> #16092: Bug when trying to combine two lists -------------------------------------+------------------------------------- Reporter: sutbult | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #13819 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > I want to write a function that takes two lists and returns a list that > includes every possible combination of elements from the two given lists, > using a given function. I thought that this code would work: > > {{{#!hs > combine :: (a -> b -> c) [a] -> [b] -> [c] > combine fn alist blist = [fn a b | a <- alist, b <- blist] > }}} > > However, when compiling, this message arises from GHC: > > Glasgow Haskell Compiler, Version 8.2.1, stage 2 booted by GHC version > 7.10.3 > Using binary package database: > /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d/package.cache > Using binary package database: > /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d/package.cache > package flags [] > loading package database > /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d > loading package database > /Users/samuelutbult/.ghc/x86_64-darwin-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 > /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d > loading package database > /Users/samuelutbult/.ghc/x86_64-darwin-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: *Combine.hs > !!! Chasing dependencies: finished in 0.69 milliseconds, allocated 0.222 > megabytes > Stable obj: [] > Stable BCO: [] > Ready for upsweep > [NONREC > ModSummary { > ms_hs_date = 2018-12-23 17:18:05.830132761 UTC > ms_mod = Main, > ms_textual_imps = [(Nothing, Prelude)] > ms_srcimps = [] > }] > *** Deleting temp files: > Deleting: > compile: input file Combine.hs > *** Checking old interface for Main (use -ddump-hi-diffs for more > details): > [1 of 1] Compiling Main ( Combine.hs, Combine.o ) > *** Parser [Main]: > !!! Parser [Main]: finished in 1.05 milliseconds, allocated 0.171 > 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-apple-darwin): > repSplitAppTys > a_anL[sk:1] > b_anM[sk:1] -> c_anN[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 > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: I want to write a function that takes two lists and returns a list that includes every possible combination of elements from the two given lists, using a given function. I thought that this code would work: {{{#!hs combine :: (a -> b -> c) [a] -> [b] -> [c] combine fn alist blist = [fn a b | a <- alist, b <- blist] }}} However, when compiling, this message arises from GHC: {{{ Glasgow Haskell Compiler, Version 8.2.1, stage 2 booted by GHC version 7.10.3 Using binary package database: /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d/package.cache Using binary package database: /Users/samuelutbult/.ghc/x86_64-darwin-8.2.1/package.conf.d/package.cache package flags [] loading package database /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d loading package database /Users/samuelutbult/.ghc/x86_64-darwin-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 /Library/Frameworks/GHC.framework/Versions/8.2.1-x86_64/usr/lib/ghc-8.2.1/package.conf.d loading package database /Users/samuelutbult/.ghc/x86_64-darwin-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: *Combine.hs !!! Chasing dependencies: finished in 0.69 milliseconds, allocated 0.222 megabytes Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2018-12-23 17:18:05.830132761 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Combine.hs *** Checking old interface for Main (use -ddump-hi-diffs for more details): [1 of 1] Compiling Main ( Combine.hs, Combine.o ) *** Parser [Main]: !!! Parser [Main]: finished in 1.05 milliseconds, allocated 0.171 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-apple-darwin): repSplitAppTys a_anL[sk:1] b_anM[sk:1] -> c_anN[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 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 Tue Feb 5 07:41:21 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 07:41:21 -0000 Subject: [GHC] #16286: Continuations are not labelled in the binaries even with -g3 Message-ID: <043.f64277feb071d6e3883ca3887adc23a1@haskell.org> #16286: Continuations are not labelled in the binaries even with -g3 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Any program would work as a reproducer, but here's what I'm using currently: {{{ {-# LANGUAGE StaticPointers #-} module Main where import Control.Concurrent import System.Mem nats :: [Int] nats = [0 .. ] main = do let z = nats !! 400 print z performGC threadDelay 1000000 print (nats !! 900) }}} If I do `printStack` every time the GC copies a stack I sometimes see stack frames like {{{ RET_SMALL (0x535568) }}} but in gdb or objdump output I can't find a symbol at that address, even when the program is built with `-g3`. When I print the location as `StgInfoTable*` I can see that it's a valid info table so `0x535578` should be labelled as `foo_info`. In the objdump output I see that the location is shown as this: {{{ 535563: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) ... 535570: 1e (bad) 535571: 00 00 add %al,(%rax) 535573: 00 00 add %al,(%rax) 535575: 00 00 add %al,(%rax) 535577: 00 bb e9 e2 85 00 add %bh,0x85e2e9(%rbx) 53557d: 48 83 c5 08 add $0x8,%rbp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 09:07:05 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 09:07:05 -0000 Subject: [GHC] #12509: ghci -XSafe fails in an inscrutable way In-Reply-To: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> References: <044.b0e5f692eb3b12e5d2440fd3cf9fb268@haskell.org> Message-ID: <059.f5f143d9cd930831f39db33137911c47@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T12509 Blocked By: | Blocking: Related Tickets: #13385, #14342 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/241 -------------------------------------+------------------------------------- Changes (by RolandSenn): * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 09:44:47 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 09:44:47 -0000 Subject: [GHC] #16287: :kind accepts bogus type Message-ID: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> #16287: :kind accepts bogus type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider this (current HEAD) {{{ ghci> type family F :: k ghci> data T :: (forall k. k) -> Type ghci> :kind T F T F :: * }}} This is bogus. `F` has arity 1, and cannot appear unsaturated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 09:49:46 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 09:49:46 -0000 Subject: [GHC] #16286: Continuations are not labelled in the binaries even with -g3 In-Reply-To: <043.f64277feb071d6e3883ca3887adc23a1@haskell.org> References: <043.f64277feb071d6e3883ca3887adc23a1@haskell.org> Message-ID: <058.f06113a023f3696b21e852c9c52d1df4@haskell.org> #16286: Continuations are not labelled in the binaries even with -g3 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I think we also don't generate labels for some closures. For example, I currently see `lvl7_r1Al_closure` in dump-asm, but gdb can't find `r1Al_closure` or `lvl7_r1Al_closure`, and I also don't see them in `nm` output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 10:54:14 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 10:54:14 -0000 Subject: [GHC] #13839: GHCi warnings do not respect the default module header In-Reply-To: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> References: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> Message-ID: <063.57f558ca7430df3740e5fb3a70524a94@haskell.org> #13839: GHCi warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST=T13839 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/292 -------------------------------------+------------------------------------- Changes (by RolandSenn): * differential: https://gitlab.haskell.org/ghc/ghc/merge_requests/215 => https://gitlab.haskell.org/ghc/ghc/merge_requests/292 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 11:33:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 11:33:27 -0000 Subject: [GHC] #16287: :kind accepts bogus type In-Reply-To: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> References: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> Message-ID: <061.e43ca5dea4be0c37a150fedae50c4392@haskell.org> #16287: :kind accepts bogus type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's an even simpler example: {{{ λ> data T :: (Type -> Type) -> Type λ> type F a = a λ> :k T F T F :: * }}} I'm very surprised that `TcValidity` doesn't catch this. Now that I look closer, [https://gitlab.haskell.org/ghc/ghc/blob/406e43af2f12756c80d583b86326f760f2f584cc/compiler/typecheck/TcValidity.hs#L604-608 here's why]: {{{#!hs check_type ve ty@(TyConApp tc tys) | isTypeSynonymTyCon tc || isTypeFamilyTyCon tc = check_syn_tc_app ve ty tc tys | isUnboxedTupleTyCon tc = check_ubx_tuple ve ty tys | otherwise = mapM_ (check_arg_type ve) tys }}} If `T` were a type synonym, then we'd call `check_syn_tc_app`, which would reject the unsaturated `F` argument. But since `T` isn't a type synonym, we instead go down a different code path (`check_arg_type`), which doesn't catch this. FWIW, [https://gitlab.haskell.org/ghc/ghc/blob/406e43af2f12756c80d583b86326f760f2f584cc/compiler/typecheck/TcValidity.hs#L716-723 this] is all that `check_syn_tc_app` does to ensure that unsaturated arguments are rejected: {{{#!hs arg_ctxt :: UserTypeCtxt arg_ctxt | GhciCtxt _ <- ctxt = GhciCtxt False -- When checking an argument, set the field of GhciCtxt to False to -- indicate that we are no longer in an outermost position (and thus -- unsaturated synonyms are no longer allowed). -- See Note [Unsaturated type synonyms in GHCi] | otherwise = ctxt }}} Perhaps we should just use this logic in `check_arg_type` as well? I think that would catch the program in this ticket without too much fuss. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 11:38:56 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 11:38:56 -0000 Subject: [GHC] #16286: Continuations are not labelled in the binaries even with -g3 In-Reply-To: <043.f64277feb071d6e3883ca3887adc23a1@haskell.org> References: <043.f64277feb071d6e3883ca3887adc23a1@haskell.org> Message-ID: <058.360d068f1a4873ab67d1e8f0480bbf80@haskell.org> #16286: Continuations are not labelled in the binaries even with -g3 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I _think_ this is because those symbols are not marked as `.globl` because they're not supposed to be referenced by other object files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 11:42:31 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 11:42:31 -0000 Subject: [GHC] #16286: Continuations are not labelled in the binaries even with -g3 In-Reply-To: <043.f64277feb071d6e3883ca3887adc23a1@haskell.org> References: <043.f64277feb071d6e3883ca3887adc23a1@haskell.org> Message-ID: <058.fec893b011740337b2950130fe71d999@haskell.org> #16286: Continuations are not labelled in the binaries even with -g3 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Maybe not. `r1Al_info` is defined like this {{{ .section .text .align 8 .align 8 .loc 1 16 18 .quad 0 .long 21 .long .Lu1NS_srt-(.Lr1Al_info)+0 .Lr1Al_info: ... }}} This is also not `.globl`, but I can see it in gdb. I think because of this {{{ .L.Lr1Al_info_die: .byte 2 .asciz "main" .asciz "r1Al_info" .byte 0 .quad .Lr1Al_info .quad .L.Lr1Al_info_end .byte 1 .byte 156 }}} So maybe we need something like this for `r1Al_closure` ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 11:45:26 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 11:45:26 -0000 Subject: [GHC] #16287: :kind accepts bogus type In-Reply-To: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> References: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> Message-ID: <061.0ec66d88a704da0fc82788fc49e91f7d@haskell.org> #16287: :kind accepts bogus type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Perhaps we should just use this logic in check_arg_type as well? Yes, that looks plausible. Moreover, `check_arg_type` is called from `check_syn_tc_app`, so maybe we can ''only'' do it in `check_arg_type`? (But there is one patch from `check_syn_tc_app` direct to `check_type`, bypassing `check_arg_type` for reasons that are not clear to me. If it could go to `check_arg_type` we'd be golden. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 11:55:13 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 11:55:13 -0000 Subject: [GHC] #16287: :kind accepts bogus type In-Reply-To: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> References: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> Message-ID: <061.eb4aa3f80c26971bcf8b25164efaded1@haskell.org> #16287: :kind accepts bogus type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): From a quick glance, I would guess that the only reason for `check_syn_tc_app` calling `check_type` instead of `check_arg_type` is due to `LiberalTypeSynonyms`. For instance, consider this (where `T` is a type synonym) {{{ λ> :set -XLiberalTypeSynonyms -XRankNTypes λ> type T a = a λ> :k T (forall a. a) }}} If you check `T`'s argument with `check_type` (as `check_syn_tc_app` does currently), then this will be accepted. If you check it with `check_arg_type`, however, it will be rejected: {{{ Illegal polymorphic type: forall a. a GHC doesn't yet support impredicative polymorphism }}} The difference amounts to whether you set `ve_rank` to `synArgMonoType` (as `check_syn_tc_app` does before invoking `check_type`) or `tyConArgMonoType` (as `check_arg_type` does). Perhaps we can tweak `check_arg_type` so that it knows when to use `synArgMonoType`—it might be as simple as passing an extra `Bool` argument to `check_arg_type` indicating whether this is the argument to a type synonym or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 12:46:19 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 12:46:19 -0000 Subject: [GHC] #16286: Continuations are not labelled in the binaries even with -g3 In-Reply-To: <043.f64277feb071d6e3883ca3887adc23a1@haskell.org> References: <043.f64277feb071d6e3883ca3887adc23a1@haskell.org> Message-ID: <058.8de2e02936d2268bb1b2a0116964a2d8@haskell.org> #16286: Continuations are not labelled in the binaries even with -g3 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): It seems like we only generate debug info for `CmmProc`s currently, ignoring `CmmData`. I don't know if this is because of a limitation of DWARF, or because no one needed this before. @bgamari, any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 14:12:58 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 14:12:58 -0000 Subject: [GHC] #16287: :kind accepts bogus type In-Reply-To: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> References: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> Message-ID: <061.c7c3126288146fbc0d4f1bcd469d8126@haskell.org> #16287: :kind accepts bogus type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/293 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/293 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 14:45:24 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 14:45:24 -0000 Subject: [GHC] #12149: Support bit-fields In-Reply-To: <056.8fdc47dd2500be4c213091e5e27ef27a@haskell.org> References: <056.8fdc47dd2500be4c213091e5e27ef27a@haskell.org> Message-ID: <071.3510a44d73e8db61d7f7937cf0196a52@haskell.org> #12149: Support bit-fields -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: bit-fields Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): This just bit me as well. On linux, `iphdr` has a bit field, and I'm struggling to find a good way to peek and poke at these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 16:01:59 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 16:01:59 -0000 Subject: [GHC] #16178: Brackets and splices should be overloaded like the static keyword In-Reply-To: <049.0449c89fd5b736cdd820699f1957751a@haskell.org> References: <049.0449c89fd5b736cdd820699f1957751a@haskell.org> Message-ID: <064.a05ee4318aa46f517657cfd36ab21090@haskell.org> #16178: Brackets and splices should be overloaded like the static keyword -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This seems like something which should go through the normal proposals process... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 17:25:28 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 17:25:28 -0000 Subject: [GHC] #16286: Continuations are not labelled in the binaries even with -g3 In-Reply-To: <043.f64277feb071d6e3883ca3887adc23a1@haskell.org> References: <043.f64277feb071d6e3883ca3887adc23a1@haskell.org> Message-ID: <058.c52a46d9b1deb191ecd595ebf45aa2ff@haskell.org> #16286: Continuations are not labelled in the binaries even with -g3 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I seem to recall that there was a relevant hack in Phab:D4713 which might compromise symbol generation of info tables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 17:32:05 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 17:32:05 -0000 Subject: [GHC] #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId Message-ID: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: 15840 | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the following three modules causes a Core Lint error in HEAD. (This does not happen in 8.6 - the Lint check was introduced later.) To reproduce: save the three files in `Repro/` directory and use `ghc- stage2 -dcore-lint -O Repro/B.hs`. The reproduction code is minimized version of code from cabal and prettyprint libraries. A.hs {{{ #!haskell module Repro.A where import Repro.C data License class Pretty a where pretty :: a -> Doc instance Pretty License where pretty _ = pretV bar :: (Pretty a) => a -> Doc bar w = foo (pretty (u w w w w)) u :: a -> a -> a -> a -> a u = u }}} B.hs {{{ #!haskell module Repro.B where import Repro.A import Repro.C bar2 :: License -> Doc bar2 = bar }}} C.hs {{{ #!haskell module Repro.C where data Doc = Empty | Beside Doc hcat :: Doc -> Doc hcat Empty = Empty hcat xs = hcat xs pretV = hcat Empty foo :: Doc -> Doc foo Empty = hcat Empty foo val = Beside val }}} The error: {{{ *** Core Lint errors : in result of Simplifier *** Repro/C.hs:9:1: warning: [in body of letrec with binders pretV_r3 :: Doc] Occurrence is GlobalId, but binding is LocalId pretV :: Doc [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}] *** Offending Program *** lvl_s1kN :: Doc [LclId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=True, Expandable=False, Guidance=IF_ARGS [] 30 20}] lvl_s1kN = case pretV of wild_Xd { Empty -> pretV; Beside ipv_s105 -> Beside wild_Xd } $sbar_s1kL [InlPrag=NOUSERINLINE[2]] :: License -> Doc [LclId, Arity=1, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True) Tmpl= \ _ [Occ=Dead] -> case pretV of wild_Xd [Occ=Once*] { Empty -> let { pretV_r3 :: Doc [LclId] pretV_r3 = wild_Xd } in pretV; Beside _ [Occ=Dead] -> Beside wild_Xd }}] $sbar_s1kL = \ _ [Occ=Dead] -> lvl_s1kN $trModule_s1kE :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 0}] $trModule_s1kE = "main"# $trModule_s1kF :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $trModule_s1kF = TrNameS $trModule_s1kE $trModule_s1kG :: Addr# [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 0}] $trModule_s1kG = "Repro.B"# $trModule_s1kH :: TrName [LclId, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 20}] $trModule_s1kH = TrNameS $trModule_s1kG $trModule :: Module [LclIdX, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 10 30}] $trModule = Module $trModule_s1kF $trModule_s1kH bar2 :: License -> Doc [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 30 20}] bar2 = \ _ [Occ=Dead] -> case pretV of wild_Xd { Empty -> pretV; Beside ipv_s105 -> Beside wild_Xd } *** End of Offense *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 18:55:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 18:55:50 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.e93ee0a46d09fe6b45a43a598853d1e5@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: gadt/T15558 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think we need an `impossible` that has a type like `Absurdity => a`, where `Absurdity` is a special constraint that the type checker can satisfy only when an absurdity is in the context (that is, in inaccessible code). If an absurdity is used to prove `Absurdity`, then the "inaccessible code" warning is squelched. This would need custom support for the `Absurdity` prover, but I don't actually think it would be all that hard. I'm not sure what the Core evidence would look like. Perhaps we need `contra`, tucked without comment in the appendix of the [https://repository.brynmawr.edu/cgi/viewcontent.cgi?referer=&httpsredir=1&article=1010&context=compsci_pubs Coercible paper]. The `contra` there is to allow us to assert that `case` matches are total. GHC's Core, though, doesn't require `case` to be total, meaning that this has never been implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 19:30:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 19:30:50 -0000 Subject: [GHC] #16281: PatternSynonyms doesn't accept non-prenex quantified functions, doesn't float foralls In-Reply-To: <051.bf999c3bd41c3e4737fb5cffccc82bdc@haskell.org> References: <051.bf999c3bd41c3e4737fb5cffccc82bdc@haskell.org> Message-ID: <066.83d192283ca47175280f586644e29237@haskell.org> #16281: PatternSynonyms doesn't accept non-prenex quantified functions, doesn't float foralls -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 goldfire): The problem is that the thing after the `::` in `pattern Blah ::` is not a type. It's a type-like thing, with requireds, universals, provideds, existentials, arguments, and a result, all arranged using familiar notation. Perhaps someday, we'll generalize this, allowing type variables to appear in arbitrary positions within the type (maybe someone wants an existential ''before'' a universal, for example), but this is a largish design problem. I'm inclined to "wontfix" for this one, leaving it for a ghc-proposal to flesh out all the details of the new design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 19:31:01 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 19:31:01 -0000 Subject: [GHC] #16281: PatternSynonyms doesn't accept non-prenex quantified functions, doesn't float foralls In-Reply-To: <051.bf999c3bd41c3e4737fb5cffccc82bdc@haskell.org> References: <051.bf999c3bd41c3e4737fb5cffccc82bdc@haskell.org> Message-ID: <066.7edb03a427d2052e0c53ef61af540980@haskell.org> #16281: PatternSynonyms doesn't accept non-prenex quantified functions, doesn't float foralls -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: wontfix | 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 goldfire): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 19:46:41 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 19:46:41 -0000 Subject: [GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType In-Reply-To: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> References: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> Message-ID: <057.386ebe273b5f5660d1a199d58a5102ca@haskell.org> #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): I am about to add some error handling to the "Network.Socket" library to deal with MacOS failing socket shutdown after EOF. MacOS returns EINVAL, which maps to 'InvalidArgument', which is similarly not available. And since some other systems, or a later MacOS may return ENOTCONN which would become 'ResourceVanished', I'd like to second the request to expose the full set of GHC Error types: {{{ -- GHC only: | UnsatisfiedConstraints | SystemError | ProtocolError | OtherError | InvalidArgument | InappropriateType | HardwareFault | UnsupportedOperation | TimeExpired | ResourceVanished | Interrupted }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 20:27:17 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 20:27:17 -0000 Subject: [GHC] #16269: Postfix operator precedence In-Reply-To: <045.86b73bdf13b4e3c727058e8cec5f9492@haskell.org> References: <045.86b73bdf13b4e3c727058e8cec5f9492@haskell.org> Message-ID: <060.aae8d3638292a670b482c2d44aa4ecfd@haskell.org> #16269: Postfix operator precedence -------------------------------------+------------------------------------- Reporter: anuyts | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (Parser) | Keywords: fixity Resolution: wontfix | PostfixOperators Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: Thanks for posting. Changes to the language supported by GHC should go through the [https://github.com/ghc-proposals/ghc-proposals ghc-proposals] process -- even for small changes like this. Until the proposal is accepted, I will label this ticket as "wontfix". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 22:13:35 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 22:13:35 -0000 Subject: [GHC] #16289: GHC thinks pattern match is exhaustive Message-ID: <046.eab88b2b678daa30e299a6ea262d8ca5@haskell.org> #16289: GHC thinks pattern match is exhaustive -------------------------------------+------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{ {-# OPTIONS_GHC -Werror #-} module Lib where data Value = Finite Integer | Infinity deriving (Eq) instance Num Value where (+) = undefined (*) = undefined abs = undefined signum = undefined negate = undefined fromInteger = Finite isSpecial :: Value -> Bool isSpecial Infinity = True isSpecial 0 = True isSpecial 1 = True isSpecial _ = False }}} {{{ > ghc Lib.hs [1 of 1] Compiling Lib ( Lib.hs, Lib.o ) Lib.hs:19:1: error: [-Woverlapping-patterns, -Werror=overlapping-patterns] Pattern match is redundant In an equation for ‘isSpecial’: isSpecial 1 = ... | 19 | isSpecial 1 = True | ^^^^^^^^^^^^^^^^^^^^^^^^^ Lib.hs:20:1: error: [-Woverlapping-patterns, -Werror=overlapping-patterns] Pattern match is redundant In an equation for ‘isSpecial’: isSpecial _ = ... | 20 | isSpecial _ = False | ^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 22:36:06 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 22:36:06 -0000 Subject: [GHC] #16134: Continuous integration on FreeBSD In-Reply-To: <046.b2a55914acf04c2c193458d381cf5eee@haskell.org> References: <046.b2a55914acf04c2c193458d381cf5eee@haskell.org> Message-ID: <061.4bebd2e8c84fd3bec30abe64b733c4ca@haskell.org> #16134: Continuous integration on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 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): There was a relevant talk at FOSDEM this year: https://fosdem.org/2019/schedule/event/freebsd_ci_cd_environment/. [[https://github.com/pizzamig/pot|pot]] might be worth investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 5 22:42:21 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Feb 2019 22:42:21 -0000 Subject: [GHC] #16290: Export `noinline` function from `GHC.Exts` Message-ID: <055.51507d72cb8074b699db23fe1ab86afd@haskell.org> #16290: Export `noinline` function from `GHC.Exts` -------------------------------------+------------------------------------- Reporter: Ptharien's | Owner: (none) Flame | Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 libraries/base | Keywords: noinline | 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 other `id`s-with-special-behavior `inline`, `lazy`, and `oneShot` that are declared in `GHC.Magic` are re-exported from `GHC.Exts` (and thus made user-accessible), but `noinline` isn’t. This seems like an oversight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 01:01:12 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 01:01:12 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.1c0728c3dcf2f4321b63570453c3bc05@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579{a,b} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264, | Phab:D5229, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/261 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: deriving/should_compile/T14579{a} => deriving/should_compile/T14579{a,b} * status: patch => closed * resolution: => fixed Comment: This was finally fixed in [https://gitlab.haskell.org/ghc/ghc/commit/e88e083d62389d5c8d082a25395a3d933ab2f03b e88e083d62389d5c8d082a25395a3d933ab2f03b]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 02:18:47 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 02:18:47 -0000 Subject: [GHC] #16289: GHC thinks pattern match is exhaustive In-Reply-To: <046.eab88b2b678daa30e299a6ea262d8ca5@haskell.org> References: <046.eab88b2b678daa30e299a6ea262d8ca5@haskell.org> Message-ID: <061.0503999065d9c4495be4f0a70f922ccf@haskell.org> #16289: GHC thinks pattern match is exhaustive -------------------------------------+------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * priority: normal => high Comment: That's pretty frightening. I'm bumping priority, but anyone can feel free to disagree with that judgment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 03:25:34 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 03:25:34 -0000 Subject: [GHC] #16146: Trivial partial type signature kills type inference in the presence of GADTs In-Reply-To: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> References: <047.1d5b12b1404ea81ff746511f96b1244d@haskell.org> Message-ID: <062.58a09ada8d4e2cde71475985087071fa@haskell.org> #16146: Trivial partial type signature kills type inference in the presence of GADTs -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The thoughts on this ticket have led to https://github.com/ghc-proposals /ghc-proposals/pull/194 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 05:37:01 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 05:37:01 -0000 Subject: [GHC] #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled In-Reply-To: <043.bd7f9da23904789b86411de4cb766153@haskell.org> References: <043.bd7f9da23904789b86411de4cb766153@haskell.org> Message-ID: <058.5aefc27e8dd729ed67b467cb083083ab@haskell.org> #15897: Negative MUT time in +RTS -s -RTS when heap profiling is enabled -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Profiling | Version: 8.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): The failures are due to test timing out on CI because it takes too long sometimes. I'll try to find a smaller test case. I think I've never tried making the input smaller, maybe that still reproduces the bug. I should try that first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 06:16:00 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 06:16:00 -0000 Subject: [GHC] #16291: Document or enable commented-out sanity check in checkStackChunk Message-ID: <043.e6a97c4834ec429c76fd9907c1aec308@haskell.org> #16291: Document or enable commented-out sanity check in checkStackChunk -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `checkStackChunk` is currently defined like this: {{{ void checkStackChunk( StgPtr sp, StgPtr stack_end ) { StgPtr p; p = sp; while (p < stack_end) { p += checkStackFrame( p ); } // ASSERT( p == stack_end ); -- HWL } }}} The commented-out assertion makes perfect sense to me, but I can't enable it (causes test failures), and it's not documented why it should not be enabled. I think this catches a bug that needs to be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 06:16:49 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 06:16:49 -0000 Subject: [GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType In-Reply-To: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> References: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> Message-ID: <057.30a4833639f14e6716c4d4bad02116dc@haskell.org> #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vdukhovni): * Attachment "Errno.hsc" added. Potential errno interface -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 06:18:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 06:18:03 -0000 Subject: [GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType In-Reply-To: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> References: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> Message-ID: <057.ebb022897dfd87b50cbd9558ae68becf@haskell.org> #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): In addition, it would be really cool if the "ioe_errno" value were accessible, at least as a number so it could be logged. While the associated C macro names are not all available on every platform, and any mapping to symbolic Haskell names would be unavoidably incomplete, a more ambitious interface might define any missing macros (that are common enough on most platforms to be supported) to 0 on platforms that lack that macro, and then a newtype + a set of PatternSynonyms would provide a usable Enum-like interface. As in the "Errno.hsc" example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 06:23:15 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 06:23:15 -0000 Subject: [GHC] #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM In-Reply-To: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> References: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> Message-ID: <061.d71cae5e7b2000108aaa43d364717b61@haskell.org> #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (LLVM) | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Data point: another spontaneous pass https://gitlab.haskell.org/ghc/ghc/-/jobs/22691 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 06:23:31 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 06:23:31 -0000 Subject: [GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType In-Reply-To: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> References: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> Message-ID: <057.5dbb7eb191b0d6c50621da815b32db13@haskell.org> #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): Example Errno.hsc usages: {{{ $ ghci Errno.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling System.IO.Errno ( Errno.hs, interpreted ) Ok, one module loaded. *System.IO.Errno> show EPERM "Operation not permitted" *System.IO.Errno> show $ IOErrno 0 "No error: 0" *System.IO.Errno> show $ IOErrno 1000 "Unknown error: 1000" *System.IO.Errno> strerror $ IOErrno 0 Just "No error: 0" *System.IO.Errno> strerror $ IOErrno 1000 Nothing *System.IO.Errno> fromEnum EPERM 1 *System.IO.Errno> toEnum 5 :: IOErrno Input/output error *System.IO.Errno> case toEnum 1 of { EPERM -> True; _ -> False } True }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 08:29:58 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 08:29:58 -0000 Subject: [GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType In-Reply-To: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> References: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> Message-ID: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vdukhovni): * Attachment "Errno.hsc" removed. Potential errno interface -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 08:29:58 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 08:29:58 -0000 Subject: [GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType In-Reply-To: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> References: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> Message-ID: <057.ff8e8ec00d90dfc34fe9500a307a2f37@haskell.org> #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vdukhovni): * Attachment "Errno.hsc" added. Potential errno interface -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 09:22:56 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 09:22:56 -0000 Subject: [GHC] #16292: Wildcards in visible kind application Message-ID: <046.ddc84da258cfa15ad418574f23cf29ff@haskell.org> #16292: Wildcards in visible kind application -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- `TcHsType.tcInferApps` contains this terrible code {{{ ; ki_arg <- addErrCtxt (funAppCtxt orig_hs_ty hs_ki_arg n) $ unsetWOptM Opt_WarnPartialTypeSignatures $ setXOptM LangExt.PartialTypeSignatures $ -- Urgh! see Note [Wildcards in visible kind application] -- ToDo: must kill this ridiculous messing with DynFlags }}} It's a knock-on from the Visible Kind Application patch -- see the Note referred to above. But it's ghastly and we must fix it. There's a [https://github.com/ghc- proposals/ghc-proposals/pull/194 GHC Proposal about this], but it's relatively ambitious. Maybe there is a shorter term thing we can do here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 09:56:44 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 09:56:44 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.3cb3ad36792335619f4615fd6a0e78b4@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I propose to fix this by making `mkCastTy` use `isReflCo` rather than `isReflexiveCo`. That way it will get rid of simple reflexive casts produced by the unifier, but will not remove compound `ty ~ ty` casts. That will happen in `OptCoercion`. This is a bit more efficient (less `tcEqType`) and it comopletely avoids this horrible constraint/type choice, meaning that `substTy`, `mkCastTy` and `mkAppTy` can all be used both by Core and by the type checker. Richard: do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 10:28:36 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 10:28:36 -0000 Subject: [GHC] #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> References: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> Message-ID: <062.4ab652603dd14992fc7c83fabf665c96@haskell.org> #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: 15840 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by aspiwack): My understanding is that the issue occurs in this subexpression {{{#!haskell let { pretV_r3 :: Doc [LclId] pretV_r3 = wild_Xd } in pretV; }}} The two `pretV` are displayed differently but have actually the same `Unique` (they differ by there locality tag though). What I think happened here is that the simplifier saw an expression of the form {{{#!haskell case u of x { pat -> rhs } }}} And decided to rewrite it to {{{#!haskell case u of x { pat -> let u = x in rhs } }}} Where the new `u` has the same unique as the other `u`, so as to shadow it, and avoid pushing a substitution through. Fair enough. Now the problem is that the new `u` is, as expected, a `LclId`. However, the ''original'' `u` happened to be a `GblId`, hence so are all the occurrences of `u` in the `rhs`! Now, I'm not sure what the appropriate solution is, here. Don't perform this transformation when the scrutinee is a global identifier? Or something more elaborate. As a matter of fact, I haven't been able to locate the part of the simplifier which does this transformation. This is a blocker for #15840. Which happened to reveal this issue in a very particular set of circumstances (involving the latest version of cabal), where it breaks core-lint when building the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 11:27:47 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 11:27:47 -0000 Subject: [GHC] #16106: Remove PowerPC OS X (Darwin) support In-Reply-To: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> References: <047.9f4ba098b7509c8233449daeede12bae@haskell.org> Message-ID: <062.b68a2663c9b1e6a0b94218481bffdf75@haskell.org> #16106: Remove PowerPC OS X (Darwin) support -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: powerpc Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/63 -------------------------------------+------------------------------------- Changes (by trommler): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 11:32:19 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 11:32:19 -0000 Subject: [GHC] #13633: testwsdeque failure on POWER8 In-Reply-To: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> References: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> Message-ID: <062.d76a83d7695907340bd9e7d06de06738@haskell.org> #13633: testwsdeque failure on POWER8 -----------------------------------+--------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: SMP Operating System: Linux | Architecture: powerpc64 Type of failure: Runtime crash | Test Case: rts/testwsdeque Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+--------------------------------------- Comment (by trommler): Test `testwsdeque` always fails on POWER9 under load. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 13:19:17 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 13:19:17 -0000 Subject: [GHC] #16293: Inconsistencies and oddities of Proxy# Message-ID: <050.2f25f16e44a73b8047b8a62971a2da19@haskell.org> #16293: Inconsistencies and oddities of Proxy# -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The `Proxy#` type has some downright strange properties that border on being bugs. Here are some of examples that I've discovered: 1. `Proxy#`, when reified with TH, gives a different arity that most other primitive type constructors: {{{ λ> putStrLn $(reify ''Proxy# >>= stringE . show) PrimTyConI GHC.Prim.Proxy# 2 True }}} If this is to be believed, `Proxy#` has 2 arguments. But shouldn't that be 1? Compare this to the results of reifying `(->)`: {{{ λ> putStrLn $(reify ''(->) >>= stringE . show) PrimTyConI GHC.Prim.-> 2 False }}} This correctly claims that it has 2 arguments. Moreover, since `(->)` actually has two invisible `RuntimeRep` arguments, this shows that `(->)` is deliberately not counting them as arguments for `PrimTyConI`'s purposes. It's just `Proxy#` that seems to count its kind argument towards its total. 2. `Proxy#` is nominally roled in its argument! That is to say, the following program typechecks: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} import Data.Proxy class C a where metaData :: Proxy a -> Int instance C Int where metaData _ = 432432 newtype Age = MkAge Int deriving C }}} But the this one does not! {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE MagicHash #-} import GHC.Exts class C a where metaData :: Proxy# a -> Int instance C Int where metaData _ = 432432 newtype Age = MkAge Int deriving C }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:10:34: error: • Couldn't match type ‘Int’ with ‘Age’ arising from the coercion of the method ‘metaData’ from type ‘Proxy# Int -> Int’ to type ‘Proxy# Age -> Int’ • When deriving the instance for (C Age) | 10 | newtype Age = MkAge Int deriving C | ^ }}} If `Proxy` is phantom-roled in its argument, then it feels like `Proxy#` out to be as well. 3. The types of `proxy#` and `Proxy` (the constructor) are subtly different. Compare: {{{ λ> :type +v proxy# proxy# :: forall k0 (a :: k0). Proxy# a λ> :type +v Proxy Proxy :: forall {k} (t :: k). Proxy t }}} Notice that `proxy#` accepts //two// visible type arguments, whereas `Proxy` only accepts one! This means that you'd have to write `proxy# @_ @Int`, as opposed to the shorter `Proxy @Int`. I feel like `proxy#` and `Proxy`'s types ought to mirror each other in this respect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 14:15:57 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 14:15:57 -0000 Subject: [GHC] #16294: Code generation corrupts writes to Addr# Message-ID: <049.f6a36fca2d6c2abd3bd064af67f0a8e1@haskell.org> #16294: Code generation corrupts writes to Addr# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This issue affects at least GHC 8.4.4 and GHC 8.6.3. Here is a somewhat minimal example: {{{#!hs {-# language BangPatterns #-} {-# language MagicHash #-} {-# language UnboxedTuples #-} {-# options_ghc -Wall -Werror -O2 #-} import Data.Primitive import Data.Void import Data.Word import Data.Monoid import GHC.IO (IO(..)) import Foreign.Storable import Numeric (showHex) import qualified GHC.Exts as E import qualified Data.Primitive as PM main :: IO () main = do arr <- compute 0xABCD 0x79 putStrLn (showString "raw packet: " . appEndo (foldMap (Endo . showHex) (E.toList arr)) $ "") compute :: Word16 -> Word8 -> IO ByteArray compute totlen prot = do buf <- PM.newPinnedByteArray 28 PM.setByteArray buf 0 28 (0 :: Word8) let !(Addr addr) = PM.mutableByteArrayContents buf !ptr = E.Ptr addr :: E.Ptr Void pokeByteOff ptr 0 (0x45 :: Word8) pokeByteOff ptr 1 (0 :: Word8) pokeByteOff ptr 2 (totlen :: Word16) pokeByteOff ptr 4 (0 :: Word16) pokeByteOff ptr 6 (0 :: Word16) pokeByteOff ptr 8 (0x40 :: Word8) pokeByteOff ptr 9 (prot :: Word8) touchMutableByteArray buf PM.unsafeFreezeByteArray buf touchMutableByteArray :: MutableByteArray E.RealWorld -> IO () touchMutableByteArray (MutableByteArray x) = touchMutableByteArray# x touchMutableByteArray# :: E.MutableByteArray# E.RealWorld -> IO () touchMutableByteArray# x = IO $ \s -> case E.touch# x s of s' -> (# s', () #) }}} For those curious about the particular interleaving of 8-bit and 16-bit writes, this was adapted from code that fills out an `iphdr` for use with raw sockets. The output will be dependent on your platform's endianness. On my little-endian architecture, I get: {{{ raw packet: 450cdab00004079000000000000000000 }}} As we expect, the `abcd` from the source gets flipped to `cdab` because of the little endian architecture this ran on. However, it starts in an unusual place. It's not even byte-aligned. Something, possible a cmm optimization or a codegen optimization, makes the `writeWord16OffAddr#` end up straddling three bytes. Someone will probably want to write a more minimal example that eliminates the use of the `primitive` library. Sorry to be the bearer of bad news :( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 15:45:13 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 15:45:13 -0000 Subject: [GHC] #16289: GHC thinks pattern match is exhaustive In-Reply-To: <046.eab88b2b678daa30e299a6ea262d8ca5@haskell.org> References: <046.eab88b2b678daa30e299a6ea262d8ca5@haskell.org> Message-ID: <061.ea4aac8a1ee7dfba8bd1d84f2effbe0e@haskell.org> #16289: GHC thinks pattern match is exhaustive -------------------------------------+------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 16:01:25 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 16:01:25 -0000 Subject: [GHC] #16294: Code generation corrupts writes to Addr# In-Reply-To: <049.f6a36fca2d6c2abd3bd064af67f0a8e1@haskell.org> References: <049.f6a36fca2d6c2abd3bd064af67f0a8e1@haskell.org> Message-ID: <064.76b4163e476f80d391db43048cae5587@haskell.org> #16294: Code generation corrupts writes to Addr# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): The good news is that it seems to me that it's only because `showHex` prints a single digit when you expect two. Can you try replacing it with `printf "%.2x"`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 16:12:11 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 16:12:11 -0000 Subject: [GHC] #16294: Code generation corrupts writes to Addr# In-Reply-To: <049.f6a36fca2d6c2abd3bd064af67f0a8e1@haskell.org> References: <049.f6a36fca2d6c2abd3bd064af67f0a8e1@haskell.org> Message-ID: <064.d566e523c8e4b7825de36a73bc0e90bd@haskell.org> #16294: Code generation corrupts writes to Addr# -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: Component: Compiler | Version: 8.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by andrewthad): * status: new => closed * resolution: => invalid Comment: I'll be darned. That solves it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 16:39:39 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 16:39:39 -0000 Subject: [GHC] #16264: Install reqlib'd libraries during CI In-Reply-To: <046.782847618c93060689478051686a30cf@haskell.org> References: <046.782847618c93060689478051686a30cf@haskell.org> Message-ID: <061.3c19a07173f32c4f51dd6025f46124b9@haskell.org> #16264: Install reqlib'd libraries during CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 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): Also see some discussionon https://gitlab.haskell.org/ghc/ghc/merge_requests/291 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 16:46:59 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 16:46:59 -0000 Subject: [GHC] #16264: Install reqlib'd libraries during CI In-Reply-To: <046.782847618c93060689478051686a30cf@haskell.org> References: <046.782847618c93060689478051686a30cf@haskell.org> Message-ID: <061.f68e258bf233ace2f074a4a1915038c5@haskell.org> #16264: Install reqlib'd libraries during CI -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 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 harpocrates): * cc: harpocrates (added) Comment: Could we put this logic somewhere in Hadrian? It would be nice to be able to use the same logic locally too. Also, has worked on this started yet (asking to see if maybe I should just go for it)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 16:56:21 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 16:56:21 -0000 Subject: [GHC] #16287: :kind accepts bogus type In-Reply-To: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> References: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> Message-ID: <061.385945e69c0d0870c5e6d163a1ded238@haskell.org> #16287: :kind accepts bogus type -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_fail/T16287 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/293 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => ghci/should_fail/T16287 * status: patch => merge * milestone: => 8.8.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/c07e7ecbdfc05429fb6ce84c547c0365d2754db7 c07e7ecb]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 17:31:42 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 17:31:42 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.9b25eb1bb3455a8a6652239a3d82f2e6@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think that's problematic. See the comments around that use of `isReflexiveCo`. Perhaps there is a way to avoid it, but there is a good principled reason around the use of the slower function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 18:18:26 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 18:18:26 -0000 Subject: [GHC] #16271: Building stage1:lib:text target is not robust In-Reply-To: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> References: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> Message-ID: <064.4cc156313067cbf32b275e1eb0807867@haskell.org> #16271: Building stage1:lib:text target is not robust -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: snowleopard (added) Comment: I am currently looking into this in the context of enabling cached Hadrian builds using Shake's caching feature. For caching to work, we need to accurately record all dependencies or at least to report all files produced withing each rule by using `produces` function: http://hackage.haskell.org/package/shake/docs/Development- Shake.html#v:produces I'll report back when I have a working cached build, which should bring us closer to fixing this issue too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 18:25:40 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 18:25:40 -0000 Subject: [GHC] #16271: Building stage1:lib:text target is not robust In-Reply-To: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> References: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> Message-ID: <064.f548657647058e606a7f2a9c5597d9b5@haskell.org> #16271: Building stage1:lib:text target is not robust -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Thanks Andrey, could you perhaps make a ticket to track this? #16272 is related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 18:42:38 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 18:42:38 -0000 Subject: [GHC] #16295: Enable cached builds with Hadrian Message-ID: <050.90024ab429dfe175278d9c32201a7dda@haskell.org> #16295: Enable cached builds with Hadrian -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As Neil is working on turning Shake into Cloud Shake [1], Shake has got a new feature of "locally cached builds", making it possible to reuse build artefacts from previous builds on the same machine. This means, in particular, that a clean build could be finished very quickly if you've built GHC before from the same/similar sources. Hopefully, this could also help us speed up GHC's CI some day. To enable cached builds, it is important to find and fix all instances of untracked dependencies in Hadrian, or at least record them using the `produces` feature of Shake [2], because otherwise Shake has no idea that these files are actually needed and should therefore be stored in the cache. Here are a couple of tickets related to untracked dependencies: https://ghc.haskell.org/trac/ghc/ticket/16271 https://ghc.haskell.org/trac/ghc/ticket/16272 I am currently working this and hope to produce a patch soon. [1] See the Build Systems à la Carte paper: https://dl.acm.org/ft_gateway.cfm?id=3236774 [2] http://hackage.haskell.org/package/shake/docs/Development- Shake.html#v:produces -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 18:43:43 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 18:43:43 -0000 Subject: [GHC] #16271: Building stage1:lib:text target is not robust In-Reply-To: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> References: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> Message-ID: <064.3045d86c387bdd30bff2c72fac572cfa@haskell.org> #16271: Building stage1:lib:text target is not robust -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Sure, done: https://ghc.haskell.org/trac/ghc/ticket/16295. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 18:46:25 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 18:46:25 -0000 Subject: [GHC] #16295: Enable cached builds with Hadrian In-Reply-To: <050.90024ab429dfe175278d9c32201a7dda@haskell.org> References: <050.90024ab429dfe175278d9c32201a7dda@haskell.org> Message-ID: <065.1391be48a1fc83a9d6744e69f6b4e940@haskell.org> #16295: Enable cached builds with Hadrian -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by snowleopard: Old description: > As Neil is working on turning Shake into Cloud Shake [1], Shake has got a > new feature of "locally cached builds", making it possible to reuse build > artefacts from previous builds on the same machine. This means, in > particular, that a clean build could be finished very quickly if you've > built GHC before from the same/similar sources. Hopefully, this could > also help us speed up GHC's CI some day. > > To enable cached builds, it is important to find and fix all instances of > untracked dependencies in Hadrian, or at least record them using the > `produces` feature of Shake [2], because otherwise Shake has no idea that > these files are actually needed and should therefore be stored in the > cache. Here are a couple of tickets related to untracked dependencies: > > https://ghc.haskell.org/trac/ghc/ticket/16271 > https://ghc.haskell.org/trac/ghc/ticket/16272 > > I am currently working this and hope to produce a patch soon. > > [1] See the Build Systems à la Carte paper: > https://dl.acm.org/ft_gateway.cfm?id=3236774 > > [2] http://hackage.haskell.org/package/shake/docs/Development- > Shake.html#v:produces New description: As Neil is working on turning Shake into Cloud Shake [1], Shake has got a new feature of "locally cached builds", making it possible to reuse build artefacts from previous builds on the same machine. This means, in particular, that a clean build could be finished very quickly if you've built GHC before from the same/similar sources. Hopefully, this could also help us speed up GHC's CI some day. To enable cached builds, it is important to find and fix all instances of untracked dependencies in Hadrian, or at least record them using the `produces` feature of Shake [2], because otherwise Shake has no idea that these files are actually needed and should therefore be stored in the cache. Here are a couple of tickets related to untracked dependencies: https://ghc.haskell.org/trac/ghc/ticket/16271 https://ghc.haskell.org/trac/ghc/ticket/16272 I am currently working this and hope to produce a patch soon. I marked this is a "bug", not a "feature request", since untracked dependencies are bugs, and they prevent us from using Shake's shiny new feature. [1] See the Build Systems à la Carte paper: https://dl.acm.org/ft_gateway.cfm?id=3236774 [2] http://hackage.haskell.org/package/shake/docs/Development- Shake.html#v:produces -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 18:46:55 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 18:46:55 -0000 Subject: [GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType In-Reply-To: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> References: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> Message-ID: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vdukhovni): * Attachment "Errno.hsc" removed. Potential errno interface -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 18:46:55 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 18:46:55 -0000 Subject: [GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType In-Reply-To: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> References: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> Message-ID: <057.0891993cd9183b30b1de34c7e416b4b3@haskell.org> #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vdukhovni): * Attachment "Errno.hsc" added. Potential 'IOErrno' interface, with curated errors from FreeBSD 12, Linux and MacOS -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 19:56:13 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 19:56:13 -0000 Subject: [GHC] #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType In-Reply-To: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> References: <042.eb1cc133c5b1a8fac6a6fb09aaf9f414@haskell.org> Message-ID: <057.cd1f8f5d779c957d9708d64b309473a0@haskell.org> #14730: Missing predicate for "ResourceVanished" IOException/IOErrorType -------------------------------------+------------------------------------- Reporter: bit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): Also, perhaps the use of strerror(3) in "Foreign.C.Error" rather than strerror_r(3) is not entirely thread-safe under atypical conditions. If the kernel is newer than the C-library, it may return error numbers that lie outside the static string array used by strerror(3) and friends, and in that case, strerror(3) will use a static buffer to generate "Unknown error: ", but use of that buffer is not thread-safe. For this to be a problem, two threads have to encounter two different unknown to the C-library errors at essentially the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 22:43:11 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 22:43:11 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.e9953a5460c843409625202db07b23a6@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > See the comments around that use of isReflexiveCo. Which comments? I think you may be referring to `Note [Respecting definitional equality]` in `TyCoRep`. Anything else? Let me also note that * In GHC today we use `mkNakedCastTy` which absolutely does not remove the casts that the above `Note` says it should. * The typechecker is careful to push casts out of the way when solving equalities, which helps. But it still has lots of `tcSplitX` calls. > I think that's problematic. What do you suggest we do? As comment:3 shows, if we have `mkTcCastTy` we'll need `mkTcAppTy`. And `tcSubstTy` and `tcSubstTheta`. And `tcInstDFunType`. It's pretty hard to be sure that we've nailed all the places. Duplicating all this stuff doesn't smell right to me. Hmm. Currently `mkCastTy` will remove a cast between `Type` and `Coercion`, because the two are equal in Core. But such a cast would yield a typechecker error (which is what both #15799 and this ticket involve), so we'd never get as far as Core. How bad would it be if `mkCastTy` did not remove a cast between `Type` and `Coercion`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 23:28:01 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 23:28:01 -0000 Subject: [GHC] #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> References: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> Message-ID: <062.2468e85bf64b9412fa5f1b5c71058d15@haskell.org> #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: 15840 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I see what is happening. First, read `OccurAnal` * `Note [Binder swap]` * `Note [Binder swap on GlobalId scrutinees]`. (This case happens in the program concerned, with scrutinee `pretV`.) The trouble is that the binder-swap, done by the occurrence analyser, transforms {{{ case A.foo{r872} of bar { K x -> ...(A.foo{r872})... } ===> case A.foo{r872} of bar { K x -> let foo{r872} = bar in ...(A.foo{r872})... }}} where `A.foo{r872}` is a `GlobalId` with unique `r872`. In the binder- swap we make a `LocalId` for `foo{r872}` ''with the same unique'', which deliberately shadows the global binding. After the simplifer substitutes it out we'll get {{{ case A.foo{r872} of bar { K x -> ...(bar)... }}} which is what we want. Alas, the intermediate form does not satisfy Lint's rules, because a `GlobalId` occurrence is bound by a `LocalId` binding. Mostly this does not show up, because we run the simplifier before linting. But ''unfoldings'' are occurrence-analysed (so that they are all ready for inlining) so the linter sees the occurrence-analysed form and barfs. ----------- What to do? A quick fix is simply not to do the binder-swap when occurrence analysing unfoldings. Replace the calls to `occurAnalyseExpr` in `CoreUnfold` with `occurAnalyseExpr_NoBinderSwap`. But that just makes things yet a bit more complicated. An alternative, and I think nicer, solution is to make the occcurrence analyser do the binder-swap substitution as it goes. Instead of adding a let-binding (as now) and doing some fancy footwork to gather the right occurrence info (as now -- e.g. `occ_gbl_scruts`), we can simply carry a substitution, and apply it to every variable. I'm not completely sure of the best path here. Maybe try both? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 6 23:50:39 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Feb 2019 23:50:39 -0000 Subject: [GHC] #16274: Remove ghctags In-Reply-To: <051.60fcdc3e4ceedcac5234a746e3c693c6@haskell.org> References: <051.60fcdc3e4ceedcac5234a746e3c693c6@haskell.org> Message-ID: <066.1041fb136ae7529992a995c54d8565fb@haskell.org> #16274: Remove ghctags -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): "make install" of a bindist produced by hadrian fails because it can't find the wrapper script for ghctags. It's a bit sad given no-one seems to be using this tool. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 01:27:35 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 01:27:35 -0000 Subject: [GHC] #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. In-Reply-To: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> References: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> Message-ID: <062.9cf76e600115fdfc6a59f02fe0b292ef@haskell.org> #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): To be clear, the behaviour we would like to see is a warning whenever the {..} adds no new used bindings into the environment. {{{#!haskell data P = P { x :: Int, y :: Int } f1 P{..} = 1 + 3 -- nothing bound is used f2 P{x, ..} = x + 3 -- y bound but not used f3 P{x, y, ..} = x + y -- no bindings left, i.e. no new useful bindings introduced g1 P{..} = x + 3 -- x from .. is used g2 P{x, ..} = x + y -- y from .. is used, even if it's in a weird style }}} f1, f2 and f3 should warn, g1 and g2 should not. I actually gave this a go myself but the way it was programmed was a bit too much for me for a quick hack. The way it is done now is that {{{..}}} is expanded into the bindings and those bindings are tagged with "don't warn if unusued" flag. Instead it should warn, but only if none of the {{{..}}}-bound names is used. Depending on how it's done, we should be careful to produce only a single warning &c. I imagine any solution is not too hard for anyone used to the codebase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 03:06:34 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 03:06:34 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.1a16b64d7b760d8d6d225a377ad5df9b@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I do mean that note, and also the NB comment right after the call to `isReflexiveCo`. You're right about the `mkNakedCastTy`. There could be a latent bug there, because `tcSplitTyConApp` won't work as it should if a cast makes a `TyConApp` look like something else. > How bad would it be if `mkCastTy` did not remove a cast between `Type` and `Coercion`? It's potentially bad. Suppose we have `tyco :: Type ~ Coercion`. Then `Bool |> tyco` is `eqType` to `Bool`, but `splitTyConApp` behaves differently on them. Here's another approach: what if `coreView` dispenses with reflexive coercions, not `mkCastTy`? We're already careful to use `coreView` liberally. Implemented correctly, this should satisfy the definitional equality concerns. The problem will be performance: it's potentially expensive to check coercion types and compute equality, and `coreView` is called a lot. (Specifically, it's a shame to build a cast only to have to remove it lots of times.) But maybe we could take a hybrid approach: `mkCastTy` discards reflexive coercions that aren't `Type`-vs-`Coercion`, and `coreView` discards the rest. (`tcView` wouldn't, of course!) That would work, I think, but I'm not in love with the approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 03:55:58 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 03:55:58 -0000 Subject: [GHC] #16293: Inconsistencies and oddities of Proxy# In-Reply-To: <050.2f25f16e44a73b8047b8a62971a2da19@haskell.org> References: <050.2f25f16e44a73b8047b8a62971a2da19@haskell.org> Message-ID: <065.1ba9335494716be791a5164189e6cf5a@haskell.org> #16293: Inconsistencies and oddities of Proxy# -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree that you've found three bugs here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 03:59:27 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 03:59:27 -0000 Subject: [GHC] #16292: Wildcards in visible kind application In-Reply-To: <046.ddc84da258cfa15ad418574f23cf29ff@haskell.org> References: <046.ddc84da258cfa15ad418574f23cf29ff@haskell.org> Message-ID: <061.9d0aeec381a81c0efb4316c768eea720@haskell.org> #16292: Wildcards in visible kind application -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is essentially #16082, but focusing more about code than user-facing design. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 04:00:12 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 04:00:12 -0000 Subject: [GHC] #16082: Sort out treatment of underscores in types In-Reply-To: <047.f7eb04af23addac6db074d5fb31ec486@haskell.org> References: <047.f7eb04af23addac6db074d5fb31ec486@haskell.org> Message-ID: <062.5835e5f01f5be2ffe9d8067324b713a9@haskell.org> #16082: Sort out treatment of underscores in types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): See also #16292, which looks at a ghastly infelicity in the implementation but is otherwise in a similar space as this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 09:01:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 09:01:38 -0000 Subject: [GHC] #16274: Remove ghctags In-Reply-To: <051.60fcdc3e4ceedcac5234a746e3c693c6@haskell.org> References: <051.60fcdc3e4ceedcac5234a746e3c693c6@haskell.org> Message-ID: <066.8bbc52bbccee74e5b241b8569f38d6cd@haskell.org> #16274: Remove ghctags -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: None | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): +1 for removing it. We have much better tools for generating tags much more accurately and faster these days. I currently use these commands currently which work pretty well: {{{ # Generate compiler tags $ fast-tags --no-module-tags driver ghc compiler -R +RTS -N # Generate RTS tags $ ctags --append -R rts/**/*.c rts/**/*.h includes/**/*.h # Generate library + compiler tags $ fast-tags --no-module-tags driver ghc compiler libraries -R +RTS -N }}} I have a few other commands as well for different variations of which files to tag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 09:05:15 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 09:05:15 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.e538ed32a3cfe2c0cc54982c6a0fea89@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > also the NB comment right after the call to isReflexiveCo. To be explicit, you mean {{{ mkCastTy :: Type -> Coercion -> Type mkCastTy ty co | isReflexiveCo co = ty -- (EQ2) from the Note -- NB: Do the slow check here. This is important to keep the splitXXX -- functions working properly. Otherwise, we may end up with something -- like (((->) |> something_reflexive_but_not_obviously_so) biz baz) -- fails under splitFunTy_maybe. This happened with the cheaper check -- in test dependent/should_compile/dynamic-paper. }}} > Suppose we have tyco :: Type ~ Coercion It's worth noting that the type checker will produce an error message for any such coercion. It's like `Int ~ Bool`. I feel somewhat relaxed about the impact on Core of not upholding an equality that will be rejected by the typechecker anyway. (Long term I think we probably want to make Type and Coercion distinct everywhere.) > mkCastTy discards reflexive coercions that aren't Type-vs-Coercion, and coreView discards the rest Hm. You mean something like {{{ tcView (ty |> co) | ty1 == coercionKind, ty2 == typeKind = Just ty | ty1 = typeKind, ty2 == coercionKind = Just ty where (ty1,ty2) = coercionKind co }}} I suppose that'd be possible. But I agree it's smelly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 09:13:09 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 09:13:09 -0000 Subject: [GHC] #16274: Remove ghctags In-Reply-To: <051.60fcdc3e4ceedcac5234a746e3c693c6@haskell.org> References: <051.60fcdc3e4ceedcac5234a746e3c693c6@haskell.org> Message-ID: <066.d0121f04356ff1eaaea114b5ddfabfdc@haskell.org> #16274: Remove ghctags -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: None | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/305 -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/305 Comment: MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/305 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 10:42:12 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 10:42:12 -0000 Subject: [GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 In-Reply-To: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> References: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> Message-ID: <063.7893425d111cb20f0ea4e573193efb7f@haskell.org> #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.5 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): Phab:D4880 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rockbmb): As part of ticket #15622 that I opened, I ran into this issue when I introduced an import to `GHC.TypeNats` in `libraries/base/Data/Fixed.hs`, having used it to replace an import to `GHC.TypeLits`. I also added two extensions, `{-# LANGUAGE DataKinds #-}` and `{-# LANGUAGE KindSignatures #-}`, which may be part of the problem. The associated commit is [here](https://gitlab.haskell.org/rockbmb/ghc/commit/c6726d732273785b53986f152a6e03fc0784c0f3), and the failure I got in CI was: ``` HC [stage 1] libraries/base/dist-install/build/Data/Fixed.o HC [stage 1] libraries/base/dist-install/build/Data/Complex.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20190206 for x86_64-unknown-linux): Can't use Natural in base Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug make[1]: *** [libraries/base/dist-install/build/Data/Fixed.o] Error 1 make[1]: *** Waiting for unfinished jobs.... libraries/base/ghc.mk:4: recipe for target 'libraries/base/dist- install/build/Data/Fixed.o' failed make: *** [all] Error 2 Makefile:123: recipe for target 'all' failed ```. I included the error here because CI build logs in GitLab disappear after 1 week. I hope this helps, and if there's anything I can do to help close this issue I'll be happy to help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 10:47:52 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 10:47:52 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.00335c91473b5f4ee6d6a8211ee6e109@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed 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 rockbmb): * cc: "Ashley, Yakeley" (removed) * cc: Ashley, Yakeley (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 13:04:05 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 13:04:05 -0000 Subject: [GHC] #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 In-Reply-To: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> References: <048.cfab6e6ea21d7113a33d736cfa0133f3@haskell.org> Message-ID: <063.805a2ca2ba9a7f93a9d53542311594da@haskell.org> #15286: "Can't use Natural in base" when compiling GHC.Natural with -O0 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 8.5 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): Phab:D4880 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): The current handling of "wired-in" things such as Integer or Natural is very fragile. In your case, as you use type-level nats, GHC implicitly needs `Natural` from `GHC.Natural` but it can't access it because `GHC.Natural` is also defined in `base`. In `coreSyn/CorePrep.hs` we explicitly detect use of Natural when we compile `base` (see `guardNaturalUse`) to generate the panic you get. Otherwise GHC would fail with something like a "can't find/load interface" error. Not allowing to depend on `Natural` in `base` is annoying/stupid. In the past I've tried the most obvious solution: put `GHC.Natural` in its own package just like we do for `integer-*`. However it's harder for Natural than it is for Integer because `GHC.Natural` uses `Exception` (with an import cycle) and `Maybe` which are defined in `base`... I have written a note to state the problem and some ideas: {{{ GHC has some built-in functions, types, constructors, etc.. These are not defined in Haskell and when it encounters them it knows what to do with them. GHC also knows some Haskell defined functions, types, constructors, etc. It can use this knowledge to perform code transformation (e.g. constant folding) and to generate some code (e.g. desugaring lists, deriving instances, etc.). In this latter case, GHC has to build the Haskell code defining these functions, types, constructors, etc. without assuming knowledge of non already built Haskell code. For instance, suppose `Integer` data type and functions are defined in the "GHC.Integer" module. When building "GHC.Integer" GHC must assume that it knows nothing about Integer (nor about anything that depends on knowing Integer). It can be tricky: suppose we are building the Dummy module defined as follow: {-# LANGUAGE NoImplicitPrelude #-} module Dummy where dummy = 0 Even if Dummy doesn't depend on anything, GHC will default the type of "dummy" to Integer! So when building this module, there is an implicit dependency on knowing Integer and GHC.Integer must have been built already for GHC to query some stuff from it. In this case we could change the default or fix the type to avoid the dependency or to make it explicit: {-# LANGUAGE NoImplicitPrelude #-} module Dummy where default (Int) -- or: dummy :: Int -- or: import GHC.Integer () dummy = 0 At the time of writing, these dependencies are manually handled this way (in base, etc.) This is very fragile (see #15286). ------------- Ideas: 1) we should automatically detect implicit dependencies: when GHC is about to use a builtin Name or Id, it should: - detect the dependency it comes from - detect cyclic dependencies with the current module - ensure the dependency is built - clearly indicate why it can't build the implicit dependency if it happens Shouldn't be too hard: GHC should pretend the module contains an implicit "import" when it is about to use a builtin. GHC could even "source import" dependencies when there is a cycle because it would mean we compile the package containing both modules. A minor issue is that this implicit import could appear quite late in the compilation pipeline (during desugaring, deriving, maybe codegen, etc.): GHC could have to switch from building the current module to build the dependencies or fail and indicate to the caller the dependencies to build beforehand. The latter would be relatively slow because GHC would need to start compiling the module again and may fail the same way further in the compilation pipeline until all dependencies are built. 2) GHC shouldn't assume knowledge of unit IDs. We should be able to disable whole builtin stuff at once. E.g. when building integer-* packages, GHC uses predefined unit-id with the parameter: -this-unit-id integer-wired-in We should avoid this: instead GHC should query the unit-id of the integer-* package somehow (or use one given on the command line to allow easy switch between integer packages). We should also allow the possibility of compiling without integer-* package at all: this is what is implicitly assumed by GHC when it builds ghc-prim and integer-* packages (see `guardIntegerUse` in coreSyn/CorePrep.hs). Instead of relying on knowing two blessed integer-* packages, GHC could detect the presence of constructors such as "S#" in the given integer package so to use rules and generate code accordingly. It would make trying new releases/implementations of those much easier. Same for other packages (natural, base, template-haskell, etc.). E.g. we should be able to disable template-haskell, etc. When some dependencies are disabled/missing, GHC can't produce code using them nor use builtin rules assuming it knows them. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 13:05:28 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 13:05:28 -0000 Subject: [GHC] #16293: Inconsistencies and oddities of Proxy# In-Reply-To: <050.2f25f16e44a73b8047b8a62971a2da19@haskell.org> References: <050.2f25f16e44a73b8047b8a62971a2da19@haskell.org> Message-ID: <065.c557c828ffc995fdf7cb4fdc1aaaf62b@haskell.org> #16293: Inconsistencies and oddities of Proxy# -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Presumably the culprit is the definition of `Proxy#` in `TysPrim`: {{{ proxyPrimTyCon :: TyCon proxyPrimTyCon = mkPrimTyCon proxyPrimTyConName binders res_kind [Nominal,Nominal] where -- Kind: forall k. k -> Void# binders = mkTemplateTyConBinders [liftedTypeKind] id res_kind = unboxedTupleKind [] }}} Are you happy to dig? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 14:38:43 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 14:38:43 -0000 Subject: [GHC] #16221: Core Lint error with a data type In-Reply-To: <047.621c532512c5ecf6cb731ace319b51aa@haskell.org> References: <047.621c532512c5ecf6cb731ace319b51aa@haskell.org> Message-ID: <062.266f51cd91202b0fa3b03f6f9b17e542@haskell.org> #16221: Core Lint error with a data type -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by aspiwack): * cc: aspiwack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 17:42:46 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 17:42:46 -0000 Subject: [GHC] #16285: Hadrian fails to run the testsuite. In-Reply-To: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> References: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> Message-ID: <062.93f341902865d3554413c515a2bd804f@haskell.org> #16285: Hadrian fails to run the testsuite. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: snowleopard (added) Comment: Andrey, any idea of what's going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 17:57:15 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 17:57:15 -0000 Subject: [GHC] #16285: Hadrian fails to run the testsuite. In-Reply-To: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> References: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> Message-ID: <062.7cd70ba62911e4ae7ba19d25d6dff0f2@haskell.org> #16285: Hadrian fails to run the testsuite. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Alp, thanks for tagging me! As far as I understand, `iserv` is not supported on Windows, so when running the testsuite on Windows, we shouldn't depend on it and skip all associated tests. I guess, this line may be relevant: https://gitlab.haskell.org/ghc/ghc/blob/aad05fb3b36b93b919622f8a6dc032109d040d16/hadrian/src/Settings/Default.hs#L137 Andreas: perhaps, you could try making `iserv` conditional, as for example, here: https://gitlab.haskell.org/ghc/ghc/blob/aad05fb3b36b93b919622f8a6dc032109d040d16/hadrian/src/Settings/Default.hs#L115 Does this help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 19:16:45 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 19:16:45 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.58c10c4190c1fcba8f0ed18382b0b13b@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The type-checker might conceivably not produce an error for a coercion like that. For example, if we have {{{#!hs class Def a where meth :: a }}} then we get `axDef :: Def a ~R# a`, and thus `KindCo axDef :: Constraint ~# Type`. Would this happen in practice? Most likely not, but we can't rule it out. One possible route is to have `mkCastTy` carefully not discard `Type`/`Constraint` coercions... and do nothing else. This would violate property `(EQ)` of `Note [Non-trivial definitional equality]`. But (assuming the type-checker never maliciously produces `KindCo axDef`), this would come up only in ill-typed programs. Still, I can't rule out the possibility of a panic or poor error message in such a scenario. Perhaps worse, any misbehavior would be terribly fragile, based as it would be on an arbitrary choice between two things that GHC thinks are equal. As we're thinking about this, it's not just coercions between `Type` and `Constraint` that are in play: it's all coercions that are reflexive except for variations between `Type` and `Constraint`. For example, a coercion between `Type -> Constraint` and `Type -> Type`. So the simplistic check proposed in comment:9 would be insufficient. One other possible solution: introduce a `TcCastTy :: Type -> Coercion -> Type` constructor in `Type`, with the following invariant: the coercion stored is reflexive in Core but irreflexive in Haskell. That is, the coercion would relate something that mentions `Type` to something that mentions `Constraint`. `mkCastTy` could cleverly figure out whether to make a `CastTy` or a `TcCastTy`. `coreView` could discard `TcCastTy`s; `tcView` wouldn't. This is similar to the plan Simon expands in comment:9, but caching the decision of whether to discard. It's still all a bit distasteful, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 19:23:57 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 19:23:57 -0000 Subject: [GHC] #16285: Hadrian fails to run the testsuite. In-Reply-To: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> References: <047.f0b57ec83fc65577b8eca30fc42b8d21@haskell.org> Message-ID: <062.0e1000c3af2df1a2ff92b28a7c201761@haskell.org> #16285: Hadrian fails to run the testsuite. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Great, thanks for replying Andrey. Note that this `stagePackages` & `testsuitePackages` split has been bothering me a fair bit recently for WIP patches that I have, and it should all probably be revisited, but one thing at a time. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 22:13:56 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 22:13:56 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase In-Reply-To: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> References: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> Message-ID: <060.abac50a00c54ea3a0ed548add7c4b35a@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by guibou): Note that instead of patching the library, `LD_PRELOAD` can be used: {{{ LD_PRELOAD=/nix/store/6dhcmmfgy5fa0p3d235yaz4qfx8jhpar- gsl-2.5/lib/libgslcblas.so ghc -package hmatrix-gsl Foo.hs -fexternal- interpreter -fforce-recomp [1 of 1] Compiling Main ( Foo.hs, Foo.o ) Linking Foo ... }}} Succeed after 25s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 22:15:31 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 22:15:31 -0000 Subject: [GHC] #16260: Use of plugins causes different SafeHaskellMode returned for the module In-Reply-To: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> References: <046.97cb0aa91bd5837c4b7f5982e570b077@haskell.org> Message-ID: <061.d6bd5fe618f20659a551f7e9b53b6f62@haskell.org> #16260: Use of plugins causes different SafeHaskellMode returned for the module -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 22:34:58 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 22:34:58 -0000 Subject: [GHC] #11822: Pattern match checker exceeded (2000000) iterations In-Reply-To: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> References: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> Message-ID: <064.874f3ec830c37b3e2e78f8cc025c3370@haskell.org> #11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | 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 dbaynard): I've just encountered this (on 8.6.3) while making some changes to stack. I'll try an option which doesn't need to do so much checking. But this appears much smaller than the previous examples here. {{{#!haskell {#- LANGUAGE OverloadedLists -#} {#- LANGUAGE PatternSynonyms -#} {#- LANGUAGE GeneralisedNewtypeDeriving -#} import Data.Seq (Seq, pattern (:<|)) import Data.Set (Set) newtype SiblingDependencies = SiblingDependencies Int deriving (Eq, Ord, Enum, Integral, Real, Num) newtype Depth = Depth Int deriving (Eq, Ord, Enum, Integral, Real, Num) data TreeNode prefix = OnlyChild prefix | LeafLast prefix | LeafMid prefix | NodeLast prefix | NodeMid prefix | PrefixedLast prefix (Seq SiblingDependencies) (Set PackageName) Depth | PrefixedMid prefix (Seq SiblingDependencies) (Set PackageName) Depth mkTreeNode :: prefix -> Seq SiblingDependencies -> Set PackageName -> Depth -> TreeNode prefix mkTreeNode t [] _ _ = OnlyChild t mkTreeNode t [0] [] _ = LeafLast t mkTreeNode t [_] [] _ = LeafMid t mkTreeNode t [0] _ 0 = LeafLast t mkTreeNode t [_] _ 0 = LeafMid t mkTreeNode t [0] _ _ = NodeLast t mkTreeNode t [_] _ _ = NodeMid t mkTreeNode t (0 :<| ns) ds depth = PrefixedLast t ns ds depth mkTreeNode t (_ :<| ns) ds depth = PrefixedMid t ns ds depth }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 22:44:21 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 22:44:21 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.999d82df47d12c5a8c81cf8b47ad3081@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): tmobile, if you want something else to try you might try this patch. I really don't see how the current implementation can be correct; afterall, during a thunk update we need to make sure that the result is visible to other cores *before* we update the thunk. Reordering here would be quite bad. On the other hand, it seems like we would have seen this go wrong on SPARC far earlier than today. {{{#!diff diff --git a/rts/Updates.h b/rts/Updates.h index 1ba398bd35..412db99dda 100644 --- a/rts/Updates.h +++ b/rts/Updates.h @@ -44,8 +44,8 @@ W_ bd; \ \ OVERWRITING_CLOSURE(p1); \ - StgInd_indirectee(p1) = p2; \ prim_write_barrier; \ + StgInd_indirectee(p1) = p2; \ SET_INFO(p1, stg_BLACKHOLE_info); \ LDV_RECORD_CREATE(p1); \ bd = Bdescr(p1); \ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 22:53:46 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 22:53:46 -0000 Subject: [GHC] #16272: libffi copies files into rts build tree In-Reply-To: <049.e3bdaa5cd1e51cb6774df0e029e2b534@haskell.org> References: <049.e3bdaa5cd1e51cb6774df0e029e2b534@haskell.org> Message-ID: <064.542cc4c18f0aad570cd712373a96b207@haskell.org> #16272: libffi copies files into rts build tree -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 22:54:18 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 22:54:18 -0000 Subject: [GHC] #16271: Building stage1:lib:text target is not robust In-Reply-To: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> References: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> Message-ID: <064.1d452d4f99b3e88b428c138c99d250eb@haskell.org> #16271: Building stage1:lib:text target is not robust -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: NeilMitchell (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 22:54:31 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 22:54:31 -0000 Subject: [GHC] #16272: libffi copies files into rts build tree In-Reply-To: <049.e3bdaa5cd1e51cb6774df0e029e2b534@haskell.org> References: <049.e3bdaa5cd1e51cb6774df0e029e2b534@haskell.org> Message-ID: <064.ced145a7d326d88a1a441f654294df3d@haskell.org> #16272: libffi copies files into rts build tree -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell@… (removed) * cc: NeilMitchell (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 7 23:51:16 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Feb 2019 23:51:16 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.9db228ee873eee0f0342e5acc0428adb@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmobile): Sorry for my slowness on this; I've been busy with other things at work and we have yet to actually trigger this bug with out code on aarch64 for some reason, so I haven't had time to take a look. Now that I understand a bit better I agree that `stg_BLACKHOLE` is unlikely to blame. Ben, I'll give your patch a go, but it seems strange that we update the indirectee straight away in the macro; why not do something like: {{{ #define updateWithIndirection(p1, p2, and_then) \ W_ bd; \ \ OVERWRITING_CLOSURE(p1); \ SET_INFO(p1, stg_BLACKHOLE_info); \ LDV_RECORD_CREATE(p1); \ prim_write_barrier; \ StgInd_indirectee(p1) = p2; \ bd = Bdescr(p1); \ if (bdescr_gen_no(bd) != 0 :: bits16) { \ recordMutableCap(p1, TO_W_(bdescr_gen_no(bd))); \ TICK_UPD_OLD_IND(); \ and_then; \ } else { \ TICK_UPD_NEW_IND(); \ and_then; \ } }}} Is it just that we don't care when other HECs see the side effects of SET_INFO? It seems to me that doing SET_INFO after the write barrier could cause you to race too. And as far as SPARC goes, IIRC SPARC machines are actually in TSO mode by default, and programs must explicitly switch to RMO or PSO mode. SPARC TSO provides essentially the same guarantees as X86. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 8 14:44:13 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Feb 2019 14:44:13 -0000 Subject: [GHC] #16259: Hadrian does not work with a cabal v2-installed "Happy" In-Reply-To: <049.ec13a85dcdc8dc8a560ef06cae684380@haskell.org> References: <049.ec13a85dcdc8dc8a560ef06cae684380@haskell.org> Message-ID: <064.001b434267bc0107158536b310437d33@haskell.org> #16259: Hadrian does not work with a cabal v2-installed "Happy" -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: NeilMitchell (added) Comment: > a simple way to workaround this is inject a constraint to prevent Setup.hs scripts from using an unreleased version of lib:Cabal, via e.g. @hvr: The fact that Hadrian currently depends on the in-tree Cabal library has proven to be both slow and fragile. Neil and I have recently been thinking that we should revert to depending on a stable release of Cabal instead. Pros: * This will make Hadrian faster to build if the (stable) Cabal library is shared with other projects on the same machine. * We don't need to adapt/rebuild Hadrian every time the in-tree Cabal library is changed. We will upgrade to a new Cabal version only when need be. * This will hopefully allow us to avoid issues like the one described in this ticket. Cons: * We will not be able to parse GHC's `.cabal` files if they use bleeding- edge features of Cabal. And arguably, they shouldn't. Any thoughts on this? I could spawn this into a separate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 8 15:04:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Feb 2019 15:04: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.732309f8a71c23d49a0a7d07bed65356@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: 8.10.1 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: #8635 #9370 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn * related: => #8635 #9370 Comment: I debugged this ticket and found the following: **The Issue** GHC has a dynamic flag `Opt_IgnoreInterfacePragmas` or `-fignore- interface-pragmas`. The setting of this flag is dependent on the optimization flag `-O`. `-O0` will set the Opt_IgnoreInterfacePragmas flag On, `-O1` and `-O2` will set it Off. If the Opt_IgnoreInterfacePragmas flag is On, then GHC(i) does not store optimization data (eg inline pragmas or rewrite rules) from the interface files. See `compiler/iface/LoadIface.hs:loadInterface`. The field containing the rules is `eps_rule_base`, the one containig the pragmas is `eps_PTE` both in the ExternalPackageState (EPS) record. The default optimization is -O0, so Opt_IgnoreInterfacePragmas is On. During startup, GHCi processes the interface `GHC.Prim` containing the `fold/build` rule. As Opt_IgnoreInterfacePragmas is On, GHCi does not store any rules in the EPS record. Only after this, we get the possibility to set the optimization flag to -O1 either in the `.ghci` file or with a `:set` command. But it's already too late, the `fold/build` rule wasn't stored, the simplifier doesn't know the rule and cannot optimize the loop: GHCi needs 8800000 bytes to process the example in this ticket. If we specify -O1 as a command line parameter everything is fine: Opt_IgnoreInterfacePragmas is Off, ghci stores the fold/build rule, the simplifier knows and uses the rule, and processing our example needs less than 100000 bytes! **The History** This is an old, well known and heavily discussed issue. See tickets #8635 and #9370. The simplest of the proposed solutions was just to store all the information from the interface files independently of the Opt_IgnoreInterfacePragmas flag. Then @richardfung provided a patch Phab:D2485 for #9370. Unsurprisingly the validation run showed some stats error, because storing all the optimization needed more space. @simonmar commented: > I care a lot about unoptimized compile-time performance - couldn't this make things worse by forcing GHC to read all the interface pragmas from interface files, even with -O0? However, @simonmar also made two suggestions how to solve this issue. The first one was: > Lazily load the pragma info, so that it doesn't cost anything if we don't use it. The simplifier should use Opt_IgnoreInterfacePragmas to decide whether to use the pragma info from external Ids or not. After this, @richardfung abandonded his patch. **The Proposed Solution:** I think the above suggestion of @simonmar is the way to go: 1. If the Opt_IgnoreInterfacePragmas flag is set On, we continue to ignore the optimization data in the interface files. However if we ignore the optimization data, we store the module name in a new list, probably also in the ExternalPackageState (EPS) record. 2. ™: If the Opt_IgnoreInterfacePragmas is set Off and there are module entries in the new list, we reload and reprocess the interface files, ignore everything but the optimization data previously excluded by Opt_IgnoreInterfacePragmas. We add this information to the EPS record. Then we clear the new list. (I still have to investigate where to put this functionality...) 3. We use wrapper functions to access the fields `eps_rule_base` and `eps_PTE`: If Opt_IgnoreInterfacePragmas is Off, the wrapper functions return all the data, else they return the initial values, without any optimization data from the interface files. All comments are welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 8 15:11:35 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Feb 2019 15:11:35 -0000 Subject: [GHC] #8635: GHC optimisation flag ignored when importing a local module with derived type classes In-Reply-To: <051.b56cbb747db73c4a6033f73a503b3d1a@haskell.org> References: <051.b56cbb747db73c4a6033f73a503b3d1a@haskell.org> Message-ID: <066.86136b09abac440e0602dcc04a5f2431@haskell.org> #8635: GHC optimisation flag ignored when importing a local module with derived type classes -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9370 #13002 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn * related: #9370 => #9370 #13002 Comment: [https://ghc.haskell.org/trac/ghc/ticket/13002#comment:18 | See ticket #13002 comment 18] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 8 15:13:22 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Feb 2019 15:13:22 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.e39eec13cc13bfdd506c35465f121cfa@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 14119 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For anyone reading this ticket who is searching for a workaround: While I haven't found a general-purpose way to avoid this bug, in limited situations it's often possible to rewrite your type families in a way that shifts applications of type families from the left-hand side to the right- hand side. For example, GHC //does// accept this formulation of `At`: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} import Data.Kind import Data.Type.Equality data N = Z | S N type family Len (xs :: [a]) :: N where Len '[] = Z Len (_ ': xs) = S (Len xs) data Vec :: N -> Type -> Type where VNil :: Vec Z a (:>) :: a -> Vec n a -> Vec (S n) a type family ListToVec (l :: [a]) :: Vec (Len l) a where ListToVec '[] = VNil ListToVec (x:xs) = x :> ListToVec xs data Fin :: N -> Type where FZ :: Fin (S n) FS :: Fin n -> Fin (S n) type family At (xs :: [a]) (i :: Fin (Len xs)) :: a where At xs i = At' (ListToVec xs) i type family At' (xs :: Vec n a) (i :: Fin n) :: a where At' (x :> _) FZ = x At' (_ :> xs) (FS i) = At' xs i -- Unit tests test1 :: At '[True] FZ :~: True test1 = Refl test2 :: At [True, False] FZ :~: True test2 = Refl test3 :: At [True, False] (FS FZ) :~: False test3 = Refl }}} If you inspect the definition of `At`, you'll see why this works: {{{ λ> :info At type family At @a (xs :: [a]) (i :: Fin (Len @a xs)) :: a where forall a (xs :: [a]) (i :: Fin (Len @a xs)). At @a xs i = At' @(Len @a xs) @a (ListToVec @a xs) i }}} Note that the left-hand side, `At @a xs i`, does not contain any immediate uses of `Len`. (The kind of `i` does, but thankfully, GHC doesn't consider that to be an illegal type synonym family application.) The other uses of `Len` and `ListToVec` have been quarantined off on the right-hand side, where GHC can't complain about them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 8 15:13:39 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Feb 2019 15:13:39 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.6dac6e7882eb4579e2bb295665ce6b0f@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: RolandSenn Type: bug | Status: new Priority: high | Milestone: 8.10.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: bgamari => RolandSenn Comment: [https://ghc.haskell.org/trac/ghc/ticket/13002#comment:18 | See ticket #13002 comment 18] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 8 15:16:03 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Feb 2019 15:16:03 -0000 Subject: [GHC] #15336: ./System/IO.hs accidentally overridden when running ghci In-Reply-To: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> References: <044.ba3290f444f0e979b7add843365e09fb@haskell.org> Message-ID: <059.8b5d945db25a5bc344f3b5d377c8d680@haskell.org> #15336: ./System/IO.hs accidentally overridden when running ghci -------------------------------------+------------------------------------- Reporter: luqui | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: RolandSenn => (none) Comment: I decided to stop working on this. The needed changes are just too dangerous. Please feel free to grab this ticket and find a nice solution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 8 15:35:48 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Feb 2019 15:35:48 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.5e7b1485e2f154ab7be09230155824f3@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Changes (by aspiwack): * cc: aspiwack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 8 16:39:58 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Feb 2019 16:39:58 -0000 Subject: [GHC] #16296: OccurAnal should not break the linter assumptions Message-ID: <047.644681ea1af3bb09669b9aa1303ac010@haskell.org> #16296: OccurAnal should not break the linter assumptions -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- As discovered in #16288 (see in particular https://ghc.haskell.org/trac/ghc/ticket/16288#comment:2), the implementation of the binder-swap transformation in the occurrence analysis sometimes produces terms which would be refused by the linter. Specifically: {{{#!hs case A.x of u { pat -> rhs } }}} Becomes {{{#!hs case A.x of u { pat -> let x = u in rhs } }}} Crucially, here, `A.x` (which is a global id) and `x` (which is a local id) ''have the same unique''. This is so that `x` shadows `A.x` in `rhs` and captures all the occurrences of `A.x` in rhs. Which are now bound by `x`. But all these occurrences of `A.x` (which are now occurrences of `x`) are still marked as global ids. This is rejected by the linter. The occurrence analysis is counting on the fact that there will be a simplifier step before the next linter fires, which will inline `x` and replace it by `u` everywhere. As #16288 has shown, this is not always the case! (specifically, in #16288, occurrence analysis happens in an unfolding, but is not followed by a simplifier pass). ---- It's easy to fix such bugs: turn off binder-swap in occurrence analysis when not followed by the simplifier. But it is very fragile. So the longer term solution would be to never produce term which break the linter. The entire reason for this `let x = u` is to avoid carrying a substitution in the occurrence analysis (and offload the work of actually doing the substitution to the simplifier). But the occurrence analysis will work through the entire `rhs` anyway. So it should be able to, at very little cost, propagate a substitution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 8 18:08:02 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Feb 2019 18:08:02 -0000 Subject: [GHC] #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> References: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> Message-ID: <062.3764325c2d868818c4369faffa4b80cf@haskell.org> #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: 15840 Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/325 -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/325 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 04:59:52 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 04:59:52 -0000 Subject: [GHC] #16297: Access violation and hang with template haskell Message-ID: <044.d7d75b5965ee2cd38679152111ba5ed0@haskell.org> #16297: Access violation and hang with template haskell -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- I found this while building the haskell-ide-engine on windows. During that build I was stuck on two packages(fclabels, haskell-lsp-types). {{{ D:\test>stack install --resolver lts-13.6 fclabels fclabels-2.0.3.3: configure fclabels-2.0.3.3: build -- While building package fclabels-2.0.3.3 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.4.0.1_ghc-8.6.3.exe --builddir=.stack-work\dist\e626a42b build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Logs have been written to: C:\sr\global-project\.stack- work\logs\fclabels-2.0.3.3.log Configuring fclabels-2.0.3.3... Preprocessing library for fclabels-2.0.3.3.. Building library for fclabels-2.0.3.3.. [ 1 of 10] Compiling Data.Label.Point ( src\Data\Label\Point.hs, .stack-work\dist\e626a42b\build\Data\Label\Point.o ) [ 2 of 10] Compiling Data.Label.Poly ( src\Data\Label\Poly.hs, .stack-work\dist\e626a42b\build\Data\Label\Poly.o ) [ 3 of 10] Compiling Data.Label.Partial ( src\Data\Label\Partial.hs, .stack-work\dist\e626a42b\build\Data\Label\Partial.o ) [ 4 of 10] Compiling Data.Label.Mono ( src\Data\Label\Mono.hs, .stack-work\dist\e626a42b\build\Data\Label\Mono.o ) [ 5 of 10] Compiling Data.Label.Failing ( src\Data\Label\Failing.hs, .stack-work\dist\e626a42b\build\Data\Label\Failing.o ) [ 6 of 10] Compiling Data.Label.Derive ( src\Data\Label\Derive.hs, .stack-work\dist\e626a42b\build\Data\Label\Derive.o ) [ 7 of 10] Compiling Data.Label ( src\Data\Label.hs, .stack- work\dist\e626a42b\build\Data\Label.o ) [ 8 of 10] Compiling Data.Label.Base ( src\Data\Label\Base.hs, .stack-work\dist\e626a42b\build\Data\Label\Base.o ) -- doesn't terminate }}} {{{ D:\test>stack install --resolver lts-13.6 haskell-lsp-types haskell-lsp-types-0.8.0.1: configure haskell-lsp-types-0.8.0.1: build -- While building package haskell-lsp-types-0.8.0.1 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.4.0.1_ghc-8.6.3.exe --builddir=.stack-work\dist\e626a42b build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 11 Logs have been written to: D:\Hoj\Desktop\fclabels-2.0.3.3\.stack- work\logs\haskell-lsp-types-0.8.0.1.log Configuring haskell-lsp-types-0.8.0.1... Preprocessing library for haskell-lsp-types-0.8.0.1.. Building library for haskell-lsp-types-0.8.0.1.. [ 1 of 24] Compiling Language.Haskell.LSP.Types.Constants ( src\Language\Haskell\LSP\Types\Constants.hs, .stack- work\dist\e626a42b\build\Language\Haskell\LSP\Types\Constants.o ) [ 2 of 24] Compiling Language.Haskell.LSP.Types.List ( src\Language\Haskell\LSP\Types\List.hs, .stack- work\dist\e626a42b\build\Language\Haskell\LSP\Types\List.o ) [ 3 of 24] Compiling Language.Haskell.LSP.Types.DocumentFilter ( src\Language\Haskell\LSP\Types\DocumentFilter.hs, .stack- work\dist\e626a42b\build\Language\Haskell\LSP\Types\DocumentFilter.o ) Access violation in generated code when reading 0x1017895900 Attempting to reconstruct a stack trace... Frame Code address * 0x4ffd920 0x17c3f148 C:\sr\snapshots\3233b5e2\lib\x86_64 -windows- ghc-8.6.3\aeson-1.4.2.0-nGorlomFPWK9VTcoGhjmV\HSaeson-1.4.2.0-nGorlomFPWK9VTcoGhjmV.o+0x2f040 (aesonzm1zi4zi2zi0zmnGorlomFPWK9VTcoGhjmV_DataziAesonziTH_consToValue_info+0x688) }}} I don't know if those two issues are same. I tried simplifying the former. {{{ -- A.hs {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE TemplateHaskell #-} module A ( head , tail ) where -- import Prelude hiding (fst, snd, head, tail) -- import Control.Arrow (arr, Kleisli(..), ArrowApply, ArrowZero, ArrowChoice) import B (getLabel) -- data Point cat g i f o = Point (cat f o) (cat (cat o i, f) g) -- data PLens cat f o where -- PLens :: !(Point cat g i f o) -> PLens cat (f -> g) (o -> i) -- Id :: ArrowApply cat => PLens cat f f -- type Lens cat f o = PLens cat (f -> f) (o -> o) -- head :: (ArrowZero arr, ArrowApply arr, ArrowChoice arr) => Lens arr [a] a -- tail :: (ArrowZero arr, ArrowApply arr, ArrowChoice arr) => Lens arr [a] [a] (head, tail) = $(getLabel ''[]) }}} {{{ -- B.hs {-# LANGUAGE TemplateHaskell #-} module B (getLabel) where import Language.Haskell.TH getLabel :: Name -> Q Exp getLabel = undefined }}} `stack exec ghc --resolver lts-13.6 -- A.hs B.hs` also hangs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 08:24:53 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 08:24:53 -0000 Subject: [GHC] #15849: Error message: "Perhaps you need a let in a do block", when there is no do block. In-Reply-To: <046.1a23c56db483a32d0322994bc5b0ff58@haskell.org> References: <046.1a23c56db483a32d0322994bc5b0ff58@haskell.org> Message-ID: <061.00e54cc36dc864905314c921d62edc85@haskell.org> #15849: Error message: "Perhaps you need a let in a do block", when there is no do block. -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: nineonine Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/330 -------------------------------------+------------------------------------- Changes (by nineonine): * owner: (none) => nineonine * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/330 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 14:56:27 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 14:56:27 -0000 Subject: [GHC] #16293: Inconsistencies and oddities of Proxy# In-Reply-To: <050.2f25f16e44a73b8047b8a62971a2da19@haskell.org> References: <050.2f25f16e44a73b8047b8a62971a2da19@haskell.org> Message-ID: <065.f1b6dba0351f1b716f4d38f087ae98ef@haskell.org> #16293: Inconsistencies and oddities of Proxy# -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/334 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/334 Comment: Digging complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 15:01:07 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 15:01:07 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.bf162b0e688eaebeeaa96478cda490d9@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/113 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/113 Comment: harpocrates, was this fixed in [https://gitlab.haskell.org/ghc/ghc/commit/5341edf3635f2875271acc469570481c52000374 5341edf3]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 15:02:55 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 15:02:55 -0000 Subject: [GHC] #16193: Nondeterministic T15897 timeout failures In-Reply-To: <050.6b50375f06c0c1355a5fdb64d26cefc5@haskell.org> References: <050.6b50375f06c0c1355a5fdb64d26cefc5@haskell.org> Message-ID: <065.5df71c07adcc884f6b5af1df7e3eacfe@haskell.org> #16193: Nondeterministic T15897 timeout failures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/319 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/319 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 15:43:55 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 15:43:55 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.e08d3ae6f0dce4368667700a31ec683c@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: trommler Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/42 -------------------------------------+------------------------------------- Comment (by bgamari): Merged with db9b84c4154d7c6ab6bf4d1398246deef0107d6f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 15:50:22 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 15:50:22 -0000 Subject: [GHC] #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] In-Reply-To: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> References: <045.95b47bc55efff213aa04a6f9ee58b854@haskell.org> Message-ID: <060.e9e246d63258d45e278bbd152d696b8f@haskell.org> #16094: panic! (the 'impossible' happened): for powerpc-unknown-linux getRegister(ppc): I64[I32[BaseReg + 812] + 64] -------------------------------------+------------------------------------- Reporter: slyfox | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/42 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 15:52:12 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 15:52:12 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.4d037475eec3d8482913be97b901bc2a@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.4 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103, MR:146 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged * comment:41 with 4f712fb3c88d2586f842202ca3dd921596599777 * comment:42 with cf5b5a74564a61aeb636a88d68732b913306d101 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 15:52:46 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 15:52:46 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.ce4d90b78a1a3eae94afb030fd6ee474@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.4 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T16141 Blocked By: | Blocking: Related Tickets: #16191 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/88 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged with ff47e60a9d017e5d749ff5e29e61d6f1a558d142. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 15:53:57 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 15:53:57 -0000 Subject: [GHC] #16150: Data races in itimer_thread_func reported by ThreadSanitizer In-Reply-To: <045.67366c6314679071e780eb66600c5b99@haskell.org> References: <045.67366c6314679071e780eb66600c5b99@haskell.org> Message-ID: <060.f693dfd89b89c0fb25e0b7562b6d0153@haskell.org> #16150: Data races in itimer_thread_func reported by ThreadSanitizer -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.4 Component: Runtime System | Version: 8.4.4 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 4f180640f3a398bd75e1406111a74eb61a44a529 and 7ec385f40406a23da7a52fd5a07131efb8973233. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 18:23:45 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 18:23:45 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors In-Reply-To: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> References: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> Message-ID: <062.5735c002d07ad6484750efbabc88ccdb@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/225 -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `master` in fb031b9b046e48ffe0d2864ec76bee3bc8ff5625. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 20:34:00 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 20:34:00 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.da081d8199ecd3b4265165f965e562da@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/113 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 20:37:47 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 20:37:47 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.129975da15bbd99c2ea0dd356e19213b@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/113 -------------------------------------+------------------------------------- Comment (by harpocrates): Oops yes it was! The inconsistent behaviour was fixed in the commit you referenced. All of the programs from the initial bug report should now error out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 20:39:11 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 20:39:11 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.6ea0489c9c71960f059f147c2682864f@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/113 -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK. Do you think the examples from this ticket can reasonably be added as test cases, or can this ticket be closed as-is? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 20:46:25 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 20:46:25 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.81ea1769cf31613ffc82dc6b0171b7c3@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/113 -------------------------------------+------------------------------------- Comment (by harpocrates): Test cases based on the Trac ticket sounds like a good idea. I'm not sure why they didn't make it into the initial MR... Unless you do it sooner, I can address that tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 20:48:07 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 20:48:07 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.35a7f2dc1a75d6d1923ced113b473cdb@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/113 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 21:43:09 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 21:43:09 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.c18d8795710a61538b18df652446a875@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, indeed let's think through this. There are two cases that `updateWithIndirection` needs to safely handle. In both case it is turning some sort of closure into an indirection: * updating a blackhole (e.g. as called from the `stg_upd_frame` entry code) * updating a thunk (e.g. from `Threads.c:updateThunk`) Note that the free variable fields of a thunk and the indirectee field of a thunk do not overlap (see `StgThunkHeader` for how this is so). Consequently it is safe to write to the indirectee field before writing to the info table pointer. In the event that we see this interleaving: {{{ Thread A Thread B --------------------------- --------------------------- X->indirectee = Y enter X X->info = stg_BLACKHOLE_info }}} we will, at worst, duplicate the evaluation of `X`. There is no chance to stumble into unsoundness here. The important thing, as mentioned in comment:22, is that the newly-created result is fully visible before the `updatee` field is written. This can be ensured by placing a barrier somewhere after the construction of the result but before the write to `updatee`. Consequently, I think my patch, wherein `updateWithIndirection` is {{{ #define updateWithIndirection(p1, p2, and_then) \ W_ bd; \ \ OVERWRITING_CLOSURE(p1); \ StgInd_indirectee(p1) = p2; \ prim_write_barrier; \ SET_INFO(p1, stg_BLACKHOLE_info); \ . . . }}} ought to be correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 22:15:21 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 22:15:21 -0000 Subject: [GHC] #14848: -XDuplicateRecordFields breaks record expression splices In-Reply-To: <048.60548a7facfb2bb72ce43f7899267ddd@haskell.org> References: <048.60548a7facfb2bb72ce43f7899267ddd@haskell.org> Message-ID: <063.9af6888cfebd94d0d852cc148224cc75@haskell.org> #14848: -XDuplicateRecordFields breaks record expression splices -------------------------------------+------------------------------------- Reporter: dailectic | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ORF Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11103 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * related: => #11103 Comment: I've just rediscovered this issue, and the interaction between `DuplicateRecordFields` and `TemplateHaskell` definitely needs to be addressed more carefully. The problem here is the case for `HsRecFld` in `DsMeta.repE`, which simply replaces the field occurrence with the selector function (which has an internal name that cannot be spliced in, namely `Name "$sel:x:A" (NameG VarName pkg "Lib")`). There are other related problems in `DsMeta` for representing fields in record definition, construction and pattern matching. The way #11103 dealt with a similar problem in reification was to represent field names using a specially-crafted `NameQ`, rather than a `NameG`. In this example that approach would give `Name "x" (NameQ "Lib")` instead. Note that `NameG` cannot be used with the field label in place of the selector, because that leads to looking up an Orig name that doesn't exist. However, while using `NameQ` should fix this example, it doesn't work in general: it means the name is dynamically bound, but of course the field might not be in scope when the splice is run. For a concrete example of this, consider a tiny variant of the test case from #12993: {{{#!hs {-# LANGUAGE DuplicateRecordFields #-} {-# LANGUAGE TemplateHaskell #-} module T12993_Lib (q) where data X = X { x :: Int } q = [|x|] }}} {{{#!hs {-# LANGUAGE TemplateHaskell #-} module T12993 where import T12993_Lib f = $(q) }}} This currently fails with an "Illegal variable name" error similar to the original report from this ticket. With the `NameQ` approach, it would still fail because `x` is not in scope in `T12993`. It seems fairly clear to me that dealing with this properly requires extending the TH AST in some way. The least invasive option might be to extend `NameFlavour` with a new constructor for field names, which would be rather like `NameG` but would carry the selector name. I'm not sure if there are better designs, however. What is the process for proposing/discussing such changes to TH? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 23:22:16 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 23:22:16 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.24086e7daf95e868b5c8b305c294e889@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have put up a more complete patch, including a Note, on GitLab: https://gitlab.haskell.org/ghc/ghc/merge_requests/337. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 9 23:52:08 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Feb 2019 23:52:08 -0000 Subject: [GHC] #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 In-Reply-To: <044.a4974a0a5c6c582f9e7335ab715702df@haskell.org> References: <044.a4974a0a5c6c582f9e7335ab715702df@haskell.org> Message-ID: <059.ae1713e8e735dbd30f85efc35f187e00@haskell.org> #12658: GHC 7.10.3 sometimes reports unimplemented/strange closure type 63270 ---------------------------------------+------------------------------- Reporter: clint | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: It has been a few years since this has been reported and there is no reproducer. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 01:05:19 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 01:05:19 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.4afc1e5503eb8dcf84bc47814ed99839@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Unfortunately this doesn't appear to fix the issue (as reproduced by the repro attached in comment:1) on aarch64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 01:20:51 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 01:20:51 -0000 Subject: [GHC] #15849: Error message: "Perhaps you need a let in a do block", when there is no do block. In-Reply-To: <046.1a23c56db483a32d0322994bc5b0ff58@haskell.org> References: <046.1a23c56db483a32d0322994bc5b0ff58@haskell.org> Message-ID: <061.ffd5c2b1e91de865d4cc559e827fba78@haskell.org> #15849: Error message: "Perhaps you need a let in a do block", when there is no do block. -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: nineonine Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/330 -------------------------------------+------------------------------------- Changes (by nineonine): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 01:53:17 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 01:53:17 -0000 Subject: [GHC] #16298: Awful(?) code in AArch64 stg_BLACKHOLE entry code Message-ID: <046.8c7986ca3a94fb68ac488b0e764787dd@haskell.org> #16298: Awful(?) code in AArch64 stg_BLACKHOLE entry code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Runtime | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's been a while since I've look at ARM assembler but this doesn't look right: {{{ Dump of assembler code for function stg_BLACKHOLE_info$def: 0x0000ffffb66d6118 <+0>: mov x23, x22 0x0000ffffb66d611c <+4>: ldr x22, [x22, #8] 0x0000ffffb66d6120 <+8>: tst x22, #0x7 0x0000ffffb66d6124 <+12>: b.ne 0xffffb66d6224 // b.any 0x0000ffffb66d6128 <+16>: adrp x25, 0xffffb66fb000 0x0000ffffb66d612c <+20>: adrp x26, 0xffffb66fb000 0x0000ffffb66d6130 <+24>: adrp x27, 0xffffb66fb000 0x0000ffffb66d6134 <+28>: adrp x29, 0xffffb66fb000 0x0000ffffb66d6138 <+32>: ldr x25, [x25, #3880] 0x0000ffffb66d613c <+36>: ldr x26, [x26, #3888] 0x0000ffffb66d6140 <+40>: ldr x27, [x27, #3896] 0x0000ffffb66d6144 <+44>: ldr x29, [x29, #3904] 0x0000ffffb66d6148 <+48>: sub x24, x19, #0x18 0x0000ffffb66d614c <+52>: ldr x8, [x22] 0x0000ffffb66d6150 <+56>: cmp x8, x25 ... }}} Why do we `adrp` four times? Couldn't this be reused, with each `ldr` result going to a separate register? This was generated by LLVM 7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 02:19:53 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 02:19:53 -0000 Subject: [GHC] #16298: Awful(?) code in AArch64 stg_BLACKHOLE entry code In-Reply-To: <046.8c7986ca3a94fb68ac488b0e764787dd@haskell.org> References: <046.8c7986ca3a94fb68ac488b0e764787dd@haskell.org> Message-ID: <061.15577578b8160e740058d1960974a879@haskell.org> #16298: Awful(?) code in AArch64 stg_BLACKHOLE entry code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have been staring more at this code and have found it's even worse than I thought. Far more repetition than I would have thought would be necessary. Here's the full dump: {{{ Dump of assembler code for function stg_BLACKHOLE_info$def: 0x0000ffffb66d6118 <+0>: mov x23, x22 // x23 == x22 == blackhole closure 0x0000ffffb66d611c <+4>: ldr x22, [x22, #8] // x22 = bh->indirectee 0x0000ffffb66d6120 <+8>: tst x22, #0x7 // GET_TAG(bh->indirectee) == 0? 0x0000ffffb66d6124 <+12>: b.ne 0xffffb66d6224 // b.any 0x0000ffffb66d6128 <+16>: adrp x25, 0xffffb66fb000 0x0000ffffb66d612c <+20>: adrp x26, 0xffffb66fb000 0x0000ffffb66d6130 <+24>: adrp x27, 0xffffb66fb000 0x0000ffffb66d6134 <+28>: adrp x29, 0xffffb66fb000 0x0000ffffb66d6138 <+32>: ldr x25, [x25, #3880] 0x0000ffffb66d613c <+36>: ldr x26, [x26, #3888] 0x0000ffffb66d6140 <+40>: ldr x27, [x27, #3896] 0x0000ffffb66d6144 <+44>: ldr x29, [x29, #3904] 0x0000ffffb66d6148 <+48>: sub x24, x19, #0x18 0x0000ffffb66d614c <+52>: ldr x8, [x22] 0x0000ffffb66d6150 <+56>: cmp x8, x25 0x0000ffffb66d6154 <+60>: b.eq 0xffffb66d61a8 // b.none 0x0000ffffb66d6158 <+64>: cmp x8, x26 0x0000ffffb66d615c <+68>: b.eq 0xffffb66d6178 // b.none 0x0000ffffb66d6160 <+72>: cmp x8, x29 0x0000ffffb66d6164 <+76>: b.eq 0xffffb66d6178 // b.none 0x0000ffffb66d6168 <+80>: adrp x9, 0xffffb66fb000 0x0000ffffb66d616c <+84>: ldr x9, [x9, #3912] 0x0000ffffb66d6170 <+88>: cmp x8, x9 0x0000ffffb66d6174 <+92>: b.ne 0xffffb66d61b4 // b.any 0x0000ffffb66d6178 <+96>: orr w1, wzr, #0x4 0x0000ffffb66d617c <+100>: mov x0, x24 0x0000ffffb66d6180 <+104>: bl 0xffffb66c6fe8 0x0000ffffb66d6184 <+108>: str x27, [x0] 0x0000ffffb66d6188 <+112>: ldr x8, [x19, #872] 0x0000ffffb66d618c <+116>: mov x22, x0 0x0000ffffb66d6190 <+120>: mov x1, x22 0x0000ffffb66d6194 <+124>: stp x8, x23, [x0, #16] 0x0000ffffb66d6198 <+128>: mov x0, x24 0x0000ffffb66d619c <+132>: bl 0xffffb66ae648 0x0000ffffb66d61a0 <+136>: cbnz x0, 0xffffb66d61e4 0x0000ffffb66d61a4 <+140>: ldr x22, [x23, #8] 0x0000ffffb66d61a8 <+144>: tst x22, #0x7 0x0000ffffb66d61ac <+148>: b.eq 0xffffb66d614c // b.none 0x0000ffffb66d61b0 <+152>: b 0xffffb66d6224 0x0000ffffb66d61b4 <+156>: tst x22, #0x7 0x0000ffffb66d61b8 <+160>: b.ne 0xffffb66d6224 // b.any 0x0000ffffb66d61bc <+164>: b 0xffffb66d61c4 0x0000ffffb66d61c0 <+168>: ldr x8, [x22] // $x8 = indirectee->info => 0x0000ffffb66d61c4 <+172>: ldursw x9, [x8, #-8] 0x0000ffffb66d61c8 <+176>: sub x10, x9, #0x1b 0x0000ffffb66d61cc <+180>: cmp x10, #0x2 0x0000ffffb66d61d0 <+184>: b.cs 0xffffb66d6204 // b.hs, b.nlast 0x0000ffffb66d61d4 <+188>: ldr x22, [x22, #8] 0x0000ffffb66d61d8 <+192>: tst x22, #0x7 0x0000ffffb66d61dc <+196>: b.eq 0xffffb66d61c0 // b.none 0x0000ffffb66d61e0 <+200>: b 0xffffb66d6224 0x0000ffffb66d61e4 <+204>: ldr x8, [x19, #872] 0x0000ffffb66d61e8 <+208>: orr w9, wzr, #0x2 0x0000ffffb66d61ec <+212>: strh w9, [x8, #34] 0x0000ffffb66d61f0 <+216>: ldr x8, [x19, #872] 0x0000ffffb66d61f4 <+220>: str x22, [x8, #40] 0x0000ffffb66d61f8 <+224>: mov x22, x23 0x0000ffffb66d61fc <+228>: bl 0xffffb66d2808 0x0000ffffb66d6200 <+232>: ret 0x0000ffffb66d6204 <+236>: cmp x9, #0x19 0x0000ffffb66d6208 <+240>: b.hi 0xffffb66d6230 // b.pmore 0x0000ffffb66d620c <+244>: orr w10, wzr, #0x1 0x0000ffffb66d6210 <+248>: lsl x9, x10, x9 0x0000ffffb66d6214 <+252>: mov w10, #0x7f00 // #32512 0x0000ffffb66d6218 <+256>: movk w10, #0x280, lsl #16 0x0000ffffb66d621c <+260>: tst x9, x10 0x0000ffffb66d6220 <+264>: b.eq 0xffffb66d6230 // b.none 0x0000ffffb66d6224 <+268>: ldr x8, [x20] 0x0000ffffb66d6228 <+272>: blr x8 0x0000ffffb66d622c <+276>: ret 0x0000ffffb66d6230 <+280>: blr x8 0x0000ffffb66d6234 <+284>: ret End of assembler dump. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 04:52:19 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 04:52:19 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.b1db218d194ab05437e60efff501e145@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.4 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103, MR:146 -------------------------------------+------------------------------------- Changes (by osa1): * status: closed => new * owner: osa1 => (none) * resolution: fixed => Comment: This is still not closed as https://gitlab.haskell.org/ghc/ghc/merge_requests/146 is still not merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 04:54:01 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 04:54:01 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.5794cdfde7c8b65495571a54525e794a@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.4 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103, MR:146 -------------------------------------+------------------------------------- Changes (by osa1): * owner: (none) => osa1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 09:58:18 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 09:58:18 -0000 Subject: [GHC] #16230: API Annotations: more explicit foralls fixup In-Reply-To: <044.42a15601640ae89d68991169845c06ab@haskell.org> References: <044.42a15601640ae89d68991169845c06ab@haskell.org> Message-ID: <059.2ba9249d65878dfaffcbd8312c662632@haskell.org> #16230: API Annotations: more explicit foralls fixup -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => merge Comment: This has landed in master as https://gitlab.haskell.org/ghc/ghc/commit/be15f7457b98fa0378de7e8146c122757f03c4e9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 09:59:20 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 09:59:20 -0000 Subject: [GHC] #16236: API Annotations: AnnAt disconnected for TYPEAPP In-Reply-To: <044.6e93fb3fdb6147571aa02f22e88db26f@haskell.org> References: <044.6e93fb3fdb6147571aa02f22e88db26f@haskell.org> Message-ID: <059.6255e5821ac2e05de12a1d4b946b3665@haskell.org> #16236: API Annotations: AnnAt disconnected for TYPEAPP -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => merge Comment: This has landed in master as https://gitlab.haskell.org/ghc/ghc/commit/cbfc9fcaa33c3b341830962906543dfca1dfedd7 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 10:00:33 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 10:00:33 -0000 Subject: [GHC] #16265: API Annotations: parens anns discarded for `(*)` operator In-Reply-To: <044.e28d1a2b447340e3749a232e774365bf@haskell.org> References: <044.e28d1a2b447340e3749a232e774365bf@haskell.org> Message-ID: <059.12502879d1aab688c9cb85734c7081f2@haskell.org> #16265: API Annotations: parens anns discarded for `(*)` operator -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => merge Comment: This has landed in master as https://gitlab.haskell.org/ghc/ghc/commit/5e9888bd9c22a1315a703f638591b50e657317c4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 10:01:43 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 10:01:43 -0000 Subject: [GHC] #16279: Lexer: Alternate Layout Rule injects actual not virtual braces In-Reply-To: <044.73378e875f9cb441e9847c7b1258c533@haskell.org> References: <044.73378e875f9cb441e9847c7b1258c533@haskell.org> Message-ID: <059.a73f527afa5ba7f3abdbdaec1405cd89@haskell.org> #16279: Lexer: Alternate Layout Rule injects actual not virtual braces -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: #13807 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => merge Comment: This has landed in master as https://gitlab.haskell.org/ghc/ghc/commit/c1cf2693d6efddeeeb813cd8995a1be136800d17 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 15:09:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 15:09:32 -0000 Subject: [GHC] #16299: :info pretty-prints data types with non-Type return kinds oddly Message-ID: <050.f421e184980b9da25695305a6c88a265@haskell.org> #16299: :info pretty-prints data types with non-Type return kinds oddly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider this GHCi session: {{{ $ ghci -XUnboxedTuples GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci λ> :i (##) data (##) :: TYPE ('GHC.Types.TupleRep '[]) = (##) -- Defined in ‘GHC.Prim’ }}} Notice that we're printing `data (##) :: TYPE ('GHC.Types.TupleRep '[]) = (##)`. Yuck! Granted, you can't define an unboxed tuple like this anyway, but the presence of that kind signature (which definitely doesn't belong in a Haskell98-style data declaration) makes things worse. In case if you're wondering if this is an unboxed tuple–specific problem, it's not. This issue also creeps up in the [https://phabricator.haskell.org/D4777 WIP implementation] of unlifted newtypes: {{{ λ> newtype T = MkT Int# λ> :i T newtype T :: TYPE 'IntRep = MkT Int# -- Defined at :5:1 }}} However, as this ticket demonstrates, this problem has existed well before the unlifted newtypes patch, and more importantly, this can be fixed independently of that patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 15:27:29 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 15:27:29 -0000 Subject: [GHC] #16300: Make TH always reify data types with explicit return kinds Message-ID: <050.70c9b424f7be766267055ce293101956@haskell.org> #16300: Make TH always reify data types with explicit return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 8.6.3 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, whenever you reify a data type with Template Haskell, it will return a `DataD`/`NewtypeD` where the return kind information has been set to `Nothing`: {{{ λ> putStrLn $(reify ''Bool >>= stringE . show) TyConI (DataD [] GHC.Types.Bool [] Nothing [NormalC GHC.Types.False [],NormalC GHC.Types.True []] []) }}} One could argue that this isn't a problem since data types always have return kind `Type` anyway. For 99% of data types, this is true. There are a handful of exceptions, such as unboxed tuples (with return kind `TYPE (TupleRep [...])`, but those could be dismissed as unusual special cases. With the advent of [https://phabricator.haskell.org/D4777 unlifted newtypes], however, things become murkier. `UnliftedNewtypes` let you define newtypes like this one: {{{#!hs newtype Foo :: TYPE IntRep where MkFoo :: Int# -> Foo }}} Notice how the return kind is //not// `Type`, but instead `TYPE IntRep`. However, TH reification doesn't clue you in to this fact: {{{ λ> putStrLn $(reify ''Foo >>= stringE . show) TyConI (NewtypeD [] Ghci8.Foo [] Nothing (GadtC [Ghci8.MkFoo] [(Bang NoSourceUnpackedness NoSourceStrictness,ConT GHC.Prim.Int#)] (ConT Ghci8.Foo)) []) }}} Still `Nothing`. There's no easy way in general to determine what the return kind of an unlifted newtype is using TH reification, which is unfortunate. Luckily, I think there's a very simple fix that we could apply here: just have TH reification return `Just ()` instead of `Nothing`! There's no technical reason why TH couldn't do this; the only reason it currently returns `Nothing` is due to historical convention. Moreover, I doubt that this would even break any code in the wild, since `Nothing` doesn't convey any useful information in the context of TH reification anyway. Does this sound reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 16:24:04 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 16:24:04 -0000 Subject: [GHC] #16299: :info pretty-prints data types with non-Type return kinds oddly In-Reply-To: <050.f421e184980b9da25695305a6c88a265@haskell.org> References: <050.f421e184980b9da25695305a6c88a265@haskell.org> Message-ID: <065.a704f07b2527b71d9e3d36aa1d6b759b@haskell.org> #16299: :info pretty-prints data types with non-Type return kinds oddly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/343 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/343 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 16:54:42 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 16:54:42 -0000 Subject: [GHC] #16301: Additions to Control.Exception: withException, displaySomeExceptionType Message-ID: <042.8fc1cecdbbc70adf405222a1864b36a2@haskell.org> #16301: Additions to Control.Exception: withException, displaySomeExceptionType -------------------------------------+------------------------------------- Reporter: dsf | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 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: -------------------------------------+------------------------------------- Requires RankNTypes though. {{{#!haskell -- | Apply a function to whatever @Exception@ type is inside a -- @SomeException at . withException :: forall r. (forall e. Exception e => e -> r) -> SomeException -> r withException f (SomeException e) = f e -- | Use 'withException' to obtain the exception's type name. displaySomeExceptionType :: SomeException -> String displaySomeExceptionType = withException (show . typeOf) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 19:26:40 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 19:26:40 -0000 Subject: [GHC] #15091: Better occurrence analysis for join points In-Reply-To: <046.b9552aa86f100d416522f1043145cf0b@haskell.org> References: <046.b9552aa86f100d416522f1043145cf0b@haskell.org> Message-ID: <061.5a496b83ced64bb5aaabbe8dd2442b3f@haskell.org> #15091: Better occurrence analysis for join points -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints 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 runeks): * cc: runeks (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 20:15:15 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 20:15:15 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.88b289f7e740757b88e16a670bf1ceed@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bodigrim): I believe there are many shiny things which could be done, if we start from the scratch. Unfortunately, we don't. Also, my understanding is that no one has an appetite for visible breaking changes. Can we have it implemented as proposed in PR or as described in comment:19? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 21:23:12 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 21:23:12 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.4aa0cbcbe1b185bff3890c919d11fd8d@haskell.org> #8657: -fregs-graph still has a limit on spill slots -------------------------------------+------------------------------------- Reporter: simonmar | Owner: archblob Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #7679 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/219 -------------------------------------+------------------------------------- Changes (by AndreasK): * status: patch => closed * resolution: => fixed Comment: Fixed in HEAD but likely too late to make it into 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 21:23:29 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 21:23:29 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.391daeca4f05ef16eee8cca86e61d1ec@haskell.org> #8657: -fregs-graph still has a limit on spill slots -------------------------------------+------------------------------------- Reporter: simonmar | Owner: archblob Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #7679 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/219 -------------------------------------+------------------------------------- Changes (by AndreasK): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 21:51:21 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 21:51:21 -0000 Subject: [GHC] #14848: -XDuplicateRecordFields breaks record expression splices In-Reply-To: <048.60548a7facfb2bb72ce43f7899267ddd@haskell.org> References: <048.60548a7facfb2bb72ce43f7899267ddd@haskell.org> Message-ID: <063.a0d0f1320e951ad48940e33392ac7cc3@haskell.org> #14848: -XDuplicateRecordFields breaks record expression splices -------------------------------------+------------------------------------- Reporter: dailectic | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: ORF Operating System: Linux | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11103 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: (none) => adamgundry Comment: > The least invasive option might be to extend `NameFlavour` with a new constructor for field names, which would be rather like `NameG` but would carry the selector name. I've tried this, and it looks like a relatively straightforward change (although we may need an equivalent to `NameL` as well, I'm not sure yet). Will propose a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 10 22:01:02 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Feb 2019 22:01:02 -0000 Subject: [GHC] #16289: GHC thinks pattern match is exhaustive In-Reply-To: <046.eab88b2b678daa30e299a6ea262d8ca5@haskell.org> References: <046.eab88b2b678daa30e299a6ea262d8ca5@haskell.org> Message-ID: <061.da0a0d553d21448d7c3a605f9a91c39b@haskell.org> #16289: GHC thinks pattern match is exhaustive -------------------------------------+------------------------------------- Reporter: dnspies | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): This looks suspiciously like https://ghc.haskell.org/trac/ghc/ticket/15713 (that's about overloaded strings, but otherwise pretty much the same situation). There's something fishy about exhaustiveness checking on overloaded literals in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 01:24:09 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 01:24:09 -0000 Subject: [GHC] #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. In-Reply-To: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> References: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> Message-ID: <062.63af53e076d2c50a2fe8798a4de54f2b@haskell.org> #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Fuuzetsu): We (Tsuru Capital) have decided to offer a bounty for fixing this ticket. Please see https://www.reddit.com/r/haskell/comments/apavqf/experiment_ghc_bug_bounty/ if interested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 03:44:19 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 03:44:19 -0000 Subject: [GHC] #14069: RTS linker maps code as writable In-Reply-To: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> References: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> Message-ID: <061.ec293820e83aa1c7cb983e3e0062a65f@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4817 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rockbmb): I'm preparing a patch to address the remaining changes here, do you mind if I go ahead @qnikst? I'd like to avoid duplicating work you may have already done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 04:35:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 04:35:02 -0000 Subject: [GHC] #16302: A non-function coerced to a function can cause a stg_ap_pp_ret Message-ID: <050.4e97aaffa0d47c8328c100c6b416ce09@haskell.org> #16302: A non-function coerced to a function can cause a stg_ap_pp_ret -------------------------------------+------------------------------------- Reporter: WheatWizard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you create an function by unsafe coercing a non-function you can get some strange functions. If you then take one of these function and apply it something it crashes with a {{{stg_ap_pp_ret}}}. Here is a pretty minimal example. {{{ import Unsafe.Coerce main=(unsafeCoerce()::a->IO())1 }}} You can reproduce it online here: https://tio.run/##y0gszk7Nyfn/PzO3IL at oRCE0rzgxLVXPOT@1KDmVKzcxM89WoxQsBhHS0LSyStS18/TX0NQ0/P8fAA Here is another one: {{{ import Unsafe.Coerce g=unsafeCoerce()::a->a main=print$g(g)1 }}} If you coerce functions this doesn't appear to happen. For example: {{{ import Unsafe.Coerce main=(unsafeCoerce id::a->IO())1 }}} is a fine program. Sometimes this causes a segmentation fault (particularly with higher airity functions): {{{ import Unsafe.Coerce main=(unsafeCoerce(+)::a->IO())1 }}} but I've never gotten it to make a {{{stg_ap_pp_ret}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 05:32:19 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 05:32:19 -0000 Subject: [GHC] #16302: A non-function coerced to a function can cause a stg_ap_pp_ret In-Reply-To: <050.4e97aaffa0d47c8328c100c6b416ce09@haskell.org> References: <050.4e97aaffa0d47c8328c100c6b416ce09@haskell.org> Message-ID: <065.8fa4f1937ed5f4c80771be543505fc6e@haskell.org> #16302: A non-function coerced to a function can cause a stg_ap_pp_ret -------------------------------------+------------------------------------- Reporter: WheatWizard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by potato44): I don't think this counts as a bug because we don't have many guarantees about `unsafeCoerce` besides for newtypes. I think it might be easier for others to read the bug report if you were to ungolf the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 06:12:59 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 06:12:59 -0000 Subject: [GHC] #16302: A non-function coerced to a function can cause a stg_ap_v_ret (was: A non-function coerced to a function can cause a stg_ap_pp_ret) In-Reply-To: <050.4e97aaffa0d47c8328c100c6b416ce09@haskell.org> References: <050.4e97aaffa0d47c8328c100c6b416ce09@haskell.org> Message-ID: <065.a13fe6fac72ebbe3f5106bcaec31a399@haskell.org> #16302: A non-function coerced to a function can cause a stg_ap_v_ret -------------------------------------+------------------------------------- Reporter: WheatWizard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by WheatWizard: Old description: > If you create an function by unsafe coercing a non-function you can get > some strange functions. If you then take one of these function and apply > it something it crashes with a {{{stg_ap_pp_ret}}}. Here is a pretty > minimal example. > > {{{ > import Unsafe.Coerce > main=(unsafeCoerce()::a->IO())1 > }}} > > You can reproduce it online here: > https://tio.run/##y0gszk7Nyfn/PzO3IL at oRCE0rzgxLVXPOT@1KDmVKzcxM89WoxQsBhHS0LSyStS18/TX0NQ0/P8fAA > > Here is another one: > > {{{ > import Unsafe.Coerce > g=unsafeCoerce()::a->a > main=print$g(g)1 > }}} > > If you coerce functions this doesn't appear to happen. > > For example: > > {{{ > import Unsafe.Coerce > main=(unsafeCoerce id::a->IO())1 > }}} > > is a fine program. Sometimes this causes a segmentation fault > (particularly with higher airity functions): > > {{{ > import Unsafe.Coerce > main=(unsafeCoerce(+)::a->IO())1 > }}} > > but I've never gotten it to make a {{{stg_ap_pp_ret}}}. New description: If you create an function by unsafe coercing a non-function you can get some strange functions. If you then take one of these function and apply it something it crashes with a {{{stg_ap_v_ret}}}. Here is a pretty minimal example. {{{ import Unsafe.Coerce main=(unsafeCoerce()::a->IO())1 }}} You can reproduce it online here: https://tio.run/##y0gszk7Nyfn/PzO3IL at oRCE0rzgxLVXPOT@1KDmVKzcxM89WoxQsBhHS0LSyStS18/TX0NQ0/P8fAA Here is another one: {{{ import Unsafe.Coerce g=unsafeCoerce()::a->a main=print$g(g)1 }}} If you coerce functions this doesn't appear to happen. For example: {{{ import Unsafe.Coerce main=(unsafeCoerce id::a->IO())1 }}} is a fine program. Sometimes this causes a segmentation fault (particularly with higher airity functions): {{{ import Unsafe.Coerce main=(unsafeCoerce(+)::a->IO())1 }}} but I've never gotten it to make a {{{stg_ap_v_ret}}}. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 06:16:41 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 06:16:41 -0000 Subject: [GHC] #16302: A non-function coerced to a function can cause a stg_ap_v_ret In-Reply-To: <050.4e97aaffa0d47c8328c100c6b416ce09@haskell.org> References: <050.4e97aaffa0d47c8328c100c6b416ce09@haskell.org> Message-ID: <065.a06d2f5774ab8c5ef52b6423874d89d4@haskell.org> #16302: A non-function coerced to a function can cause a stg_ap_v_ret -------------------------------------+------------------------------------- Reporter: WheatWizard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by WheatWizard): Replying to [comment:1 potato44]: > I don't think this counts as a bug because we don't have many guarantees about `unsafeCoerce` besides for newtypes. > > I think it might be easier for others to read the bug report if you were to ungolf the code. > That seems like a fair assessment. I wouldn't really expect this code to do anything meaningful. In fact a segmentation fault seems like a very likely outcome. But the compiler did ask me to report it so I thought it would be better safe than sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 08:21:19 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 08:21:19 -0000 Subject: [GHC] #16303: checkStack sanity check fails Message-ID: <043.5c62864ddc74f11e27dba9e7181f6bec@haskell.org> #16303: checkStack sanity check fails -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- checkStackChunk() currently has a commented-out assertion: {{{ void checkStackChunk( StgPtr sp, StgPtr stack_end ) { StgPtr p; p = sp; while (p < stack_end) { p += checkStackFrame( p ); } // ASSERT( p == stack_end ); -- HWL } }}} I realized a while ago that if I enable it, it fails in some cases, so I asked Simon Marlow about this. Quoting: > I don't know, but blame says it was disabled by Hans-Wolfgang Loidl as part of > the GUM merge 18 years ago. I suggest just enabling it and debug whatever goes > wrong. This ticket is to enable the assertion and fix bugs. To reproduce, run the test suite: {{{ $ make EXTRA_HC_OPTS='-debug -rtsopts' WAY=sanity }}} Tests that trigger the assertion: - annrun01 - T10508_api - dynCompileExpr Tried with GHC HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 09:29:51 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 09:29:51 -0000 Subject: [GHC] #16052: Core optimizations for memset on a small range In-Reply-To: <049.35f339a100b576d6db7c28659297f61e@haskell.org> References: <049.35f339a100b576d6db7c28659297f61e@haskell.org> Message-ID: <064.201f58b88e8cf72a377bd381ea1d3636@haskell.org> #16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): @andrewthad: Are you still interested in fixing this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 10:26:05 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 10:26:05 -0000 Subject: [GHC] #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. In-Reply-To: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> References: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> Message-ID: <062.7a430e2fcc79178b79822abc73584099@haskell.org> #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I have put a patch up which implements these flags. https://gitlab.haskell.org/ghc/ghc/merge_requests/346 Waiting for CI to run now to see if I missed anything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 10:57:22 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 10:57:22 -0000 Subject: [GHC] #16302: A non-function coerced to a function can cause a stg_ap_v_ret In-Reply-To: <050.4e97aaffa0d47c8328c100c6b416ce09@haskell.org> References: <050.4e97aaffa0d47c8328c100c6b416ce09@haskell.org> Message-ID: <065.4e279647e0001e2fa5fa18a763105e8b@haskell.org> #16302: A non-function coerced to a function can cause a stg_ap_v_ret -------------------------------------+------------------------------------- Reporter: WheatWizard | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11826 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid * related: => #11826 Comment: Indeed, once you start using `unsafeCoerce` in a cavalier fashion like this, you're taking your own life into your hands. The fact that it happened to produce a panic is sheer coincidence—it might have done something even stranger, like segfault. For the reasons explained in #11826 and comment:1, I'm going to mark this as not-a-bug unless there's a compelling reason to believe otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 11:07:51 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 11:07:51 -0000 Subject: [GHC] #14069: RTS linker maps code as writable In-Reply-To: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> References: <046.9e22b0896a2cacfd4a0714e7a6c1497b@haskell.org> Message-ID: <061.f3ba89c7059c845a3ec1b6ebd80dc30a@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4817 Wiki Page: | -------------------------------------+------------------------------------- Comment (by qnikst): @rockbmb, feel free to do that I'm currently stuck on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 11:09:17 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 11:09:17 -0000 Subject: [GHC] #16302: A non-function coerced to a function can cause a stg_ap_v_ret In-Reply-To: <050.4e97aaffa0d47c8328c100c6b416ce09@haskell.org> References: <050.4e97aaffa0d47c8328c100c6b416ce09@haskell.org> Message-ID: <065.d6cc6fdf8e48b9b7632eee6870689f09@haskell.org> #16302: A non-function coerced to a function can cause a stg_ap_v_ret -------------------------------------+------------------------------------- Reporter: WheatWizard | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11826 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Agreed, this is not a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 11:18:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 11:18:00 -0000 Subject: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file. In-Reply-To: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> References: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> Message-ID: <061.d92018b3b68040aa12eab3866a6cb444@haskell.org> #6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ahri): Still broken on OSX - works fine on Linux and Win32 (64). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 12:00:14 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 12:00:14 -0000 Subject: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file. In-Reply-To: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> References: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> Message-ID: <061.2111050665d3613b0cc934528d6100e5@haskell.org> #6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.0.4 (Parser) | Resolution: | Keywords: cpp Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ahri): I've opened a ticket on the Clang bugtracker: https://bugs.llvm.org/show_bug.cgi?id=40689 I wonder if GHC should simply allow leading whitespace as "sh" seems happy enough to accept a file in this form. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 13:04:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 13:04:02 -0000 Subject: [GHC] #16304: Hadrian: refactor libffi and rts rules. Message-ID: <045.af55bfaaffb7f989933383044a4d8298@haskell.org> #16304: Hadrian: refactor libffi and rts rules. -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The rts package depends on libffi. The hadrian rules around this are a bit hacky. The rts needs some specific header files, then the corresponding libffi rule takes on some unsolicited responsibilities, copying some important files into the rts directory. Also see mpickering's [https://gitlab.haskell.org/ghc/ghc/merge_requests/174#note_3288 comment] on this: This whole copying the header files into the rts dir seemed very dodgy to me. Why do we not depend on libffi when building the rts and then copy the files we need in the rules for building the rts? This is a hack implemented partly to get around the issue of not knowing the names of some libffi files until after building libffi. There surely is an idiomatic solution to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 14:38:16 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 14:38:16 -0000 Subject: [GHC] #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase In-Reply-To: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> References: <045.fddeda88cbbf2d7fe6e80239e545036b@haskell.org> Message-ID: <060.24cfb72c2124508c25adf05d617809ec@haskell.org> #16257: -fexternal-interpreter with external C shared library leads to undefined symbol during template haskell phase -------------------------------------+------------------------------------- Reporter: guibou | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by concert): I think I am seeing the same issue via a slightly different route. I've got a package that builds and binds some C and sets `extra-lib-dirs` in its package.yaml. In a module depending on it I get the "can't load .so/.DLL" error when using template haskell (or in my case quasiquotes). The library I depend on to trigger is here (you will need meson to build it): https://gitlab.com/concert/hs-rage This may be packaged wrong, being my first stab at something like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 14:43:29 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 14:43:29 -0000 Subject: [GHC] #16198: Cmm string literals shouldn't be represented as [Word8] In-Reply-To: <045.eab390ea1c7447194f424f58669324ce@haskell.org> References: <045.eab390ea1c7447194f424f58669324ce@haskell.org> Message-ID: <060.10016a80fb89eb019b35d23427a03e28@haskell.org> #16198: Cmm string literals shouldn't be represented as [Word8] -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: patch => closed * resolution: => fixed Comment: Merged with 4fa32293c9d2658ce504b8fe6d909db2acf59983 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 15:16:38 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 15:16:38 -0000 Subject: [GHC] #16166: Compiling with profiling on Windows can cause linker errors In-Reply-To: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> References: <047.ccc783008e11e5abafdcb023eaef5d3d@haskell.org> Message-ID: <062.95125a6a4e44c1784bad2d9aa823ae7f@haskell.org> #16166: Compiling with profiling on Windows can cause linker errors -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/225 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 15:17:13 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 15:17:13 -0000 Subject: [GHC] #16104: Plugin name lookup behavior change from GHC 8.4 series In-Reply-To: <045.39ad726a4f99f2525b5422855351a024@haskell.org> References: <045.39ad726a4f99f2525b5422855351a024@haskell.org> Message-ID: <060.f2302371a648a20179095251ad942f1b@haskell.org> #16104: Plugin name lookup behavior change from GHC 8.4 series -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.4 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: comment:7 merged to `master` with 0d9f105ba423af4f2ca215a18d04d4c8e2c372a8. comment:6 merged to `ghc-8.6` with 8c2dbc161572b59498a9d7abe444e65973069ef7, comment:7 with 5abfd982f55287b24fd71a5d60a2e3d0e361e47e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 15:23:46 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 15:23:46 -0000 Subject: [GHC] #16303: checkStack sanity check fails In-Reply-To: <043.5c62864ddc74f11e27dba9e7181f6bec@haskell.org> References: <043.5c62864ddc74f11e27dba9e7181f6bec@haskell.org> Message-ID: <058.b3e202564e586010f1c48a6d2d8fe6cf@haskell.org> #16303: checkStack sanity check fails -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch Comment: MR at https://gitlab.haskell.org/ghc/ghc/merge_requests/349 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 16:55:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 16:55:00 -0000 Subject: [GHC] #16052: Core optimizations for memset on a small range In-Reply-To: <049.35f339a100b576d6db7c28659297f61e@haskell.org> References: <049.35f339a100b576d6db7c28659297f61e@haskell.org> Message-ID: <064.4acbbff7af15ff3b73555e911e95f263@haskell.org> #16052: Core optimizations for memset on a small range -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.9 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Thanks for following up. I won't be trying to do this anytime soon, so if anyone else has the desire to do this, go for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 17:09:56 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 17:09:56 -0000 Subject: [GHC] #16282: all-missed-specializations doesn't suggest warning In-Reply-To: <047.dd59e0ffb2b5e177646617818ff04a7f@haskell.org> References: <047.dd59e0ffb2b5e177646617818ff04a7f@haskell.org> Message-ID: <062.958b1438bcb8425751eba5ed1257b0e9@haskell.org> #16282: all-missed-specializations doesn't suggest warning -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/350/diffs -------------------------------------+------------------------------------- Changes (by crockeea): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/350/diffs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 17:12:20 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 17:12:20 -0000 Subject: [GHC] #16190: Speed up handling of large String literals In-Reply-To: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> References: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> Message-ID: <060.d89de33a4a13b33f5fd4d7f1ffd54ae0@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/143 -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/143 Comment: MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/143 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 17:15:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 17:15:34 -0000 Subject: [GHC] #16274: Remove ghctags In-Reply-To: <051.60fcdc3e4ceedcac5234a746e3c693c6@haskell.org> References: <051.60fcdc3e4ceedcac5234a746e3c693c6@haskell.org> Message-ID: <066.73f883ef2a7a397556f0796df0a019bf@haskell.org> #16274: Remove ghctags -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: None | Version: 8.6.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/305 -------------------------------------+------------------------------------- Changes (by hsyl20): * status: patch => closed * resolution: => fixed Comment: Merged in `master` as 027017fb33923b106765f5a0a6fc000ebe421d40 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 17:47:20 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 17:47:20 -0000 Subject: [GHC] #16300: Make TH always reify data types with explicit return kinds In-Reply-To: <050.70c9b424f7be766267055ce293101956@haskell.org> References: <050.70c9b424f7be766267055ce293101956@haskell.org> Message-ID: <065.4fae3ac74827a68ad95c24f5dd36ac92@haskell.org> #16300: Make TH always reify data types with explicit return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): A different (but closely related) issue is that currently, this is rejected: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH $(pure [DataD [] (mkName "D") [] (Just StarT) [NormalC (mkName "MkD") []] []]) }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:3: error: Kind signatures are only allowed on GADTs When splicing a TH declaration: data D :: * = MkD | 7 | $(pure [DataD [] (mkName "D") [] (Just StarT) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} This restriction feels somewhat artificial, given that GHC can't even parse Haskell98-style declarations with explicit kind signatures in the first place (ignore the bit about `data D :: * = MkD`, as that's just a pretty-printing mistake). Indeed, the `Maybe Kind` field of `DataD`/`NewtypeD` //only// makes sense if the data type happens to be a GADT. If it's not a GADT, surely it doesn't do any harm to just ignore the `Maybe Kind`, right? I care about this since changing TH reification to always fill in the `Maybe Kind` field with `Just <...>` causes the `TH_spliceDecl3` test case to start failing with the "`Kind signatures are only allowed on GADTs`" error. If you look at the implementation of the test, you'll see why: {{{ -- test splicing of reified and renamed data declarations module TH_spliceDecl3 where import Language.Haskell.TH import TH_spliceDecl3_Lib data T = C $(do { TyConI d <- reify ''T; rename' d}) }}} It's reifying `T` (a Haskell98 data type) and then immediately splicing back in. Due to the aforementioned restriction about kinds, however, this fails. We could dig into the reified AST and change `Just Type` to `Nothing` before splicing it back it, but this feels like a lot of unnecessary work. I propose that we just drop this restriction as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 17:53:27 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 17:53:27 -0000 Subject: [GHC] #13208: Do two-phase inlining in simpleOptPgm In-Reply-To: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> References: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> Message-ID: <064.305b7ebdb6db8c37f3bb37d41fe47958@haskell.org> #13208: Do two-phase inlining in simpleOptPgm -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bjmprice): What's the status of this ticket? I ask because in `Note [The simple optimiser]`, it is claimed that "It thereby guarantees to leave no un- reduced beta-redexes.", but in 8.6.3 the Haskell `beta = let f = \x -> x in f True` gives rise to the Core `beta = (\ (x_aVG :: Bool) -> x_aVG) GHC.Types.True`, which seems to contradict that claim. (This core is with `-ddump-ds`, which I think runs the simple optimiser. With `-ddump-ds-preopt` it is a let-binding, not a beta-redex.) I guess that the Note could mean that "all beta-redexes in the input are reduced", rather than "there are no beta-redexes in the output", but this isn't how I understood the text. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 17:54:13 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 17:54:13 -0000 Subject: [GHC] #13208: Do two-phase inlining in simpleOptPgm In-Reply-To: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> References: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> Message-ID: <064.2465ec56909dacda570c6cab9e993553@haskell.org> #13208: Do two-phase inlining in simpleOptPgm -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints 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 bjmprice): * cc: bjmprice (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 17:56:36 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 17:56:36 -0000 Subject: [GHC] #16300: Make TH always reify data types with explicit return kinds In-Reply-To: <050.70c9b424f7be766267055ce293101956@haskell.org> References: <050.70c9b424f7be766267055ce293101956@haskell.org> Message-ID: <065.bba2e86b7c5502a956eee8306cb33405@haskell.org> #16300: Make TH always reify data types with explicit return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): As further evidence for how //ad hoc// the restriction in comment:1 is, if I change the program to use `NewtypeD` instead: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH $(pure [NewtypeD [] (mkName "D") [] (Just StarT) (NormalC (mkName "MkD") [(Bang NoSourceUnpackedness NoSourceStrictness, ConT ''Int)]) []]) }}} Then GHC accepts it without issue! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 18:07:06 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 18:07:06 -0000 Subject: [GHC] #16300: Make TH always reify data types with explicit return kinds In-Reply-To: <050.70c9b424f7be766267055ce293101956@haskell.org> References: <050.70c9b424f7be766267055ce293101956@haskell.org> Message-ID: <065.44c525adc46f0991bef752947a77bed7@haskell.org> #16300: Make TH always reify data types with explicit return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, but the program in comment:2 is accepted for different reasons than what I expected. It's not being accepted due to the fact that `Just StarT` is ignored. In fact, GHC //is// checking the explicit return kind! This is demonstrated by this program, which tries to sneak in something bogus: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH $(pure [NewtypeD [] (mkName "D") [] (Just (ArrowT `AppT` ConT ''Maybe `AppT` StarT)) (NormalC (mkName "MkD") [(Bang NoSourceUnpackedness NoSourceStrictness, ConT ''Int)]) []]) }}} {{{ GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:8:3: error: • Expecting one more argument to ‘Maybe’ Expected a type, but ‘Maybe’ has kind ‘* -> *’ • In the kind ‘Maybe -> GHC.Types.Type’ | 8 | $(pure [NewtypeD [] (mkName "D") [] (Just (ArrowT `AppT` ConT ''Maybe `AppT` StarT)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} I suppose this reveals another viable alternative. We could just treat the program in comment:1 as though we were trying to splice in a GADT (i.e., `newtype D :: Type where MkD :: D`). Granted, we'd then be splicing in a GADT using `NormalC` instead of the usual `GadtC`, but there's no reason why we couldn't reinterpret `NormalC` as though it were specifying a GADT constructor. ...except there's another weird thing that `Convert` does in which it rejects mixed uses of `NormalC` and `GadtC`: {{{#!hs ; unless (isGadtDecl || isH98Decl) (failWith (text "Cannot mix GADT constructors with Haskell 98" <+> text "constructors")) }}} This suggests that if we want to pursue this direction, then we should further lift this mixed constructors restriction. Hm... I'm not sure which route to go down. Do others have any thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 18:13:08 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 18:13:08 -0000 Subject: [GHC] #8657: -fregs-graph still has a limit on spill slots In-Reply-To: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> References: <047.d29c2fd8f8c4c83bf5493d9abc3a1631@haskell.org> Message-ID: <062.35248076e2d4c0cad3632705eafb5678@haskell.org> #8657: -fregs-graph still has a limit on spill slots -------------------------------------+------------------------------------- Reporter: simonmar | Owner: archblob Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler (NCG) | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #7679 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/219 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.8.1 Comment: I'm happy to merge this for 8.8 but let's hold off on 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 18:29:38 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 18:29:38 -0000 Subject: [GHC] #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock In-Reply-To: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> References: <048.a8200ccd32dc88ac96567a97fcb71b76@haskell.org> Message-ID: <063.15418f3d9d21f1a6be6c503e20667604@haskell.org> #16239: hadrian fails to "build" _build/docs/html/libraries/base/base.haddock -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/248 -------------------------------------+------------------------------------- Changes (by alpmestan): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 18:43:56 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 18:43:56 -0000 Subject: [GHC] #16305: When should -Wmissed-specializations fire? Message-ID: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> #16305: When should -Wmissed-specializations fire? -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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: -------------------------------------+------------------------------------- While working on a fix for #16282, I noticed: 1. that `-Wmissed-specializations` doesn't fire when the docs say it should 2. that the "probable fix" suggested when a warning does fire is highly suspect {{{ import Data.Map main :: IO () main = do let m = [] :: [Map String Bool] mapM_ print m }}} With GHC 8.4.3, 8.6.3, and HEAD: `ghc -O2 -Wmissed-specializations Main.hs` does *not* issue any warnings. However, `ghc -O2 -Wall-missed-specializations Main.hs` *does* create a warning: {{{ Main.hs: warning: [-Wall-missed-specialisations] Could not specialise imported function ‘Data.Map.Internal.$w$cshowsPrec’ when specialising ‘Data.Map.Internal.$fShowMap_$cshowsPrec’ Probable fix: add INLINABLE pragma on ‘Data.Map.Internal.$w$cshowsPrec’ }}} The docs for `-Wmissed-specializations` say, "warn when specialisation of an imported, overloaded function fails." Since `showsPrec` is an imported function, it seems that a warning should have been issued with `-Wmissed- specs`. My reading of the docs is that `-Wall-missed-specs` should output everything `-Wmissed-specs` does, along with any *local* overloaded and unspecialized functions. Moreover, the "Probable fix" is suspect. A warning recommending an `INLINABLE` pragma is issued depending on the output of `warnMissedSpec` in specialise/Specialise.hs. For `-Wall-missed-specs`, `warnMissedSpec` doesn't check if an INLINABLE pragma is already present, so the fix could be redundant. For `-Wmissed-specs`, `warnMissedSpecs` *only* issues a warning if there *is* any inline pragma (of one sort of another) on all the callers, making the `probable fix` definitely redundant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 18:55:32 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 18:55:32 -0000 Subject: [GHC] #16305: When should -Wmissed-specializations fire? In-Reply-To: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> References: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> Message-ID: <062.f89ee213aad626fa4dbd19034d82f3c8@haskell.org> #16305: When should -Wmissed-specializations fire? -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 crockeea): I should point out that the fact that `-Wmissed-specs` doesn't create a warning in the example above seems to (according to the code) be due to `showsPrec` not having any type of inline pragma. The following evaluates to `False` on `f=showsPrec`: `has_inline_prag f = isAnyInlinePragma (idInlinePragma f)` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 19:04:45 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 19:04:45 -0000 Subject: [GHC] #7679: Regression in -fregs-graph performance In-Reply-To: <047.9e26897513125de7441d596a4b30ee54@haskell.org> References: <047.9e26897513125de7441d596a4b30ee54@haskell.org> Message-ID: <062.65af3261aa1afd8c97cceef699ec6f47@haskell.org> #7679: Regression in -fregs-graph performance -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7192, #8657 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanessamchale): * cc: vanessa.mchale@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 19:06:47 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 19:06:47 -0000 Subject: [GHC] #16305: When should -Wmissed-specializations fire? In-Reply-To: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> References: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> Message-ID: <062.ba2028151c8c1aafe89de9a2cecc073a@haskell.org> #16305: When should -Wmissed-specializations fire? -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > While working on a fix for #16282, I noticed: > > 1. that `-Wmissed-specializations` doesn't fire when the docs say it > should > 2. that the "probable fix" suggested when a warning does fire is highly > suspect > > > {{{ > import Data.Map > main :: IO () > main = do > let m = [] :: [Map String Bool] > mapM_ print m > }}} > > With GHC 8.4.3, 8.6.3, and HEAD: > `ghc -O2 -Wmissed-specializations Main.hs` does *not* issue any warnings. > > However, `ghc -O2 -Wall-missed-specializations Main.hs` *does* create a > warning: > {{{ > Main.hs: warning: [-Wall-missed-specialisations] > Could not specialise imported function > ‘Data.Map.Internal.$w$cshowsPrec’ > when specialising ‘Data.Map.Internal.$fShowMap_$cshowsPrec’ > Probable fix: add INLINABLE pragma on > ‘Data.Map.Internal.$w$cshowsPrec’ > }}} > > The docs for `-Wmissed-specializations` say, "warn when specialisation of > an imported, overloaded function fails." Since `showsPrec` is an imported > function, it seems that a warning should have been issued with `-Wmissed- > specs`. My reading of the docs is that `-Wall-missed-specs` should output > everything `-Wmissed-specs` does, along with any *local* overloaded and > unspecialized functions. > > Moreover, the "Probable fix" is suspect. A warning recommending an > `INLINABLE` pragma is issued depending on the output of `warnMissedSpec` > in specialise/Specialise.hs. For `-Wall-missed-specs`, `warnMissedSpec` > doesn't check if an INLINABLE pragma is already present, so the fix could > be redundant. For `-Wmissed-specs`, `warnMissedSpecs` *only* issues a > warning if there *is* any inline pragma (of one sort of another) on all > the callers, making the `probable fix` definitely redundant. New description: While working on a fix for #16282, I noticed: 1. that `-Wmissed-specializations` doesn't fire when the docs say it should 2. that the "probable fix" suggested when a warning does fire is highly suspect {{{ import Data.Map main :: IO () main = do let m = [] :: [Map String Bool] mapM_ print m }}} With GHC 8.4.3, 8.6.3, and HEAD: `ghc -O2 -Wmissed-specializations Main.hs` does *not* issue any warnings. However, in 8.6.3 and HEAD, `ghc -O2 -Wall-missed-specializations Main.hs` *does* create a warning: {{{ Main.hs: warning: [-Wall-missed-specialisations] Could not specialise imported function ‘Data.Map.Internal.$w$cshowsPrec’ when specialising ‘Data.Map.Internal.$fShowMap_$cshowsPrec’ Probable fix: add INLINABLE pragma on ‘Data.Map.Internal.$w$cshowsPrec’ }}} The docs for `-Wmissed-specializations` say, "warn when specialisation of an imported, overloaded function fails." Since `showsPrec` is an imported function, it seems that a warning should have been issued with `-Wmissed- specs`. My reading of the docs is that `-Wall-missed-specs` should output everything `-Wmissed-specs` does, along with any *local* overloaded and unspecialized functions. Moreover, the "Probable fix" is suspect. A warning recommending an `INLINABLE` pragma is issued depending on the output of `warnMissedSpec` in specialise/Specialise.hs. For `-Wall-missed-specs`, `warnMissedSpec` doesn't check if an INLINABLE pragma is already present, so the fix could be redundant. For `-Wmissed-specs`, `warnMissedSpecs` *only* issues a warning if there *is* any inline pragma (of one sort of another) on all the callers, making the `probable fix` definitely redundant. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 19:36:22 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 19:36:22 -0000 Subject: [GHC] #16306: Hadrian: First test after a full rebuild normally fails due to an additional stdout line Message-ID: <049.3c4b1c797246bc27fd2a35aaddab357f@haskell.org> #16306: Hadrian: First test after a full rebuild normally fails due to an additional stdout line -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After pulling down the lates updates to my local GHC tree, I normally do the following: {{{ hadrian/build.sh clean hadrian/build.sh --flavour=devel2 -j4 hadrian/build.sh test --flavour=devel2 --freeze1 --only=T99999 }}} The first test fails with: `Actual stdout output differs from expected:` stdout contains an additonal line, obviously generated by Hadrian: {{{ +Linking /home/roland/Projekte/ghc/testsuite/mk/ghc-config ... }}} When I rerun the test, Hadrian does not re-link `ghc-config` and everything works fine! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 20:00:26 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 20:00:26 -0000 Subject: [GHC] #16300: Make TH always reify data types with explicit return kinds In-Reply-To: <050.70c9b424f7be766267055ce293101956@haskell.org> References: <050.70c9b424f7be766267055ce293101956@haskell.org> Message-ID: <065.c65b1a8254e7aabad587f73a85fe95a5@haskell.org> #16300: Make TH always reify data types with explicit return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I favor keeping the no-mixed-constructors and no-kind-sig-without-GADT- constructors restrictions: they keep TH closer to Haskell. I feel like every time TH diverges from Haskell, we regret it later. So, returning to the original question: how about non-`Type`-kinded datatypes/newtypes always reify as GADTs? The choice of syntax in reification is immaterial, so let's just change it. Also, we should reject the example in comment:2, as it would be rejected in Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 21:03:30 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 21:03:30 -0000 Subject: [GHC] #16300: Make TH always reify data types with explicit return kinds In-Reply-To: <050.70c9b424f7be766267055ce293101956@haskell.org> References: <050.70c9b424f7be766267055ce293101956@haskell.org> Message-ID: <065.72d2622ed5fa7f63a2b27fd4d5e6bb43@haskell.org> #16300: Make TH always reify data types with explicit return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:4 goldfire]: > how about non-`Type`-kinded datatypes/newtypes always reify as GADTs? The choice of syntax in reification is immaterial, so let's just change it. I can see the appeal behind this choice, but at the same time, I would be a little sad if we went in this direction. Generally speaking, I like keeping TH reification as honest as possible. Moreover, whether a data type is declared as a GADT or not has some consequences on its other properties. For instance, the derived `Show` instance for a data type with infix constructors changes depending on whether the type is a GADT, and unless consumers have a reliable way to reify whether or not a data type is a GADT, they wouldn't be able to replicate what `deriving Show` does with Template Haskell, which would be a bit sad. I really wish that we had top-level kind signatures, since then we could just reify `type Foo :: TYPE IntRep`, regardless of whether `Foo` was defined using Haskell98 or GADT syntax. I suppose we could just park this ticket until that becomes a reality. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 21:15:21 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 21:15:21 -0000 Subject: [GHC] #16300: Make TH always reify data types with explicit return kinds In-Reply-To: <050.70c9b424f7be766267055ce293101956@haskell.org> References: <050.70c9b424f7be766267055ce293101956@haskell.org> Message-ID: <065.0e18954efe4a4d6145d4a0d64219c337@haskell.org> #16300: Make TH always reify data types with explicit return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): > I suppose we could just park this ticket until that becomes a reality. That sounds like as good an idea of any of these others. Actually, maybe it would be better to have `qTypeKind :: Type -> Q Kind` and `qExprType :: Exp -> Q Type`. Then, we can avoid this whole kerfuffle for unlifted newtypes by requiring clients to just get the kind of the argument. Note that these two functions would not be particularly hard to write but would be very useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 21:33:56 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 21:33:56 -0000 Subject: [GHC] #16300: Make TH always reify data types with explicit return kinds In-Reply-To: <050.70c9b424f7be766267055ce293101956@haskell.org> References: <050.70c9b424f7be766267055ce293101956@haskell.org> Message-ID: <065.8776cb6f74d37bd11f1e3f36c558944a@haskell.org> #16300: Make TH always reify data types with explicit return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:6 goldfire]: > Actually, maybe it would be better to have `qTypeKind :: Type -> Q Kind` and `qExprType :: Exp -> Q Type`. Then, we can avoid this whole kerfuffle for unlifted newtypes by requiring clients to just get the kind of the argument. That's an intriguing idea. > Note that these two functions would not be particularly hard to write but would be very useful. While I imagine one could implement these functions, I wonder what their specification should be. What should they do if their inputs are ill typed, for instance? Also, the answers that they return might change depending on whether certain language extensions are enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 21:44:30 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 21:44:30 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.9ba17f4881d2267a7ff53630d8ad00c0@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rockbmb): I've pinged a maintainer on the GitHub's PR page, I would also like to either close or move forward with this, either as it currently is or with @Bodigrim's change. More elaborate changes can always come afterwards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 21:49:13 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 21:49:13 -0000 Subject: [GHC] #16300: Make TH always reify data types with explicit return kinds In-Reply-To: <050.70c9b424f7be766267055ce293101956@haskell.org> References: <050.70c9b424f7be766267055ce293101956@haskell.org> Message-ID: <065.1da3f71e1ec5ed63c0aff65dfd7879b0@haskell.org> #16300: Make TH always reify data types with explicit return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Note that they are in the `Q` monad: there's no claim to purity here. This means it's reasonable for the behavior to depend on extensions, etc. I suppose this could be a specification: they return the information that `:t` or `:k` would return. And that could also essentially be the implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 22:30:47 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 22:30:47 -0000 Subject: [GHC] #16305: When should -Wmissed-specializations fire? In-Reply-To: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> References: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> Message-ID: <062.7650e8b7b2dfdc1f36910f45f966504d@haskell.org> #16305: When should -Wmissed-specializations fire? -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 mpickering): It seems to me that `-Wmissed-specs` should warn when a function which has an `INLINABLE` pragma on fails to specialise for some reason and `-Wall- missed-specs` should warn whenever an overloaded function fails to specialise. Is that what the implementation does? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 11 22:54:55 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Feb 2019 22:54:55 -0000 Subject: [GHC] #16305: When should -Wmissed-specializations fire? In-Reply-To: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> References: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> Message-ID: <062.a2d28b3904d83cb91cc5597009f1cdd0@haskell.org> #16305: When should -Wmissed-specializations fire? -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 crockeea): Nearly. `-Wmissed-specs` warns when an *imported* function which has *any* "inline" pragma (haven't dug into which are allowed) doesn't get specialized. `-Wall-missed-specs` warns whenever any overloaded function fails to specialize, exactly as you say. Questions are: 1. Should `-Wmissed-specs` warn in the example above? 2. What should the "Probable fix" be for either flag? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 04:09:28 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 04:09:28 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.9d75165c73e41ae4c2385bab1322cb75@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752, #12506, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Comment (by pingu): Replying to [comment:58 hussein.aitlahcen]: > Hello everyone, > > My team experienced the same issue when using Squeal extensively (https://github.com/morphismtech/squeal). My team appears to be experiencing the same issue using Beam migrations. Beam is a similar library to Squeal which makes heavy use of type families (https://tathougies.github.io/beam/)... I found this ticket whilst trying to work out why GHC was spending so much time and memory simplifying. > ... Because of that, GHC was taking **12gb+** to compile some files. I found that omitting the interfaces pragmas with `-fomit-interface-pragmas` was helping a lot. In fact, no more unfolded type in the interface file, making the dumped .txt file going from **3.5gb** to **700kb** with a maximum allocated memory of **2.5gb**. This flag reduced our maximum residency from ~= 14GB down to ~= 10GB, and compile times roughly halved. Thank you very much for this tip, it's stopped us swapping during compilation for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 04:47:54 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 04:47:54 -0000 Subject: [GHC] #16307: gloss-examples' fluid program takes close to an eternity to compile Message-ID: <046.47ebd2e32d20033c7ee60c2f552b77f1@haskell.org> #16307: gloss-examples' fluid program takes close to an eternity to compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It has been over ten minutes and 16 GB of residency and `ghc` `master` still hasn't finished. We should investigate this; something seems very wrong. https://github.com/bgamari/gloss/tree/d863394df7b5a9400f2c2fae08fdbb07c91c6822 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 06:34:04 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 06:34:04 -0000 Subject: [GHC] #16263: GHC accepts illegal constraint in kind In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.0f333ae49fb4868b96666f6d9b9d6983@haskell.org> #16263: GHC accepts illegal constraint in kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | 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 RyanGlScott): Thoughts on comment:5, simonpj? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 06:38:19 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 06:38:19 -0000 Subject: [GHC] #16075: Weverything ignores some OPTIONS_GHC flags In-Reply-To: <047.71239b51b70aad041042b035411a0e7b@haskell.org> References: <047.71239b51b70aad041042b035411a0e7b@haskell.org> Message-ID: <062.35869e884780b5f9f281b0ecfef097cd@haskell.org> #16075: Weverything ignores some OPTIONS_GHC flags -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * status: new => closed * resolution: => invalid Comment: Upon further review, I do not think there is a bug here. The problem appears to be that when using `-Wall`, a `-Wmissing-signature` warning is issued, thus adding the pragma makes the warning go away. But with the same pragma and `-Weverything`, a `-Wmissing-exported-signature` is issued, which the pragma doesn't affect. I just missed that the warning changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 08:00:52 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 08:00:52 -0000 Subject: [GHC] #16293: Inconsistencies and oddities of Proxy# In-Reply-To: <050.2f25f16e44a73b8047b8a62971a2da19@haskell.org> References: <050.2f25f16e44a73b8047b8a62971a2da19@haskell.org> Message-ID: <065.3bdf793c66ceb658ac3c61441e44eb1e@haskell.org> #16293: Inconsistencies and oddities of Proxy# -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | primops/should_compile/T16293a, | th/T16293b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/334 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => primops/should_compile/T16293a, th/T16293b * resolution: => fixed * milestone: => 8.10.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/012257c15f584069500af2953ab70856f9a1470e 012257c15f584069500af2953ab70856f9a1470e]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 08:09:26 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 08:09:26 -0000 Subject: [GHC] #16188: GHC HEAD-only panic (buildKindCoercion) In-Reply-To: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> References: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> Message-ID: <065.a7c80759addea89636e48fc0a37e4b1c@haskell.org> #16188: GHC HEAD-only panic (buildKindCoercion) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T16188 Blocked By: | Blocking: Related Tickets: #16204, #16225 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/207 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => typecheck/should_compile/T16188 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/4a4ae70f09009c5d32696445a06eacb273f364b5 4a4ae70f09009c5d32696445a06eacb273f364b5]. Please merge this into 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 08:12:10 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 08:12:10 -0000 Subject: [GHC] #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) In-Reply-To: <050.809cff7906dca54b71168422e3269d5a@haskell.org> References: <050.809cff7906dca54b71168422e3269d5a@haskell.org> Message-ID: <065.3c11c4491586862db82252ae71a1c75a@haskell.org> #16204: GHC HEAD-only Core Lint error (Argument value doesn't match argument type) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T16204{a,b}, | typecheck/should_fail/T16204c Blocked By: | Blocking: Related Tickets: #16188, #16225 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/207 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => typecheck/should_compile/T16204{a,b}, typecheck/should_fail/T16204c Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/4a4ae70f09009c5d32696445a06eacb273f364b5 4a4ae70f09009c5d32696445a06eacb273f364b5]. Please merge this into 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 08:13:13 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 08:13:13 -0000 Subject: [GHC] #16225: GHC HEAD-only Core Lint error (Trans coercion mis-match) In-Reply-To: <050.51ee2352f2a4dae51e64e4bda9769d8b@haskell.org> References: <050.51ee2352f2a4dae51e64e4bda9769d8b@haskell.org> Message-ID: <065.6867fe29261bbf5a034354c8ca4b7cda@haskell.org> #16225: GHC HEAD-only Core Lint error (Trans coercion mis-match) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T16225 Blocked By: | Blocking: Related Tickets: #16188, #16204 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/207 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => typecheck/should_compile/T16225 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/4a4ae70f09009c5d32696445a06eacb273f364b5 4a4ae70f09009c5d32696445a06eacb273f364b5]. Please merge this into 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 08:18:04 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 08:18:04 -0000 Subject: [GHC] #16299: :info pretty-prints data types with non-Type return kinds oddly In-Reply-To: <050.f421e184980b9da25695305a6c88a265@haskell.org> References: <050.f421e184980b9da25695305a6c88a265@haskell.org> Message-ID: <065.779efac8ce7d66998854b9884e435899@haskell.org> #16299: :info pretty-prints data types with non-Type return kinds oddly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T7627 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/343 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => ghci/scripts/T7627 * resolution: => fixed * milestone: => 8.10.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/8b476d822e97cfe4cebe6e74924d9a79148d608c 8b476d822e97cfe4cebe6e74924d9a79148d608c]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 11:55:42 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 11:55:42 -0000 Subject: [GHC] #16263: GHC accepts illegal constraint in kind In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.3f9f12828d3eae348f60fac5bc112d43@haskell.org> #16263: GHC accepts illegal constraint in kind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | 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 simonpj): Thanks for the ping. Fixing this will fit right into my work on #16185 (see `wip/T16185`) where I have already written new Notes on constraints in kinds. I'll adjust `TcValidity` to reject this kind up-front, as you suggest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 11:57:15 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 11:57:15 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.20291d4a6da0fd552809cc572c231620@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752, #12506, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ben: you have a patch in flight for this don't you? It'd be great to resurrect it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 12:04:35 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 12:04:35 -0000 Subject: [GHC] #16263: Rework GHC's treatment of constraints in kinds (was: GHC accepts illegal constraint in kind) In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.fef957ea446bf02301783ea2f0a7d360@haskell.org> #16263: Rework GHC's treatment of constraints in kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | 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: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * milestone: 8.8.1 => 8.10.1 * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/128 Comment: Replying to [comment:7 simonpj]: > Thanks for the ping. Fixing this will fit right into my work on #16185 (see `wip/T16185`) where I have already written new Notes on constraints in kinds. OK, I didn't realize that you were directly working on fixing this. In that case, I'll retitle this ticket to reflect your more ambitious goals. > I'll adjust `TcValidity` to reject this kind up-front, as you suggest. By "this kind", I assume you mean `Eq a => Type` from the original example? If so, yes, rejecting that (and adding a test case for it) would be wonderful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 12:08:01 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 12:08:01 -0000 Subject: [GHC] #16305: When should -Wmissed-specializations fire? In-Reply-To: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> References: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> Message-ID: <062.19ca6ab965e2ca00bf35e6b23a320b55@haskell.org> #16305: When should -Wmissed-specializations fire? -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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): For what it's worth, here's the Note in `Specialise.hs` {{{ {- Note [Warning about missed specialisations] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Suppose * In module Lib, you carefully mark a function 'foo' INLINABLE * Import Lib(foo) into another module M * Call 'foo' at some specialised type in M Then you jolly well expect it to be specialised in M. But what if 'foo' calls another function 'Lib.bar'. Then you'd like 'bar' to be specialised too. But if 'bar' is not marked INLINABLE it may well not be specialised. The warning Opt_WarnMissedSpecs warns about this. It's more noisy to warning about a missed specialisation opportunity for /every/ overloaded imported function, but sometimes useful. That is what Opt_WarnAllMissedSpecs does. ToDo: warn about missed opportunities for local functions. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 12:09:42 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 12:09:42 -0000 Subject: [GHC] #16263: Rework GHC's treatment of constraints in kinds In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.1c5a70a9ade09291f7cdf1ca9845ef16@haskell.org> #16263: Rework GHC's treatment of constraints in kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | 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: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Comment (by simonpj): > By "this kind", I assume you mean Eq a => Type from the original example? If so, yes, rejecting that (and adding a test case for it) would be wonderful. Yes, exactly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 12:24:59 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 12:24:59 -0000 Subject: [GHC] #16305: When should -Wmissed-specializations fire? In-Reply-To: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> References: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> Message-ID: <062.9eb0ecd77c690cea4c6e6e6b089f0015@haskell.org> #16305: When should -Wmissed-specializations fire? -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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): As I read the code it is trying to do this: * `-Wall-missed-specs`: warn about ''any'' overloaded imported functions that cannot be specialised. Usually this means we don't have its RHS. * `-Wmissed-specs`: warn about any overloaded imported functions that can't be specialised, and is transitively called by a chain of imported functions each with an INLINEABLE pragma. For the latter consider {{{ module A where import B foo = f (3::Int) + g (4::Int) module B where f :: Num a => a -> a {-# INLINABLE f #-} f x = h x g x = Num a => a -> a g x = blah h x :: Num a => a -> a h x = blah }}} Then when compiling A, `-Wmissed-specs` is supposed to * Not warn about not-specialising `g`, because `g` didn't have an INLINABLE pragma. * Warn about non-specialising `h` because `f` (which is directly called from A) has a careful `INLINABLE` pragma, but `h` (perhaps due to an oversight) does not. In contrast `-Wall-missed-specs` should warn about both. Does that make sense? Is it what we want? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 13:46:39 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 13:46:39 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.8b73fa5a69c7f13f659bc5a3188ee8fe@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: Component: libraries | Version: 8.6.3 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/139 -------------------------------------+------------------------------------- Comment (by RyanGlScott): https://gitlab.haskell.org/ghc/ghc/merge_requests/139 was merged. Should we close this ticket, or would it behoove us to keep it open until we can verify that 8.6.4 fixes this issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 13:57:30 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 13:57:30 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.832864fc3caba952e0cbc3d01161aef6@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T14729{,kind}, | typecheck/should_compile/T15549[ab] Blocked By: | Blocking: Related Tickets: #15549 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => dependent/should_compile/T14729{,kind}, typecheck/should_compile/T15549[ab] * status: patch => closed * resolution: => fixed Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/2b90356d26b4699227816ad9424e766eccdb6c36 2b90356d26b4699227816ad9424e766eccdb6c36]. (Given the complexity of this patch, I'm not sure if it's worth trying to merge to 8.8 or not.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 14:05:22 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 14:05:22 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.de807870699845f6f2915af280a79814@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752, #12506, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Comment (by _recursion): > Because of that, GHC was taking **12gb+** to compile some files. I found that omitting the interfaces pragmas with `-fomit-interface-pragmas` was helping a lot. In fact, no more unfolded type in the interface file, making the dumped .txt file going from **3.5gb** to **700kb** with a maximum allocated memory of **2.5gb**. Doing this has been an ''immense'' help for Luna. Compile times on my machine, which is no slouch, have gone from just over one hour to a hair over six minutes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 14:21:18 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 14:21:18 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.184ae6433de4e81bcc1875a5f987caff@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T14729{,kind}, | typecheck/should_compile/T15549[ab] Blocked By: | Blocking: Related Tickets: #15549 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Changes (by goldfire): * status: closed => merge Comment: I think we should merge if possible. While complex, the changes are local to just a few places, and these places don't get a ton of traffic (because they're rather challenging to update). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 14:29:03 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 14:29:03 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.ea3f2848099dc5004aa1d95c0692f758@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T14729{,kind}, | typecheck/should_compile/T15549[ab] Blocked By: | Blocking: Related Tickets: #15549 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.10.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 14:58:46 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 14:58:46 -0000 Subject: [GHC] #16243: Improve fregs-graph. In-Reply-To: <047.c51e05612d1f950acb9a8eb123109828@haskell.org> References: <047.c51e05612d1f950acb9a8eb123109828@haskell.org> Message-ID: <062.69d79eee3295412cbca3704808cd1e65@haskell.org> #16243: Improve fregs-graph. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Resolution: | Keywords: fregs-graph Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7679 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #7679 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 15:48:32 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 15:48:32 -0000 Subject: [GHC] #16073: Hadrian build fails on Windows In-Reply-To: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> References: <046.99186dc13d4818eed6cf41a7060b7505@haskell.org> Message-ID: <061.a59aca25504b31ac55916325204e9993@haskell.org> #16073: Hadrian build fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by angerman): There is some other windows related issue in Cabal, that slyfox mentioned today: https://github.com/haskell/cabal/issues/5887 that might be cross compilation related only though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 16:40:09 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 16:40:09 -0000 Subject: [GHC] #16308: testsuite driver is sensitive to registration of multiple boot package versions Message-ID: <046.d01ad12f202863d7d5e1e4423835ef5e@haskell.org> #16308: testsuite driver is sensitive to registration of multiple boot package versions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Currently `testsuite/tests/Makefile` generates the `--rootdir` flags to be passed by `runtests.py` by looking at the output of `ghc-pkg list`. In the case that the user has recently bumped their submodules this list may contain multiple versions of the same package. This will then result in the same `library/$LIB/tests` directory being passed to the testsuite driver more than once. The testsuite driver will then squawk a "There are multiple tests with this name" warning. It took a few minutes for Simon and I to work out why this was. We should do better here (at least in Hadrian). Either by: * Teaching the testsuite driver to deduplicate the `--rootdir` list * Using a more robust source for the list of tested packages -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 16:40:33 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 16:40:33 -0000 Subject: [GHC] #16308: testsuite driver is sensitive to registration of multiple boot package versions In-Reply-To: <046.d01ad12f202863d7d5e1e4423835ef5e@haskell.org> References: <046.d01ad12f202863d7d5e1e4423835ef5e@haskell.org> Message-ID: <061.62a7c4d1254eb01c7b5cdbfb78b6d428@haskell.org> #16308: testsuite driver is sensitive to registration of multiple boot package versions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: alpmestan (added) Comment: CCing Alp as we recently the discussed the state of the testsuite in Hadrian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 16:45:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 16:45:16 -0000 Subject: [GHC] #16051: Cross compilation broken under Hadrian In-Reply-To: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> References: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> Message-ID: <061.7affc1b03e306f3ae7f7dec11bff2019@haskell.org> #16051: Cross compilation broken under Hadrian -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: (none) => alpmestan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 17:00:29 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 17:00:29 -0000 Subject: [GHC] #16051: Cross compilation broken under Hadrian In-Reply-To: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> References: <046.96e2c3b2b366c68e46309d0133e5da66@haskell.org> Message-ID: <061.8daad64e545b253e0ccf82c04032849c@haskell.org> #16051: Cross compilation broken under Hadrian -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Build System | Version: 8.7 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): ghctags being gone, I don't have any problem getting the build to complete with this very simple patch: {{{#!diff diff --git a/hadrian/src/UserSettings.hs b/hadrian/src/UserSettings.hs index c92dd11d44..b6fc30bd90 100644 --- a/hadrian/src/UserSettings.hs +++ b/hadrian/src/UserSettings.hs @@ -59,4 +59,4 @@ successColour = mkSuccessColour (Dull Green) -- 'Stage1' compiler. Setting it to 'Stage3' will build the 'Stage3' -- compiler. Setting it to 'Stage0' will mean nothing gets built at all. finalStage :: Stage -finalStage = Stage2 +finalStage = Stage1 }}} (this is a setting Matthew introduced somewhat recently, documented in hadrian's docs) With this in place, a simple `hadrian/build.sh -j4` builds stage 1 to completion. However, trying to build this trivial Haskell program then fails: {{{#!hs main = putStrLn "hello" }}} with {{{#!sh $ _build/stage0/bin/aarch64-unknown-linux-gnu-ghc hello.hs -o hello [1 of 1] Compiling Main ( hello.hs, hello.o ) hello.hs:1:1: error: Bad interface file: /nix/store/8h3fdgpq66w8kxzxn49s706505a7ihnr- ghc-8.4.3/lib/ghc-8.4.3/base-4.11.1.0/Prelude.hi mismatched interface file versions (wanted "80720190211", got "8043") | 1 | main = putStrLn "hello" | ^ }}} The cross-compiler ends up looking at the boot compiler's interface files instead of its own. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 18:15:47 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 18:15:47 -0000 Subject: [GHC] #13839: GHCi warnings do not respect the default module header In-Reply-To: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> References: <048.8053658e99a6145e8d5d5532fd36189f@haskell.org> Message-ID: <063.594eef43e97dd744317327cdb8d2b36e@haskell.org> #13839: GHCi warnings do not respect the default module header -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TESTS="T13839 T13839a T13839b" Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/292 -------------------------------------+------------------------------------- Changes (by RolandSenn): * testcase: make test TEST=T13839 => make test TESTS="T13839 T13839a T13839b" * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 18:17:59 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 18:17:59 -0000 Subject: [GHC] #16308: testsuite driver is sensitive to registration of multiple boot package versions In-Reply-To: <046.d01ad12f202863d7d5e1e4423835ef5e@haskell.org> References: <046.d01ad12f202863d7d5e1e4423835ef5e@haskell.org> Message-ID: <061.daed191d8e6e5b338d60f1744b0efcbc@haskell.org> #16308: testsuite driver is sensitive to registration of multiple boot package versions -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Do we have such a "more robust source" ? I think we can easily deduplicate, but if we _do_ have such a source of `rootdir`s/packages to test, that would quite likely be simpler and a better choice in the long run. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 18:46:17 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 18:46:17 -0000 Subject: [GHC] #16309: Flag to instruct GHC not to use an environment file Message-ID: <047.45c7dd13af52722f5d747eda2270339d@haskell.org> #16309: Flag to instruct GHC not to use an environment file -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- As the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.html #package-environments user manual] document, GHC looks for environment files in the current directory to tell it what packages to look for. There seems to be no way to disable this behavior (short of deleting or renaming the environment file). This causes trouble for me, as I expect `ghci` to mean the same thing no matter where I say it. Can we add a flag (perhaps `-no-package-env`) that tells GHC not to look for an environment file? Note that specifying a dummy package environment file doesn't work because we can't suppress the implicit `-hide-all- packages` that is triggered whenever using a package environment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 19:10:15 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 19:10:15 -0000 Subject: [GHC] #16310: Program fails with "Impossible case alternative" when optimized Message-ID: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> #16310: Program fails with "Impossible case alternative" when optimized -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's an (unfortunately rather large) program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Main (main) where import Data.Kind (Type) import Data.Type.Equality ((:~:)(..)) import Unsafe.Coerce (unsafeCoerce) main :: IO () main = print $ traversableComposition @(M1 U1) @() @() @() @U1 @U1 sPureFun sPureFun (SM1 SU1) ----- sPureFun :: forall f a. SApplicative f => Sing (PureSym0 :: a ~> f a) sPureFun = singFun1 @PureSym0 sPure data family Sing (a :: k) data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: a ~> b) (x :: a) :: b data (.@#@$$$) :: forall a b c. (b ~> c) -> (a ~> b) -> a ~> c type instance Apply (f .@#@$$$ g) x = Apply f (Apply g x) newtype instance Sing (f :: k1 ~> k2) = SLambda (forall t. Sing t -> Sing (Apply f t)) type SingFunction1 f = forall t. Sing t -> Sing (Apply f t) singFun1 :: forall f. SingFunction1 f -> Sing f singFun1 f = SLambda f type SingFunction2 f = forall t. Sing t -> SingFunction1 (Apply f t) singFun2 :: forall f. SingFunction2 f -> Sing f singFun2 f = SLambda (\x -> singFun1 (f x)) ----- data U1 p = U1 data instance Sing (z :: U1 p) where SU1 :: Sing 'U1 newtype M1 f p = M1 (f p) data instance Sing (z :: M1 f p) where SM1 :: Sing x -> Sing ('M1 x) data M1Sym0 :: forall k (f :: k -> Type) (p :: k). f p ~> M1 f p type instance Apply M1Sym0 x = 'M1 x newtype Compose f g x = Compose (f (g x)) data ComposeSym0 :: forall k1 k2 (f :: k2 -> Type) (g :: k1 -> k2) (x :: k1). f (g x) ~> Compose f g x type instance Apply ComposeSym0 x = 'Compose x data instance Sing (z :: Compose f g a) where SCompose :: Sing x -> Sing ('Compose x) instance (PFunctor f, PFunctor g) => PFunctor (Compose f g) where type Fmap h ('Compose x) = 'Compose (Fmap (FmapSym1 h) x) instance (SFunctor f, SFunctor g) => SFunctor (Compose f g) where sFmap :: forall a b (h :: a ~> b) (x :: Compose f g a). Sing h -> Sing x -> Sing (Fmap h x) sFmap sh (SCompose sx) = SCompose (sFmap (singFun1 @(FmapSym1 h) (sFmap sh)) sx) instance (PApplicative f, PApplicative g) => PApplicative (Compose f g) where type Pure x = 'Compose (Pure (Pure x)) type 'Compose h <*> 'Compose x = 'Compose (Fmap (<*>@#@$) h <*> x) instance (SApplicative f, SApplicative g) => SApplicative (Compose f g) where sPure sx = SCompose (sPure (sPure sx)) SCompose sh %<*> SCompose sx = SCompose (sFmap (singFun2 @(<*>@#@$) (%<*>)) sh %<*> sx) instance PFunctor U1 where type Fmap _ _ = 'U1 instance SFunctor U1 where sFmap _ _ = SU1 instance VFunctor U1 where fmapCompose _ _ SU1 = Refl instance PFunctor f => PFunctor (M1 f) where type Fmap g ('M1 x) = 'M1 (Fmap g x) instance SFunctor f => SFunctor (M1 f) where sFmap sg (SM1 sx) = SM1 (sFmap sg sx) instance VFunctor f => VFunctor (M1 f) where fmapCompose sg sh (SM1 x) | Refl <- fmapCompose sg sh x = Refl instance PApplicative U1 where type Pure _ = 'U1 type _ <*> _ = 'U1 instance SApplicative U1 where sPure _ = SU1 _ %<*> _ = SU1 instance VApplicative U1 where applicativeHomomorphism _ _ = Refl applicativeFmap _ _ = Refl instance PTraversable U1 where type Traverse _ _ = Pure 'U1 instance STraversable U1 where sTraverse _ _ = sPure SU1 instance VTraversable U1 where traversableComposition :: forall p q r (f :: Type -> Type) (g :: Type -> Type) (h :: p ~> f q) (i :: q ~> g r) (x :: U1 p). (VApplicative f, VApplicative g) => Sing h -> Sing i -> Sing x -> Traverse (ComposeSym0 .@#@$$$ FmapSym1 i .@#@$$$ h) x :~: 'Compose (Fmap (TraverseSym1 i) (Traverse h x)) traversableComposition _ si _ | Refl <- applicativeHomomorphism @f sTraverseI sU1q , Refl <- applicativeFmap @f sTraverseI (sPure sU1q) = Refl where sTraverseI :: Sing (TraverseSym1 i :: U1 q ~> g (U1 r)) sTraverseI = singFun1 (sTraverse si) sU1q :: Sing ('U1 :: U1 q) sU1q = SU1 instance PTraversable f => PTraversable (M1 f) where type Traverse g ('M1 x) = Fmap M1Sym0 (Traverse g x) instance STraversable f => STraversable (M1 f) where sTraverse sg (SM1 sx) = sFmap (singFun1 @M1Sym0 SM1) (sTraverse sg sx) instance VTraversable f => VTraversable (M1 f) where traversableComposition :: forall p q r (cf :: Type -> Type) (cg :: Type -> Type) (h :: p ~> cf q) (i :: q ~> cg r) (x :: M1 f p). (VApplicative cf, VApplicative cg) => Sing h -> Sing i -> Sing x -> Traverse (ComposeSym0 .@#@$$$ FmapSym1 i .@#@$$$ h) x :~: 'Compose (Fmap (TraverseSym1 i) (Traverse h x)) traversableComposition sh si (SM1 (sfp :: Sing fp)) | Refl <- traversableComposition sh si sfp , Refl <- fmapCompose @cf (singFun1 @(FmapSym1 M1Sym0) (sFmap sM1Fun)) sTraverseIFun sTraverseHIp , Refl <- -- Fmap (FmapSym1 M1Sym0 .@#@$$$ TraverseSym1 i) (Traverse h fp) -- :~: Fmap (TraverseSym1 i .@#@$$$ M1Sym0) (Traverse h fp) Refl @FmapSym0 `apply` funExt @(f q) @(cg (M1 f r)) @(FmapSym1 M1Sym0 .@#@$$$ TraverseSym1 i) @(TraverseSym1 i .@#@$$$ M1Sym0) lemma `apply` Refl @(Traverse h fp) , Refl <- fmapCompose @cf sTraverseIFun sM1Fun sTraverseHIp = Refl where lemma :: forall (z :: f q). Sing z -> Fmap M1Sym0 (Traverse i z) :~: Traverse i (Apply M1Sym0 z) lemma _ = Refl sM1Fun :: forall z. Sing (M1Sym0 :: f z ~> M1 f z) sM1Fun = singFun1 SM1 sTraverseHIp :: Sing (Traverse h fp) sTraverseHIp = sTraverse sh sfp sTraverseIFun :: forall hk. STraversable hk => Sing (TraverseSym1 i :: hk q ~> cg (hk r)) sTraverseIFun = singFun1 (sTraverse si) ----- class PFunctor (f :: Type -> Type) where type Fmap (g :: a ~> b) (x :: f a) :: f b data FmapSym0 :: forall f a b. (a ~> b) ~> f a ~> f b data FmapSym1 :: forall f a b. (a ~> b) -> f a ~> f b type instance Apply FmapSym0 f = FmapSym1 f type instance Apply (FmapSym1 f) x = Fmap f x class SFunctor (f :: Type -> Type) where sFmap :: forall a b (g :: a ~> b) (x :: f a). Sing g -> Sing x -> Sing (Fmap g x) class (PFunctor f, SFunctor f) => VFunctor f where fmapCompose :: forall a b c (g :: b ~> c) (h :: a ~> b) (x :: f a). Sing g -> Sing h -> Sing x -> Fmap g (Fmap h x) :~: Fmap (g .@#@$$$ h) x class PFunctor f => PApplicative f where type Pure (x :: a) :: f a type (g :: f (a ~> b)) <*> (x :: f a) :: f b infixl 4 <*> data PureSym0 :: forall (f :: Type -> Type) a. a ~> f a type instance Apply PureSym0 x = Pure x data (<*>@#@$) :: forall (f :: Type -> Type) a b. f (a ~> b) ~> f a ~> f b data (<*>@#@$$) :: forall (f :: Type -> Type) a b. f (a ~> b) -> f a ~> f b type instance Apply (<*>@#@$) f = (<*>@#@$$) f type instance Apply ((<*>@#@$$) f) x = f <*> x class SFunctor f => SApplicative f where sPure :: forall a (x :: a). Sing x -> Sing (Pure x :: f a) (%<*>) :: forall a b (g :: f (a ~> b)) (x :: f a). Sing g -> Sing x -> Sing (g <*> x) class (PApplicative f, SApplicative f, VFunctor f) => VApplicative f where applicativeHomomorphism :: forall a b (g :: a ~> b) (x :: a). Sing g -> Sing x -> (Pure g <*> Pure x) :~: (Pure (g `Apply` x) :: f b) applicativeFmap :: forall a b (g :: a ~> b) (x :: f a). Sing g -> Sing x -> Fmap g x :~: (Pure g <*> x) class PFunctor t => PTraversable t where type Traverse (g :: a ~> f b) (x :: t a) :: f (t b) data TraverseSym1 :: forall t f a b. (a ~> f b) -> t a ~> f (t b) type instance Apply (TraverseSym1 f) x = Traverse f x class SFunctor t => STraversable t where sTraverse :: forall f a b (g :: a ~> f b) (x :: t a). SApplicative f => Sing g -> Sing x -> Sing (Traverse g x) class (PTraversable t, STraversable t, VFunctor t) => VTraversable t where traversableComposition :: forall a b c (f :: Type -> Type) (g :: Type -> Type) (h :: a ~> f b) (i :: b ~> g c) (x :: t a). (VApplicative f, VApplicative g) => Sing h -> Sing i -> Sing x -> Traverse (ComposeSym0 .@#@$$$ FmapSym1 i .@#@$$$ h) x :~: 'Compose (Fmap (TraverseSym1 i) (Traverse h x)) ----- funExt :: forall a b (f :: a ~> b) (g :: a ~> b). (forall (x :: a). Sing x -> Apply f x :~: Apply g x) -> f :~: g funExt _ = axiom apply :: f :~: g -> a :~: b -> Apply f a :~: Apply g b apply Refl Refl = Refl axiom :: a :~: b axiom = unsafeCoerce Refl }}} When compiled without optimization, this program prints "`Refl`", as you would expect: {{{ $ /opt/ghc/8.6.3/bin/ghc -O0 Bug.hs -fforce-recomp [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ ./Bug Refl }}} However, when compiled with optimizations, it starts failing at runtime! {{{ $ /opt/ghc/8.6.3/bin/ghc -O Bug.hs -fforce-recomp [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ ./Bug Bug: Impossible case alternative }}} This behavior can be observed on all versions of GHC from 8.2.2 to HEAD. Interestingly, this program passes `-dcore-lint` on GHC 8.4.4 through HEAD, but on GHC 8.2.2, it fails `-dcore-lint`: {{{ $ /opt/ghc/8.6.3/bin/ghc -O Bug.hs -fforce-recomp -dcore-lint [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ /opt/ghc/8.2.2/bin/ghc -O Bug.hs -fforce-recomp -dcore-lint [1 of 1] Compiling Main ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** : warning: In a case alternative: (Refl cobox_a1UV :: (FmapSym0 :: (TyFun (f1_X2dk b_a2aC ~> g_a2aF (M1 f1_X2dk c_a2aD)) (f_a2aE (f1_X2dk b_a2aC) ~> f_a2aE (g_a2aF (M1 f1_X2dk c_a2aD))) -> *)) ~# (FmapSym0 :: (TyFun (f1_X2dk b_a2aC ~> g_a2aF (M1 f1_X2dk c_a2aD)) (f_a2aE (f1_X2dk b_a2aC) ~> f_a2aE (g_a2aF (M1 f1_X2dk c_a2aD))) -> *))) No alternatives for a case scrutinee in head-normal form: ($WRefl @ Any @ Any) `cast` (((:~:) (UnsafeCo nominal Any (f b ~> g (M1 f c))) (UnsafeCo nominal Any (FmapSym1 M1Sym0 .@#@$$$ TraverseSym1 i)) (UnsafeCo nominal Any (TraverseSym1 i .@#@$$$ M1Sym0)))_R :: ((Any :~: Any) :: *) ~R# (((FmapSym1 M1Sym0 .@#@$$$ TraverseSym1 i_a2aH) :~: (TraverseSym1 i_a2aH .@#@$$$ M1Sym0)) :: *)) }}} (The full Core Lint error is absolutely enormous, so I'll post it as a separate attachment.) The one thing about this program that might be considered strange is the use of `axiom = unsafeCoerce Refl`. I believe this should be a perfectly safe use of `unsafeCoerce`, but nevertheless, there is always the possibility that GHC is doing something unsightly when optimizing it. As one curiosity, if you mark `axiom` as `NOINLINE`, then the program produces a different result: {{{ $ /opt/ghc/8.6.3/bin/ghc -O Bug.hs -fforce-recomp -dcore-lint [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ ./Bug }}} The program simply prints a newline, for some odd reason. (It doesn't appear to throw an exception either, since `echo $?` yields `0`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 19:13:52 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 19:13:52 -0000 Subject: [GHC] #16310: Program fails with "Impossible case alternative" when optimized In-Reply-To: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> References: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> Message-ID: <065.2752c28513363f1e7845375be7ea85a8@haskell.org> #16310: Program fails with "Impossible case alternative" when optimized -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "ghc-8.2.2.dump-core-lint" added. Result of running `/opt/ghc/8.2.2/bin/ghc -O Bug.hs -fforce-recomp -dcore- lint` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 19:16:53 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 19:16:53 -0000 Subject: [GHC] #16310: Program fails with "Impossible case alternative" when optimized In-Reply-To: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> References: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> Message-ID: <065.777a772deda2c20cb12556dabdaf690c@haskell.org> #16310: Program fails with "Impossible case alternative" when optimized -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Upon further searching, the most likely reason why this fails Core Lint in GHC 8.2.2 but not in later versions is due to commit 6b52b4c832f888f7741a4ba0fec1fdac10244f6d, which removed the very Core Lint check that fires in 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 20:29:43 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 20:29:43 -0000 Subject: [GHC] #16305: When should -Wmissed-specializations fire? In-Reply-To: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> References: <047.96f76fdc1c5898f6791c33d542e88cbd@haskell.org> Message-ID: <062.2a594c5dca1db83ac7c3cfbbc75a814e@haskell.org> #16305: When should -Wmissed-specializations fire? -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 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 crockeea): Looks like your assessment is accurate, Simon. Perhaps the only problem here is a documentation issue, because I don't think the docs for `-Wmissed-specs` make it clear when a warning is issued. I'm also interested in understanding the warning from my example. The function names appear to be core, and it's not clear to me that `Data.Map.Internal.$fShowMap_$cshowsPrec` even corresponds to a function in source code. If that's the case, then the warning isn't very useful, either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 20:38:53 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 20:38:53 -0000 Subject: [GHC] #16221: Core Lint error with a data type In-Reply-To: <047.621c532512c5ecf6cb731ace319b51aa@haskell.org> References: <047.621c532512c5ecf6cb731ace319b51aa@haskell.org> Message-ID: <062.9e279c91a80a488919dd80e500d52841@haskell.org> #16221: Core Lint error with a data type -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 20:42:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 20:42:27 -0000 Subject: [GHC] #16247: GHC 8.6 Core Lint regression (Kind application error) In-Reply-To: <050.86450994402b394920f8cc11311bffbb@haskell.org> References: <050.86450994402b394920f8cc11311bffbb@haskell.org> Message-ID: <065.b35dcaff0b82fcd27f4677add79357a3@haskell.org> #16247: GHC 8.6 Core Lint regression (Kind application error) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.6.3 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 RyanGlScott): A more complicated example that `singletons` spat out: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind (Constraint, Type) import GHC.Generics (Rep1, U1(..)) data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: a ~> b) (x :: a) :: b type SameKind (a :: k) (b :: k) = (() :: Constraint) type family From1 (z :: (f :: Type -> Type) a) :: Rep1 f a type family From1U1 (x :: U1 (p :: k)) :: Rep1 U1 p where {} data From1U1Sym0 :: forall p k. (U1 :: k -> Type) p ~> Rep1 (U1 :: k -> Type) p where From1Sym0KindInference :: forall z arg. SameKind (Apply From1U1Sym0 arg) (From1U1 arg) => From1U1Sym0 z }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Tidy Core *** : warning: In the type ‘forall k (p :: k) k k (p :: k) (z :: TyFun (U1 p) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p)) (arg :: U1 p). SameKind (Apply (From1U1Sym0 |> (TyFun _N (Sym (Sym (Rep1_U1[0] _N)

_N)))_N ->_N <*>_N) arg) (From1U1 arg |> Sym (Sym (Rep1_U1[0] _N)

_N)) => From1U1Sym0 (z |> (TyFun _N (Sym (Rep1_U1[0] _N)

_N))_N)’ Kind application error in type ‘U1 p_a2U6’ Function kind = forall k. k -> * Arg kinds = [(k_a2U7, *), (p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the type ‘forall k (p :: k) k k (p :: k) (z :: TyFun (U1 p) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p)) (arg :: U1 p). SameKind (Apply (From1U1Sym0 |> (TyFun _N (Sym (Sym (Rep1_U1[0] _N)

_N)))_N ->_N <*>_N) arg) (From1U1 arg |> Sym (Sym (Rep1_U1[0] _N)

_N)) => From1U1Sym0 (z |> (TyFun _N (Sym (Rep1_U1[0] _N)

_N))_N)’ Kind application error in type ‘M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p_a2U6’ Function kind = forall k. * -> Meta -> (k -> *) -> k -> * Arg kinds = [(k_a2U7, *), (D, *), ('MetaData "U1" "GHC.Generics" "base" 'False, Meta), (C1 ('MetaCons "U1" 'PrefixI 'False) U1, k_a2U7 -> *), (p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the type ‘forall k (p :: k) k k (p :: k) (z :: TyFun (U1 p) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p)) (arg :: U1 p). SameKind (Apply (From1U1Sym0 |> (TyFun _N (Sym (Sym (Rep1_U1[0] _N)

_N)))_N ->_N <*>_N) arg) (From1U1 arg |> Sym (Sym (Rep1_U1[0] _N)

_N)) => From1U1Sym0 (z |> (TyFun _N (Sym (Rep1_U1[0] _N)

_N))_N)’ Kind application error in type ‘U1 p_a2U6’ Function kind = forall k. k -> * Arg kinds = [(k_a2U7, *), (p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the type ‘forall k (p :: k) k k (p :: k) (z :: TyFun (U1 p) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p)) (arg :: U1 p). SameKind (Apply (From1U1Sym0 |> (TyFun _N (Sym (Sym (Rep1_U1[0] _N)

_N)))_N ->_N <*>_N) arg) (From1U1 arg |> Sym (Sym (Rep1_U1[0] _N)

_N)) => From1U1Sym0 (z |> (TyFun _N (Sym (Rep1_U1[0] _N)

_N))_N)’ Kind application error in coercion ‘Sym (Rep1_U1[0] _N) _N’ Function kind = k_a2U7 -> * Arg kinds = [(p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the type ‘forall k (p :: k) k k (p :: k) (z :: TyFun (U1 p) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p)) (arg :: U1 p). SameKind (Apply (From1U1Sym0 |> (TyFun _N (Sym (Sym (Rep1_U1[0] _N)

_N)))_N ->_N <*>_N) arg) (From1U1 arg |> Sym (Sym (Rep1_U1[0] _N)

_N)) => From1U1Sym0 (z |> (TyFun _N (Sym (Rep1_U1[0] _N)

_N))_N)’ Kind application error in coercion ‘Sym (Rep1_U1[0] _N) _N’ Function kind = k_a2U7 -> * Arg kinds = [(p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) Bug.hs:22:36: warning: [in body of lambda with binder z_X1QM :: TyFun (U1 p_a2U6) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p_a2U6)] Kind application error in type ‘U1 p_a2U6’ Function kind = forall k. k -> * Arg kinds = [(k_a2U7, *), (p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) Bug.hs:22:36: warning: [in body of lambda with binder z_X1QM :: TyFun (U1 p_a2U6) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p_a2U6)] Kind application error in type ‘M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p_a2U6’ Function kind = forall k. * -> Meta -> (k -> *) -> k -> * Arg kinds = [(k_a2U7, *), (D, *), ('MetaData "U1" "GHC.Generics" "base" 'False, Meta), (C1 ('MetaCons "U1" 'PrefixI 'False) U1, k_a2U7 -> *), (p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the expression: From1Sym0KindInference @ k_a2U5 @ p_a2U6 @ k_a2U7 @ (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) @ k_X2TZ @ p_X2U5 @ z_X1QM @ arg_X1QO @~ (<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N :: (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) ~# (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)) dt_a35M Kind application error in type ‘U1 p_a2U6’ Function kind = forall k. k -> * Arg kinds = [(k_a2U7, *), (p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the expression: From1Sym0KindInference @ k_a2U5 @ p_a2U6 @ k_a2U7 @ (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) @ k_X2TZ @ p_X2U5 @ z_X1QM @ arg_X1QO @~ (<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N :: (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) ~# (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)) dt_a35M Kind application error in coercion ‘Sym (Rep1_U1[0] _N) _N’ Function kind = k_a2U7 -> * Arg kinds = [(p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the expression: From1Sym0KindInference @ k_a2U5 @ p_a2U6 @ k_a2U7 @ (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) @ k_X2TZ @ p_X2U5 @ z_X1QM @ arg_X1QO @~ (<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N :: (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) ~# (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)) dt_a35M Kind application error in coercion ‘Sym (Rep1_U1[0] _N) _N’ Function kind = k_a2U7 -> * Arg kinds = [(p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the coercion ‘<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N’ Kind application error in type ‘U1 p_a2U6’ Function kind = forall k. k -> * Arg kinds = [(k_a2U7, *), (p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the coercion ‘<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N’ Kind application error in coercion ‘Sym (Rep1_U1[0] _N) _N’ Function kind = k_a2U7 -> * Arg kinds = [(p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the coercion ‘<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N’ Kind application error in coercion ‘Sym (Rep1_U1[0] _N) _N’ Function kind = k_a2U7 -> * Arg kinds = [(p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) Bug.hs:22:36: warning: [in body of lambda with binder z_X1QM :: TyFun (U1 p_a2U6) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p_a2U6)] Kind application error in type ‘U1 p_a2U6’ Function kind = forall k. k -> * Arg kinds = [(k_a2U7, *), (p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) Bug.hs:22:36: warning: [in body of lambda with binder z_X1QM :: TyFun (U1 p_a2U6) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p_a2U6)] Kind application error in type ‘M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p_a2U6’ Function kind = forall k. * -> Meta -> (k -> *) -> k -> * Arg kinds = [(k_a2U7, *), (D, *), ('MetaData "U1" "GHC.Generics" "base" 'False, Meta), (C1 ('MetaCons "U1" 'PrefixI 'False) U1, k_a2U7 -> *), (p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the expression: From1Sym0KindInference @ k_a2U5 @ p_a2U6 @ k_a2U7 @ (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) @ k_X2TZ @ p_X2U5 @ z_X1QM @ arg_X1QO @~ (<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N :: (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) ~# (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)) dt_a35M Kind application error in type ‘U1 p_a2U6’ Function kind = forall k. k -> * Arg kinds = [(k_a2U7, *), (p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the expression: From1Sym0KindInference @ k_a2U5 @ p_a2U6 @ k_a2U7 @ (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) @ k_X2TZ @ p_X2U5 @ z_X1QM @ arg_X1QO @~ (<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N :: (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) ~# (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)) dt_a35M Kind application error in coercion ‘Sym (Rep1_U1[0] _N) _N’ Function kind = k_a2U7 -> * Arg kinds = [(p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the expression: From1Sym0KindInference @ k_a2U5 @ p_a2U6 @ k_a2U7 @ (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) @ k_X2TZ @ p_X2U5 @ z_X1QM @ arg_X1QO @~ (<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N :: (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) ~# (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)) dt_a35M Kind application error in coercion ‘Sym (Rep1_U1[0] _N) _N’ Function kind = k_a2U7 -> * Arg kinds = [(p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the coercion ‘<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N’ Kind application error in type ‘U1 p_a2U6’ Function kind = forall k. k -> * Arg kinds = [(k_a2U7, *), (p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the coercion ‘<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N’ Kind application error in coercion ‘Sym (Rep1_U1[0] _N) _N’ Function kind = k_a2U7 -> * Arg kinds = [(p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) : warning: In the coercion ‘<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N’ Kind application error in coercion ‘Sym (Rep1_U1[0] _N) _N’ Function kind = k_a2U7 -> * Arg kinds = [(p_a2U6, k_a2U5)] Fun: k_a2U7 (p_a2U6, k_a2U5) *** Offending Program *** $WFrom1Sym0KindInference [InlPrag=INLINE[2]] :: forall k (p :: k) k k (p :: k) (z :: TyFun (U1 p) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p)) (arg :: U1 p). SameKind (Apply (From1U1Sym0 |> (TyFun _N (Sym (Sym (Rep1_U1[0] _N)

_N)))_N ->_N <*>_N) arg) (From1U1 arg |> Sym (Sym (Rep1_U1[0] _N)

_N)) => From1U1Sym0 (z |> (TyFun _N (Sym (Rep1_U1[0] _N)

_N))_N) [GblId[DataConWrapper], Arity=1, Caf=NoCafRefs, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (@ k_X2TZ) (@ (p_X2U5 :: k_X2TZ)) (@ k_a2U5) (@ k_a2U7) (@ (p_a2U6 :: k_a2U5)) (@ (z_X1QM :: TyFun (U1 p_a2U6) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p_a2U6))) (@ (arg_X1QO :: U1 p_X2U5)) (dt_a35M [Occ=Once] :: SameKind (Apply (From1U1Sym0 |> (TyFun _N (Sym (Sym (Rep1_U1[0] _N) _N)))_N ->_N <*>_N) arg_X1QO) (From1U1 arg_X1QO |> Sym (Sym (Rep1_U1[0] _N) _N))) -> From1Sym0KindInference @ k_a2U5 @ p_a2U6 @ k_a2U7 @ (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) @ k_X2TZ @ p_X2U5 @ z_X1QM @ arg_X1QO @~ (<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N :: (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) ~# (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)) dt_a35M}] $WFrom1Sym0KindInference = \ (@ k_X2TZ) (@ (p_X2U5 :: k_X2TZ)) (@ k_a2U5) (@ k_a2U7) (@ (p_a2U6 :: k_a2U5)) (@ (z_X1QM :: TyFun (U1 p_a2U6) (M1 D ('MetaData "U1" "GHC.Generics" "base" 'False) (C1 ('MetaCons "U1" 'PrefixI 'False) U1) p_a2U6))) (@ (arg_X1QO :: U1 p_X2U5)) (dt_a35M [Occ=Once] :: SameKind (Apply (From1U1Sym0 |> (TyFun _N (Sym (Sym (Rep1_U1[0] _N) _N)))_N ->_N <*>_N) arg_X1QO) (From1U1 arg_X1QO |> Sym (Sym (Rep1_U1[0] _N) _N))) -> From1Sym0KindInference @ k_a2U5 @ p_a2U6 @ k_a2U7 @ (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) @ k_X2TZ @ p_X2U5 @ z_X1QM @ arg_X1QO @~ (<(z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)>_N :: (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N) ~# (z_X1QM |> (TyFun _N (Sym (Rep1_U1[0] _N) _N))_N)) dt_a35M $trModule1_r36E :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule1_r36E = "main"# $trModule2_r36Q :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule2_r36Q = TrNameS $trModule1_r36E $trModule3_r36R :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule3_r36R = "Bug"# $trModule4_r36S :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule4_r36S = TrNameS $trModule3_r36R $trModule :: Module [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule = Module $trModule2_r36Q $trModule4_r36S $tcTyFun1_r36T :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $tcTyFun1_r36T = "TyFun"# $tcTyFun2_r36U :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $tcTyFun2_r36U = TrNameS $tcTyFun1_r36T $tcTyFun :: TyCon [GblId, Unf=OtherCon []] $tcTyFun = TyCon 8840097126617362261## 15320025594455375939## $trModule $tcTyFun2_r36U 0# krep$*->*->* *** End of Offense *** : error: Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 21:20:56 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 21:20:56 -0000 Subject: [GHC] #16311: Suggest -XExistentialQuantification for 'forall' in data declarations Message-ID: <048.8e11135b0672563b5f793c5e90494439@haskell.org> #16311: Suggest -XExistentialQuantification for 'forall' in data declarations -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Phab:D5180 introduced a slight regression to the error messages. In this code {{{#!hs data T = forall a. MkT a }}} GHC used to complain {{{ rnfail053.hs:5:10: Not a data constructor: ‘forall’ Perhaps you intended to use ExistentialQuantification }}} but then the message has become {{{ rnfail053.hs:5:18: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall . }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 21:42:41 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 21:42:41 -0000 Subject: [GHC] #16310: Program fails with "Impossible case alternative" when optimized In-Reply-To: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> References: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> Message-ID: <065.761eaddf9fdb9c1372899d43ec5020ac@haskell.org> #16310: Program fails with "Impossible case alternative" when optimized -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I managed to trim this down considerably: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Main (main) where import Data.Kind (Type) import Data.Type.Equality ((:~:)(..)) import Unsafe.Coerce (unsafeCoerce) data family Sing :: k -> Type data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: a ~> b) (x :: a) :: b funExt :: forall a b (f :: a ~> b) (g :: a ~> b). (forall (x :: a). Sing x -> Apply f x :~: Apply g x) -> f :~: g funExt _ = axiom apply :: f :~: g -> a :~: b -> Apply f a :~: Apply g b apply Refl Refl = Refl axiom :: forall a b. a :~: b axiom = unsafeCoerce (Refl @a) type family F (a :: Type ~> Type) data FSym :: (Type ~> Type) ~> Type type instance Apply FSym a = F a data T1Sym :: Type ~> Type data T2Sym :: Type ~> Type type instance Apply T1Sym a = a type instance Apply T2Sym a = a main :: IO () main | Refl <- Refl @FSym `apply` funExt @Type @Type @T1Sym @T2Sym (const Refl) = pure () }}} {{{ $ /opt/ghc/8.6.3/bin/ghc -O0 -fforce-recomp Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ ./Bug $ /opt/ghc/8.6.3/bin/ghc -O -fforce-recomp Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... $ ./Bug Bug: Impossible case alternative }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 21:58:51 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 21:58:51 -0000 Subject: [GHC] #16310: Program fails with "Impossible case alternative" when optimized In-Reply-To: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> References: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> Message-ID: <065.9afe414fcc25c376b3f450e02db83adb@haskell.org> #16310: Program fails with "Impossible case alternative" when optimized -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Marking `apply` as `NOINLINE` works around the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 22:13:08 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 22:13:08 -0000 Subject: [GHC] #16310: Program fails with "Impossible case alternative" when optimized In-Reply-To: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> References: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> Message-ID: <065.63d8d20f4a133c9918a157bc7da16c79@haskell.org> #16310: Program fails with "Impossible case alternative" when optimized -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: wontfix | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix Comment: After some thought, I've come to the conclusion that this isn't a bug. Here is what is happening. GHC scrutinizes a `$WRefl` of type `T1Sym :~: T2Sym`. GHC, in its infinite wisdom, recognizes that `T1Sym` and `T2Sym` are distinct data types, and therefore cannot possibly be equal. Therefore, `SimplUtils.mkCase` transforms this into `case ($WRefl :: T1Sym :~: T2Sym) of {}`, since the `Refl` case is "unreachable". However, due to our crafty use of `unsafeCoerce`, we //do// actually enter this case, and disaster strikes. I've come to the conclusion that `axiom`, much like `unsafePerformIO`, requires careful use of `NOINLINE` in order to use in a safe fashion. The fact that `apply` must be marked as `NOINLINE` reflects this reality. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 12 22:24:48 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Feb 2019 22:24:48 -0000 Subject: [GHC] #16310: Program fails with "Impossible case alternative" when optimized In-Reply-To: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> References: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> Message-ID: <065.65a11e926644874bf27e46cc2dd213a9@haskell.org> #16310: Program fails with "Impossible case alternative" when optimized -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: wontfix | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): `unsafeCoerce` is certainly dangerous, as its name suggests! Here `axiom` seems to claim that for all types `a` and `b`, the two are equal. That might lead to a seg-faolt; here it leads to "unreachable" code being reached. Or is there more to it than that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 01:08:48 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 01:08:48 -0000 Subject: [GHC] #16312: Optimization + adding an INLINE pragma triggers Core Lint error (Type of case alternatives not the same as the annotation on case) Message-ID: <050.2616a09c9703c7abb703460264929e5d@haskell.org> #16312: Optimization + adding an INLINE pragma triggers Core Lint error (Type of case alternatives not the same as the annotation on case) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: -------------------------------------+------------------------------------- Here's a seemingly innocuous program, minimized from the `kan-extensions` library: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} module Bug where newtype Curried g h a = Curried { runCurried :: forall r. g (a -> r) -> h r } instance Functor g => Functor (Curried g h) where fmap f (Curried g) = Curried (g . fmap (.f)) instance (Functor g, g ~ h) => Applicative (Curried g h) where pure a = Curried (fmap ($a)) Curried mf <*> Curried ma = Curried (ma . mf . fmap (.)) {-# INLINE (<*>) #-} -- The Core Lint error goes away if you remove this INLINE pragma }}} However, it triggers a Core Lint error on GHC 8.2.2 through HEAD if you compile it with `-O` and `-dcore-lint`: {{{ $ /opt/ghc/8.6.3/bin/ghc -fforce-recomp -dcore-lint Bug.hs -O [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** : warning: In the expression: (case heq_sel @ (* -> *) @ (* -> *) @ h_a1eC @ h_a1eC ($d~_a1eE `cast` (((~) <* -> *>_N co_a1hx _N)_R ; N:~[0] <* -> *>_N _N _N :: (g_a1eB ~ h_a1eC) ~R# (h_a1eC ~~ h_a1eC))) of co_X1ij { __DEFAULT -> (\ (@ a_a1fg) (@ b_a1fh) (ds_d1yw :: Curried h_a1eC h_a1eC (a_a1fg -> b_a1fh)) (ds_d1yx :: Curried h_a1eC h_a1eC a_a1fg) (@ r_a1fn) -> let { g_X1zi :: h_a1eC (b_a1fh -> r_a1fn) -> h_a1eC ((a_a1fg -> b_a1fh) -> a_a1fg -> r_a1fn) [LclId, Unf=Unf{Src=, TopLvl=False, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 30 0}] g_X1zi = fmap @ h_a1eC ($dFunctor_a1eD `cast` ((Functor co_a1hx)_R :: Functor g_a1eB ~R# Functor h_a1eC)) @ (b_a1fh -> r_a1fn) @ ((a_a1fg -> b_a1fh) -> a_a1fg -> r_a1fn) (. @ b_a1fh @ r_a1fn @ a_a1fg) } in \ (x_X1zn :: h_a1eC (b_a1fh -> r_a1fn)) -> (ds_d1yx `cast` (N:Curried[0] _R _R _N :: Curried h_a1eC h_a1eC a_a1fg ~R# (forall r. h_a1eC (a_a1fg -> r) -> h_a1eC r))) @ r_a1fn ((ds_d1yw `cast` (N:Curried[0] _R _R b_a1fh>_N :: Curried h_a1eC h_a1eC (a_a1fg -> b_a1fh) ~R# (forall r. h_a1eC ((a_a1fg -> b_a1fh) -> r) -> h_a1eC r))) @ (a_a1fg -> r_a1fn) (g_X1zi x_X1zn))) `cast` (forall (a :: <*>_N) (b :: <*>_N). b)>_R ->_R _R ->_R Sym (N:Curried[0] _R _R _N) :: (forall a b. Curried h_a1eC h_a1eC (a -> b) -> Curried h_a1eC h_a1eC a -> forall r. h_a1eC (b -> r) -> h_a1eC r) ~R# (forall a b. Curried h_a1eC h_a1eC (a -> b) -> Curried h_a1eC h_a1eC a -> Curried h_a1eC h_a1eC b)) }) @ b_a1gi @ b_a1gi ((<$ @ (Curried g_a1eB h_a1eC) ($dFunctor_s1zH `cast` ((Functor (Curried (Sym co_a1hx) _N)_N)_R :: Functor (Curried h_a1eC h_a1eC) ~R# Functor (Curried g_a1eB h_a1eC))) @ (b_a1gi -> b_a1gi) @ a_a1gh (breakpoint @ b_a1gi) a1_a1z1) `cast` (Sym (Curried (Sub (Sym co_a1hx)) _R b_a1gi>_N)_R :: Curried g_a1eB h_a1eC (b_a1gi -> b_a1gi) ~R# Curried h_a1eC h_a1eC (b_a1gi -> b_a1gi))) (a2_a1z2 `cast` (Sym (Curried (Sub (Sym co_a1hx)) _R _N)_R :: Curried g_a1eB h_a1eC b_a1gi ~R# Curried h_a1eC h_a1eC b_a1gi)) Type of case alternatives not the same as the annotation on case: Actual type: forall a b. Curried h_a1eC h_a1eC (a -> b) -> Curried h_a1eC h_a1eC a -> Curried h_a1eC h_a1eC b Annotation on case: forall a b. Curried g_a1eB h_a1eC (a -> b) -> Curried g_a1eB h_a1eC a -> Curried g_a1eB h_a1eC b }}} The size of the `-dcore-lint` output is enormous, so I'll post it separately as an attachment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 01:09:21 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 01:09:21 -0000 Subject: [GHC] #16312: Optimization + adding an INLINE pragma triggers Core Lint error (Type of case alternatives not the same as the annotation on case) In-Reply-To: <050.2616a09c9703c7abb703460264929e5d@haskell.org> References: <050.2616a09c9703c7abb703460264929e5d@haskell.org> Message-ID: <065.e76a052eb411f13582827aae53947ae6@haskell.org> #16312: Optimization + adding an INLINE pragma triggers Core Lint error (Type of case alternatives not the same as the annotation on case) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 RyanGlScott): * Attachment "ghc-8.6.3.dump-core-lint" added. Result of running `/opt/ghc/8.6.3/bin/ghc -fforce-recomp -dcore-lint Bug.hs -O` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 01:44:31 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 01:44:31 -0000 Subject: [GHC] #16310: Program fails with "Impossible case alternative" when optimized In-Reply-To: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> References: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> Message-ID: <065.b626cadc41a9ca977f77aa33e8c3da66@haskell.org> #16310: Program fails with "Impossible case alternative" when optimized -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: wontfix | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Well, `axiom` is being used to prove functional extensionality, which is generally safe. But perhaps it would be better to put the use of `unsafeCoerce` in `funExt` directly. I wonder if that quells the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 01:57:12 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 01:57:12 -0000 Subject: [GHC] #16310: Program fails with "Impossible case alternative" when optimized In-Reply-To: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> References: <050.6b5d05f730823a2d4028992e8e5a451c@haskell.org> Message-ID: <065.867ef79c4364fff5e454bdfcc715b33b@haskell.org> #16310: Program fails with "Impossible case alternative" when optimized -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: wontfix | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:6 goldfire]: > But perhaps it would be better to put the use of `unsafeCoerce` in `funExt` directly. I wonder if that quells the problem. Alas, defining `funExt _ = unsafeCoerce (Refl @f)` does no good—it still produces `Impossible case alternative` when ran. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 02:12:31 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 02:12:31 -0000 Subject: [GHC] #16313: Core Lint warning (Unsafe coercion: {left, right}-hand type is levity-polymorphic) Message-ID: <050.474e30199f4ed213e19d2a554c242efb@haskell.org> #16313: Core Lint warning (Unsafe coercion: {left,right}-hand type is levity- polymorphic) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- goldfire claims [https://github.com/goldfirere/singletons/issues/383 this] is a GHC bug, so I'm reporting it here: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind (Type) import GHC.Exts (TYPE) import Type.Reflection (TypeRep, (:~~:)(..), eqTypeRep) import Unsafe.Coerce (unsafeCoerce) data SBool :: Bool -> Type where SFalse :: SBool False STrue :: SBool True type family DefaultEq (a :: k) (b :: k) :: Bool where DefaultEq a a = 'True DefaultEq a b = 'False sEqTypeRep :: forall rep (x :: TYPE rep) (y :: TYPE rep). TypeRep x -> TypeRep y -> SBool (DefaultEq x y) sEqTypeRep tra trb = case eqTypeRep tra trb of Just HRefl -> STrue Nothing -> unsafeCoerce SFalse }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs -O -dcore-lint -fforce-recomp [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint warnings : in result of Simplifier *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Float inwards *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Called arity analysis *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Demand analysis *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Worker Wrapper binds *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Exitification transformation *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Common sub-expression *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Float inwards *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Simplifier *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Demand analysis *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of Tidy Core *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg *** Core Lint warnings : in result of CorePrep *** : warning: In a case alternative: (True) Unsafe coercion: left-hand type is levity-polymorphic From: x_a1rf To: y_a1rg : warning: In a case alternative: (True) Unsafe coercion: right-hand type is levity-polymorphic From: x_a1rf To: y_a1rg }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 02:36:16 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 02:36:16 -0000 Subject: [GHC] #16314: Improve confusing error message with MINIMAL pragma Message-ID: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> #16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- I got bitten by this recently, and while I can see GHC's reasoning, I wish it told me something different and more useful. {{{#!hs class X a where foo :: a {-# MINIMAL foo #-} foo = undefined instance X Int }}} For this program, ghc says: {{{ GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( a.hs, interpreted ) a.hs:7:10: warning: [-Wmissing-methods] • No explicit implementation for ‘foo’ • In the instance declaration for ‘X Int’ | 7 | instance X Int | ^^^^^ }}} This is arguably "correct", since I made `foo` part of `MINIMAL`; but it's very confusing, because I know I added a default definition. I wish GHC instead said something like: {{{ You made `foo` MINIMAL, but also gave an explicit definition for it. }}} I can see the logic behind the current error message, but it was rather confusing. The background is that my class had many other methods and a `MINIMAL` pragma. Much later I realized I could give a default definition of one of those methods but I forgot to remove it from the `MINIMAL` list. So, I had to puzzle a while at the error messages that were coming from far away modules that had nothing to do with the class definition itself. This is not a showstopper by any means, but unless there are good reasons to do otherwise, it would be nice to get a warning right where the class is defined, as opposed to where it is instantiated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 09:48:39 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 09:48:39 -0000 Subject: [GHC] #16314: Improve confusing error message with MINIMAL pragma In-Reply-To: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> References: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> Message-ID: <060.7c7428be1ab8155dd5e63a3f020b354e@haskell.org> #16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > it would be nice to get a warning right where the class is defined, as opposed to where it is instantiated. I'm not sure that would be a good change. Here's a typical use-case (taken from the user manual) {{{ class Eq a where (==), (/=) :: a -> a -> Bool (==) a b = not (a /= b) (/=) a b = not (a == b) {-# MINIMAL (==) | (/=) #-} }}} Both have default methods, but you must define one or the other, or you get an infinite loop. At an instance we specifically want a warning, even though both have default methods. This was the original motivation for MINIMAL. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 10:23:17 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 10:23:17 -0000 Subject: [GHC] #16311: Suggest -XExistentialQuantification for 'forall' in data declarations In-Reply-To: <048.8e11135b0672563b5f793c5e90494439@haskell.org> References: <048.8e11135b0672563b5f793c5e90494439@haskell.org> Message-ID: <063.f5f0b59b285fbfd25ae6a40ed75317b1@haskell.org> #16311: Suggest -XExistentialQuantification for 'forall' in data declarations -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 10:41:50 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 10:41:50 -0000 Subject: [GHC] #16100: T11627a fails sometimes on CI In-Reply-To: <049.e33977a8da6d3efb347066a1a3474487@haskell.org> References: <049.e33977a8da6d3efb347066a1a3474487@haskell.org> Message-ID: <064.61dcfc434657fad5f365b64abf7f2a4e@haskell.org> #16100: T11627a fails sometimes on CI -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've also observed this `T11627a` failure on `validate-x86_64-darwin` ([https://ghc- gitlab.s3.amazonaws.com/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b/2019_02_13/27060/42255/job.log ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190213T104114Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190213 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=f7c384c7f84acb2c560f0243f14ac260daaf603a6686e676626e0a347bd55623 example]). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 10:48:17 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 10:48:17 -0000 Subject: [GHC] #15849: Error message: "Perhaps you need a let in a do block", when there is no do block. In-Reply-To: <046.1a23c56db483a32d0322994bc5b0ff58@haskell.org> References: <046.1a23c56db483a32d0322994bc5b0ff58@haskell.org> Message-ID: <061.244d0a2288b25098e0842f471290508b@haskell.org> #15849: Error message: "Perhaps you need a let in a do block", when there is no do block. -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: nineonine Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T15849 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/330 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => parser/should_fail/T15849 * status: patch => merge * milestone: => 8.8.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/a08f463bcc9727d91cec4c6e952ad0f5bbc3fbf9 a08f463bcc9727d91cec4c6e952ad0f5bbc3fbf9], marking as a merge candidate for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 11:40:09 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 11:40:09 -0000 Subject: [GHC] #16307: gloss-examples' fluid program takes close to an eternity to compile In-Reply-To: <046.47ebd2e32d20033c7ee60c2f552b77f1@haskell.org> References: <046.47ebd2e32d20033c7ee60c2f552b77f1@haskell.org> Message-ID: <061.461ea556f0f739827629b932586f3612@haskell.org> #16307: gloss-examples' fluid program takes close to an eternity to compile -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * cc: AndreasK (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 11:57:41 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 11:57:41 -0000 Subject: [GHC] #16311: Suggest -XExistentialQuantification for 'forall' in data declarations In-Reply-To: <048.8e11135b0672563b5f793c5e90494439@haskell.org> References: <048.8e11135b0672563b5f793c5e90494439@haskell.org> Message-ID: <063.705559ff9cabf4829c44ecceaa87aa00@haskell.org> #16311: Suggest -XExistentialQuantification for 'forall' in data declarations -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm especially interested in this ticket because I recently implemented a prototype of the [https://github.com/ghc-proposals/ghc-proposals/pull/193 forall-always-a-keyword-in-types] proposal, and to my surprise, this caused the stderr for `rnfail053` to change even further: {{{#!diff diff -uw "rename/should_fail/rnfail053.run/rnfail053.stderr.normalised" "rename/should_fail/rnfail053.run/rnfail053.comp.stderr.normalised" --- rename/should_fail/rnfail053.run/rnfail053.stderr.normalised 2019-02-13 06:48:37.043855139 -0500 +++ rename/should_fail/rnfail053.run/rnfail053.comp.stderr.normalised 2019-02-13 06:48:37.043855139 -0500 @@ -1,5 +1,7 @@ rnfail053.hs:5:10: - Illegal symbol ‘forall’ in type - Perhaps you intended to use RankNTypes or a similar language - extension to enable explicit-forall syntax: ‘forall . ’ + Data constructor ‘MkT’ has existential type variables, a context, or a specialised result type + MkT :: forall a. a -> T + (Enable ExistentialQuantification or GADTs to allow this) + In the definition of data constructor ‘MkT’ + In the data type declaration for ‘T’ }}} It wasn't clear to me at the time whether this was an upgrade or downgrade in error message quality, so I worked around it by making this change to the parser: {{{#!diff diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y index 820144d930..e3423669bf 100644 --- a/compiler/parser/Parser.y +++ b/compiler/parser/Parser.y @@ -2275,7 +2293,11 @@ constr :: { LConDecl GhcPs } (fst $ unLoc $2) } forall :: { Located ([AddAnn], Maybe [LHsTyVarBndr GhcPs]) } - : 'forall' tv_bndrs '.' { sLL $1 $> ([mu AnnForall $1,mj AnnDot $3], Just $2) } + : 'forall' tv_bndrs '.' {% do { hintExplicitForall $1 + ; pure $ sLL $1 $> + ( [ mu AnnForall $1 + , mj AnnDot $3 ] + , Just $2) } } | {- empty -} { noLoc ([], Nothing) } }}} That reverted the error message back to what it was before (mentioning `RankNTypes`). But perhaps the error message really ought to mention `ExistentialQuantification`. Some related questions: there are currently two distinct error messages that mention not enabling `ExistentialQuantification`: * There's the one in the original description of this ticket (the "`Not a data constructor: ‘forall’`" one). * There's also the one I mentioned in this comment (the "`has existential type variables, a context, or a specialised result type`" one). Do we need both? Or is there a way we could consolidate the two somehow? Would the answer change if we made `forall` permanently a keyword in types? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 11:58:41 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 11:58:41 -0000 Subject: [GHC] #16314: Improve confusing error message with MINIMAL pragma In-Reply-To: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> References: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> Message-ID: <060.ec1c73ec989695fd5ea6eb47bd9fede3@haskell.org> #16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): Thanks Simon. But I think your example is quite different. In your case the pragma says `f | g`. So, I do agree the definitions for them should not cause a warning. But if I said `MINIMAL f, g` (i.e., `f` and `g` *must* both be defined) and have also given a definition for one of them, surely GHC can warn about that? In case there's a complex "boolean" expression in `MINIMAL` (such as `f | g, h` etc.) this might be hard to determine, but pretty much all my use cases have been a straight list of functions and defining one should be easy to detect to violate the requirements of `MINIMAL`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 14:38:42 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 14:38:42 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.e91f5aab6973c67e4469c54c9ac2e111@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T14729{,kind} Blocked By: | Blocking: Related Tickets: #15549 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: dependent/should_compile/T14729{,kind}, typecheck/should_compile/T15549[ab] => dependent/should_compile/T14729{,kind} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 14:40:13 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 14:40:13 -0000 Subject: [GHC] #15549: Core Lint error with EmptyCase In-Reply-To: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> References: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> Message-ID: <065.0cb19900d0012235db4c7e46b0bbb2ad@haskell.org> #15549: Core Lint error with EmptyCase -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T15549[ab] Blocked By: | Blocking: Related Tickets: #14729 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => typecheck/should_compile/T15549[ab] * milestone: 8.10.1 => 8.8.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/2b90356d26b4699227816ad9424e766eccdb6c36 2b90356d26b4699227816ad9424e766eccdb6c36]. (Given the complexity of this patch, I'm not sure if it's worth trying to merge to 8.8 or not.) Echoing https://ghc.haskell.org/trac/ghc/ticket/14729#comment:14, this is a merge candidate for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 14:46:59 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 14:46:59 -0000 Subject: [GHC] #15579: topNormaliseType is wrong In-Reply-To: <046.5b7180305b5f494ab9ca559038fad023@haskell.org> References: <046.5b7180305b5f494ab9ca559038fad023@haskell.org> Message-ID: <061.a145fbb6374eadb9b3fbfd68ff502f35@haskell.org> #15579: topNormaliseType is wrong -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What is the status of this ticket now that [https://gitlab.haskell.org/ghc/ghc/commit/2b90356d26b4699227816ad9424e766eccdb6c36 2b90356d26b4699227816ad9424e766eccdb6c36] (Fix #14729 by making the normaliser homogeneous) has landed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 15:10:00 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 15:10:00 -0000 Subject: [GHC] #14671: Make the Template Haskell class Lift work over typed expressions In-Reply-To: <046.7f4fa9b815f39c9531e53be8b5e6ebfa@haskell.org> References: <046.7f4fa9b815f39c9531e53be8b5e6ebfa@haskell.org> Message-ID: <061.a56d1f84c072cdcdbf410338180e275d@haskell.org> #14671: Make the Template Haskell class Lift work over typed expressions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/351 -------------------------------------+------------------------------------- Changes (by harpocrates): * differential: Phab:D5198 => https://gitlab.haskell.org/ghc/ghc/merge_requests/351 Comment: (Same patch, just moved places) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 15:12:28 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 15:12:28 -0000 Subject: [GHC] #16314: Improve confusing error message with MINIMAL pragma In-Reply-To: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> References: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> Message-ID: <060.a800ca1e6fe994f569b1174825cae0d0@haskell.org> #16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, fine. This sounds like a feature request! The next thing to do is to write down a specification that says precisely what warnings you'd like to see under what circumstances. Maybe even worth a GHC proposal; but certainly a specification! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 15:13:40 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 15:13:40 -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.b10bb527af25bb501e9c958aad33b49b@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: partial- crash or panic | sigs/should_fail/T14040a Blocked By: | Blocking: Related Tickets: #13877, #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The error message for the `error "urk"` version has changed once again in GHC HEAD. Simon, can you spot-check this to see if this looks correct? (Modulo wildcard pretty-printing, of course.) {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20190212: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:24:41: error: • Found type wildcard ‘_’ standing for ‘_1 :: x0’ Where: ‘x0’ is an ambiguous type variable ‘_1’ is an ambiguous type variable To use the inferred type, enable PartialTypeSignatures • In the first argument of ‘p’, namely ‘_’ In the type ‘Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl’ In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 24 | -> (forall (y :: Type). p _ WeirdNil) | ^ Bug.hs:26:44: error: • Found type wildcard ‘_’ standing for ‘GHC.Types.Any :: WeirdList z’ Where: ‘z’ is a rigid type variable bound by ‘forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)’ at Bug.hs:25:27 To use the inferred type, enable PartialTypeSignatures • In the first argument of ‘p’, namely ‘_’ In the type ‘Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl’ In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 26 | Sing x -> Sing xs -> p _ xs | ^ Bug.hs:27:24: error: • Found type wildcard ‘_’ standing for ‘GHC.Types.Any :: z’ Where: ‘z’ is a rigid type variable bound by ‘forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)’ at Bug.hs:25:27 To use the inferred type, enable PartialTypeSignatures • In the first argument of ‘p’, namely ‘_’ In the type ‘Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl’ In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 27 | -> p _ (WeirdCons x xs)) | ^ Bug.hs:28:20: error: • Found type wildcard ‘_’ standing for ‘_0 :: a’ Where: ‘a’ is an ambiguous type variable ‘_0’ is an ambiguous type variable To use the inferred type, enable PartialTypeSignatures • In the first argument of ‘p’, namely ‘_’ In the type ‘Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl’ In the type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 28 | -> p _ wl | ^ Bug.hs:37:19: error: • Cannot instantiate unification variable ‘a0’ with a type involving foralls: (forall y. p _1 'WeirdNil) -> (forall z (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p GHC.Types.Any xs -> p GHC.Types.Any ('WeirdCons x xs)) -> p _0 wl GHC doesn't yet support impredicative polymorphism • In the expression: error "urk" In an equation for ‘elimWeirdList’: elimWeirdList x = error "urk" • Relevant bindings include x :: Sing wl (bound at Bug.hs:37:15) elimWeirdList :: Sing wl -> (forall y. p _1 'WeirdNil) -> (forall z (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p GHC.Types.Any xs -> p GHC.Types.Any ('WeirdCons x xs)) -> p _0 wl (bound at Bug.hs:37:1) | 37 | elimWeirdList x = error "urk" | ^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 19:08:01 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 19:08:01 -0000 Subject: [GHC] #16314: Improve confusing error message with MINIMAL pragma In-Reply-To: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> References: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> Message-ID: <060.1d27b9867a19448c20ebbb3297babe8c@haskell.org> #16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): Thanks Simon. Will do! I think the logic is quite simple even with the boolean operators, and hopefully should be trivial to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 19:40:10 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 19:40:10 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification Message-ID: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code typechecks when `k` is brought into scope explicitly, but not implicitly (code example courtesy of RyanGlScott): {{{#!hs {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} module Bug where import Data.Kind import Data.Proxy data T = forall k (a :: k). MkT (Proxy a) -- Uncomment `k` and it typechecks pattern P :: forall. () => forall {-k-} (a :: k). Proxy a -> T pattern P x = MkT (x :: Proxy (a :: k)) }}} I discovered this because I was implementing https://github.com/ghc- proposals/ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst and had to explicitly quantify some definitions in the test suite. Then the test case for #14498 stopped producing the error that it should. It seems indicative of an issue in typechecking pattern synonyms: I would expect equal treatment for implicit and explicit type/kind variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 19:58:09 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 19:58:09 -0000 Subject: [GHC] #16314: Improve confusing error message with MINIMAL pragma In-Reply-To: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> References: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> Message-ID: <060.079c0623c6629d5c91a5c7dcaafe1385@haskell.org> #16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): Another observation. I've just found out that if you try this: {{{#!hs class X a where foo :: a {-# MINIMAL #-} }}} Then GHC says: {{{ a.hs:1:1: warning: • The MINIMAL pragma does not require: ‘foo’ but there is no default implementation. • In the class declaration for ‘X’ }}} which is absolutely fantastic! So, it does implement the other side of the check. What's missing is if `MINIMAL` requires something, yet you also give a default definition for it, then it keeps quiet about it. So this request seems to fall well within the current practice of warning about these cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 20:58:22 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 20:58:22 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.017076972147333da6e0a1a481408f01@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I know what is happening here. There are two different culprits in the codebase: the renamer and the typechecker. The typechecker problem is much easier to understand. When typechecking the body of a pattern synonym, we bring certain type variables into scope. [https://gitlab.haskell.org/ghc/ghc/blob/4af0a2d609651c4bae45d84d2bf7ce9fe8cca350/compiler/typecheck/TcPatSyn.hs#L386-388 Here] is the code that does it: {{{#!hs tcExtendTyVarEnv univ_tvs $ tcExtendKindEnvList [(getName (binderVar ex_tv), APromotionErr PatSynExPE) | ex_tv <- extra_ex] $ }}} We bring the universal (required) type variables into scope, of course. We also bring the "existential" (provided) type variables into scope so that if we find any occurrences of them in the pattern synonym body, we can throw the relevant `APromotionErr` error. Why did I write "existential" in scare quotes? Because the only existential type variables that are being brought into scope are the //implicitly quantified// ones (`extra_ex`). The remaining explicitly quantified ones (which live in `ex_bndrs`) are never brought into scope. Fortunately, fixing that is as simple as replacing `extra_ex` with `ex_bndrs` in the code above. However, that change alone won't be enough. There is another problem in that GHC treats the occurrence of `k` in the pattern synonym type signature as being completely different from the occurrence of `k` in the body. Why? It's ultimately due to the renamer. In particular, because of the `forall`-or-nothing rule, the only explicitly quantified type variables that can ever brought into scope over the body must appear in a `forall` at the very front of the type signature. Since `k` is quantified by a nested `forall`, it is never brought into scope over the body during renaming, so the renamer gives a different unique to the occurrence of `k` in the body. (This is why GHC doesn't throw an error about `k` when typechecking the body, since the `k` that would throw an `APromotionErr` is actually different from the `k` in the body.) I believe that we should be able to tweak things so that the renamer brings in the explicitly quantified universals //and// existentials from a pattern synonym type signature. Experimentally, this change was sufficient to accomplish that: {{{#!diff diff --git a/compiler/hsSyn/HsTypes.hs b/compiler/hsSyn/HsTypes.hs index 5eeca6eac2..fe6849b955 100644 --- a/compiler/hsSyn/HsTypes.hs +++ b/compiler/hsSyn/HsTypes.hs @@ -51,7 +51,7 @@ module HsTypes ( mkEmptyImplicitBndrs, mkEmptyWildCardBndrs, mkHsQTvs, hsQTvExplicit, emptyLHsQTvs, isEmptyLHsQTvs, isHsKindedTyVar, hsTvbAllKinded, isLHsForAllTy, - hsScopedTvs, hsWcScopedTvs, dropWildCards, + hsScopedTvs, hsPatSynScopedTvs, hsWcScopedTvs, dropWildCards, hsTyVarName, hsAllLTyVarNames, hsLTyVarLocNames, hsLTyVarName, hsLTyVarLocName, hsExplicitLTyVarNames, splitLHsInstDeclTy, getLHsInstDeclHead, getLHsInstDeclClass_maybe, @@ -959,6 +959,20 @@ hsScopedTvs sig_ty | otherwise = [] +hsPatSynScopedTvs :: LHsSigType GhcRn -> [Name] +hsPatSynScopedTvs sig_ty + | HsIB { hsib_ext = vars + , hsib_body = sig_ty2 } <- sig_ty + , L _ (HsForAllTy { hst_bndrs = tvs, hst_body = body }) <- sig_ty2 + = vars ++ map hsLTyVarName (tvs ++ body_tvs body) + | otherwise + = [] + where + body_tvs :: LHsType GhcRn -> [LHsTyVarBndr GhcRn] + body_tvs (L _ (HsForAllTy { hst_bndrs = tvs })) = tvs + body_tvs (L _ (HsQualTy { hst_body = body })) = body_tvs body + body_tvs _ = [] + {- Note [Scoping of named wildcards] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider diff --git a/compiler/rename/RnBinds.hs b/compiler/rename/RnBinds.hs index ade67b7a49..fc5ffddfb0 100644 --- a/compiler/rename/RnBinds.hs +++ b/compiler/rename/RnBinds.hs @@ -606,7 +606,7 @@ mkScopedTvFn sigs = \n -> lookupNameEnv env n `orElse` [] get_scoped_tvs (L _ (TypeSig _ names sig_ty)) = Just (names, hsWcScopedTvs sig_ty) get_scoped_tvs (L _ (PatSynSig _ names sig_ty)) - = Just (names, hsScopedTvs sig_ty) + = Just (names, hsPatSynScopedTvs sig_ty) get_scoped_tvs _ = Nothing -- Process the fixity declarations, making a FastString -> (Located Fixity) map }}} Does this sound like the right approach? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 21:14:57 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 21:14:57 -0000 Subject: [GHC] #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases In-Reply-To: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> References: <050.919a1e01bdb4c7dd782d03b61521f072@haskell.org> Message-ID: <065.a69d587d41ce2a888202a15fe94d6d8e@haskell.org> #16199: GHC 8.6 bundles libraries that don't correspond to Hackage releases -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.4 Component: libraries | Version: 8.6.3 (other) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14678 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/139 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.4 Comment: Let's close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 22:03:34 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 22:03:34 -0000 Subject: [GHC] #16311: Suggest -XExistentialQuantification for 'forall' in data declarations In-Reply-To: <048.8e11135b0672563b5f793c5e90494439@haskell.org> References: <048.8e11135b0672563b5f793c5e90494439@haskell.org> Message-ID: <063.e6f4d8621119087ba99c90332d9b5fb9@haskell.org> #16311: Suggest -XExistentialQuantification for 'forall' in data declarations -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): > Do we need both? Or is there a way we could consolidate the two somehow? Would the answer change if we made forall permanently a keyword in types? No, we don't need both, and the `forall` proposal makes the matters trivial. See https://gitlab.haskell.org/ghc/ghc/merge_requests/363 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 22:04:37 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 22:04:37 -0000 Subject: [GHC] #16311: Suggest -XExistentialQuantification for 'forall' in data declarations In-Reply-To: <048.8e11135b0672563b5f793c5e90494439@haskell.org> References: <048.8e11135b0672563b5f793c5e90494439@haskell.org> Message-ID: <063.9ecf3d5bf2d15a7dd959d29576e4635c@haskell.org> #16311: Suggest -XExistentialQuantification for 'forall' in data declarations -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: new => patch * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 13 22:06:44 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Feb 2019 22:06:44 -0000 Subject: [GHC] #16311: Suggest -XExistentialQuantification for 'forall' in data declarations In-Reply-To: <048.8e11135b0672563b5f793c5e90494439@haskell.org> References: <048.8e11135b0672563b5f793c5e90494439@haskell.org> Message-ID: <063.0d24d0be4120541e2c141844ce2b2f07@haskell.org> #16311: Suggest -XExistentialQuantification for 'forall' in data declarations -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/363 -------------------------------------+------------------------------------- Changes (by int-index): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/363 * version: 8.6.3 => 8.7 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 05:30:54 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 05:30:54 -0000 Subject: [GHC] #16314: Improve confusing error message with MINIMAL pragma In-Reply-To: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> References: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> Message-ID: <060.920ae7fc29e5a934c039e7a7a8b33231@haskell.org> #16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): Here's a modest proposal to handle this case. The user guide says the syntax for `MINIMAL` is: {{{#!hs mindef ::= name | '(' mindef ')' | mindef '|' mindef | mindef ',' mindef }}} Strictly speaking the above is actually incorrect because it doesn't capture the fact that you can simply write `{-# MINIMAL #-}`, i.e., no methods listed at all, but that obviously would correspond to the empty set. Abusing the notation in the obvious way, define the following function from a `MINIMAL` expression to a set of names: {{{#!hs required empty_decls = Set.empty -- the missing case in the grammar required name = Set.singleton name required ('(' expr ')') = required expr required (left '|' right) = required left `Set.intersection` required right required (left ',' right) = required left `Set.union` required right }}} For each class declaration with a `MINIMAL` pragma, compute: {{{#!hs D = set of all methods with default definitions R = the required set, as defined above E = D `Set.difference` R }}} If `E` is ''not'' empty, then GHC should emit a warning saying the methods in `E` are required by the `MINIMAL` pragma but also are given a default definition. If `E` is empty, no warning is generated. I don't think we want to put definitions given with the "default signatures" extension into the set `D`; because they can be arguably considered as missing for the general case. But perhaps including them in `D` can be even a stricter check. I'd vote to leave them out to avoid false positives. This sounds simple enough to be worth an explicit GHC proposal, but I'm happy to create one if you deem it's worth it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 06:52:24 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 06:52:24 -0000 Subject: [GHC] #14671: Make the Template Haskell class Lift work over typed expressions In-Reply-To: <046.7f4fa9b815f39c9531e53be8b5e6ebfa@haskell.org> References: <046.7f4fa9b815f39c9531e53be8b5e6ebfa@haskell.org> Message-ID: <061.0fe3e0d7ea0d438a42210182f7f74a52@haskell.org> #14671: Make the Template Haskell class Lift work over typed expressions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.10.1 Component: Template Haskell | Version: 8.2.2 Resolution: fixed | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T14682 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/351 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => deriving/should_compile/T14682 * resolution: => fixed * milestone: => 8.10.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/7f26b74e409d058005909fc2b2ed2e6027d49365 7f26b74e409d058005909fc2b2ed2e6027d49365]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 08:02:27 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 08:02:27 -0000 Subject: [GHC] #16316: `-package-env=` in OPTIONS_GHC not supported Message-ID: <042.0175d4f62ce5291d9daee47759a888c9@haskell.org> #16316: `-package-env=` in OPTIONS_GHC not supported -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature | Status: new request | Priority: high | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- I just realised we're missing an ingredient in order to support persistent package-environment workflows for standalone scripts: Consider the following use-cases: ---- 1. Script requires package environemnts disabled {{{#!hs #!/usr/bin/env runghc {-# OPTIONS_GHC -package-env=- #-} main = putStrLn "Hello World" }}} ---- 2. User manually maintains a package environment for scripts or teaching exercises (this is a quite common way to teach Haskell which I subscribe to, by letting students interact with ghc and ghci directly instead, and only properly introducing `cabal` lateron when it's actually needed) {{{ cabal v2-install --lib lens lens-aeson --package-env=lets-lens }}} and the scripts shall be using that custom named package environment: {{{#!hs #!/usr/bin/env runghc {-# OPTIONS_GHC -package-env=lets-lens #-} import Control.Lens main = do putStrLn "Hello Lens" -- ...lens using code... }}} ---- Currently both of these use-cases don't work because {{{ $ ghci-8.6.3 Main.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Main.hs:3:16: error: unknown flag in {-# OPTIONS_GHC #-} pragma: -package-env=lets-lens | 3 | {-# OPTIONS_GHC -package-env=lets-lens #-} | ^^^^^^^^^^^^^^^^^^^^^^^^ }}} I do realise that it's tricky to support package-db related commands in `OPTIONS_GHC` but it'd nevertheless be quite important to support this in some way (possibly with some restrictions) in order to properly support the package-env based workflows (NB: the legacy user pkg-db based ones aren't available anymore in future cabal versions -- package-environments have completely replaced the legacy user-pkg db there). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 08:46:42 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 08:46:42 -0000 Subject: [GHC] #16314: Improve confusing error message with MINIMAL pragma In-Reply-To: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> References: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> Message-ID: <060.ba8fe95dc6bc76509d09226537f8c7c8@haskell.org> #16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > This sounds simple enough to be worth an explicit GHC proposal, but I'm happy to create one if you deem it's worth it. Yes, now I understand the proposal, thanks. I do think it's worth a proposal. I've been struck by how often people chime in with helpful comments that make the idea better. And it won't take long, and it documents the intent. Plus, it's all about what users want, so asking users is a good plan. Why not add the empty case at the same time (only a user-manual change). Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 10:39:12 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 10:39:12 -0000 Subject: [GHC] #16317: HIE files don't include module import/export information Message-ID: <049.754179950e9512ffd6a1ff36d9542e79@haskell.org> #16317: HIE files don't include module import/export information -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- HIE files don't record information about import/exports. This blocks implementing LSIF files which need to know about imports/exports. Export information can be read from `tcg_exports`. Import information can be got from the `HscEnv` and looked up using `findImportedModule` I think. Would be good to target this for 8.8 if there is any time remaining. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 12:59:30 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 12:59:30 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.f74701acedef788839189f8fac1ee05c@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13275, #15181 | Differential Rev(s): Phab:D4733 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: sighingnow => (none) * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 13:08:09 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 13:08:09 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.5b7d3040e4b4bf4441633de48c0ea93f@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13275, #15181 | Differential Rev(s): Phab:D4733 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yikes. I have just wasted 30 minutes (in Core dumps) figuring out why a type printed as {{{ forall a b. Eq a => blah }}} didn't match a term {{{ /\ a. \(d :: Eq a). blah }}} Turns out that the real type is `forall a. Eq a => forall b. blah`, but the pretty printer silently moves the foralls to the top. This is done in `splitIfaceSigmaTy` in the patch in comment:13. It might be ''just'' arguable to move the foralls around for ''user'' types. E.g in test `ghci025` we now report {{{ return :: Monad m => a -> m a }}} whereas previously it was {{{ return :: Monad m => forall a. a -> m a }}} But we definitely should not do this in Core printouts. I also noticed that in the output for `ghci025` we have {{{ c3 :: forall a b a. C a b => a -> b }}} The repeated 'a' is terrible! So I'm re-opening this ticket to ask: do we want to swizzle the foralls to the top, even in user printout? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 13:53:15 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 13:53:15 -0000 Subject: [GHC] #16318: Explicitly passing -package-env causes "Loaded package environment from .ghc.environment" message to be printed twice Message-ID: <050.1473c530d0a90fae443e0e00872a0b4e@haskell.org> #16318: Explicitly passing -package-env causes "Loaded package environment from .ghc.environment" message to be printed twice -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.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: -------------------------------------+------------------------------------- {{{ $ /opt/ghc/8.6.3/bin/ghc -package-env .ghc.environment.x86_64-linux-8.6.3 -e "putStrLn \"Hello\"" Loaded package environment from .ghc.environment.x86_64-linux-8.6.3 Loaded package environment from .ghc.environment.x86_64-linux-8.6.3 Hello }}} This is a regression from GHC 8.4.4: {{{ $ /opt/ghc/8.4.4/bin/ghc -package-env .ghc.environment.x86_64-linux-8.4.4 -e "putStrLn \"Hello\"" Loaded package environment from .ghc.environment.x86_64-linux-8.4.4 Hello }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 14:20:56 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 14:20:56 -0000 Subject: [GHC] #16319: unexpected difference between newtype and data Message-ID: <049.b77ffeefa62b8da598a1a219151c19c3@haskell.org> #16319: unexpected difference between newtype and data ----------------------------------------+--------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The following code compiles fine {{{#!hs -- | A referable class -- An object can only have one reference. -- For example, a function is either referenced by name of by signature but not both. class ( Eq (Ref a) , Ord (Ref a) , Hashable (Ref a) , Show (Ref a) , Read (Ref a) , Data (Ref a) ) => Referable a where type Ref a toRef :: a -> Ref a data Referable a => RefMap a = RefMap { -- | the HashMap toHashMap :: HashMap.Map (Ref a) a } deriving (Eq, Ord, Show, Read, Data) }}} yet following the hlint hint to replace data by the equivalent newtype results in the following issues: {{{ src\TorXakis\Referable.hs:59:43: error: * Could not deduce (Eq (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: Eq a bound by the deriving clause for `Eq (RefMap a)' at src\TorXakis\Referable.hs:59:43-44 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Eq (RefMap a)) | 59 | } deriving (Eq, Ord, Show, Read, Data) | ^^ src\TorXakis\Referable.hs:59:47: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: Ord a bound by the deriving clause for `Ord (RefMap a)' at src\TorXakis\Referable.hs:59:47-49 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Ord (RefMap a)) | 59 | } deriving (Eq, Ord, Show, Read, Data) }}} I assume this is a bug... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 14:28:49 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 14:28:49 -0000 Subject: [GHC] #16319: unexpected difference between newtype and data In-Reply-To: <049.b77ffeefa62b8da598a1a219151c19c3@haskell.org> References: <049.b77ffeefa62b8da598a1a219151c19c3@haskell.org> Message-ID: <064.8b6fbd6c83304cb7e1e117df3fe3f3a9@haskell.org> #16319: unexpected difference between newtype and data ---------------------------------+---------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by goldfire): Hm. It looks like the `newtype` deriving strategy (which is what would be used for `Eq` and `Ord` but not for others) ignores datatype contexts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 14:37:36 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 14:37:36 -0000 Subject: [GHC] #16314: Improve confusing error message with MINIMAL pragma In-Reply-To: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> References: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> Message-ID: <060.2a8d72edf112bc91402e191b05fa837f@haskell.org> #16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): Will do! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 15:29:58 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 15:29:58 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.47c24d37b8351752aec8e211723da81a@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13275, #15181 | Differential Rev(s): Phab:D4733 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Another oddity is that `elminiateRunTimeRep` (which works recursively) is called by `pprIfaceSigmaTy`, which is called from `ppr_sigma` which is called by `ppr_ty` which is also recursive. This can't be right. I think `eliminateRuntimeRep` should only be called at top level -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 15:43:58 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 15:43:58 -0000 Subject: [GHC] #16319: unexpected difference between newtype and data In-Reply-To: <049.b77ffeefa62b8da598a1a219151c19c3@haskell.org> References: <049.b77ffeefa62b8da598a1a219151c19c3@haskell.org> Message-ID: <064.f1a95516cd90686e15f9d00a36edd8fd@haskell.org> #16319: unexpected difference between newtype and data ---------------------------------+---------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by RyanGlScott): Indeed, `GeneralizedNewtypeDeriving` (and `DerivingVia`) have never taken the "stupid theta" (i.e., `DatatypeContexts`) into account when generating code for whatever reason. Fixing this wouldn't be too difficult (I think you'd just need to change the relevant bits in `TcDeriv`), but is it really worth it? `DatatypeContexts` is a deprecated feature: {{{ λ> :set -XDatatypeContexts : warning: -XDatatypeContexts is deprecated: It was widely considered a misfeature, and has been removed from the Haskell language. }}} And I'm not sure if it's worthwhile to continue to maintain it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 15:46:18 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 15:46:18 -0000 Subject: [GHC] #15219: Implement UnliftedNewtypes proposal In-Reply-To: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> References: <049.9ab4f7af374c37f017e858e7629cfd2f@haskell.org> Message-ID: <064.3e57869bdd2a411c96281b0cb77cec49@haskell.org> #15219: Implement UnliftedNewtypes proposal -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | UnliftedNewtypes, GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1311 | Differential Rev(s): Phab:D4777, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/364 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D4777 => Phab:D4777, https://gitlab.haskell.org/ghc/ghc/merge_requests/364 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 15:46:25 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 15:46:25 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.7aa3810b02a5591a6dee153c88872ff7@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: (none) Type: feature request | Status: patch Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15219 | Differential Rev(s): Phab:D4777, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/364 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D4777 => Phab:D4777, https://gitlab.haskell.org/ghc/ghc/merge_requests/364 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 15:47:16 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 15:47:16 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMzU5NTogU2hvdWxkIOKAmGNvZXJjZeKAmSBi?= =?utf-8?q?e_levity_polymorphic=3F?= In-Reply-To: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> References: <051.625d9a98e0349d1f7fb916d9c9ad0e42@haskell.org> Message-ID: <066.98e31052a3d407536467128d0df3bc73@haskell.org> #13595: Should ‘coerce’ be levity polymorphic? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13592 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/364 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/364 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 15:47:23 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 15:47:23 -0000 Subject: [GHC] #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) In-Reply-To: <051.8c8f3c0ace71ad8ecb6463da73c07735@haskell.org> References: <051.8c8f3c0ace71ad8ecb6463da73c07735@haskell.org> Message-ID: <066.d75f1b0a4f6352e1e097dc814d5f5b0b@haskell.org> #15883: GHC panic: newtype F rep = F (forall (a :: TYPE rep). a) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: Resolution: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4777, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/364 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D4777 => Phab:D4777, https://gitlab.haskell.org/ghc/ghc/merge_requests/364 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 15:51:12 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 15:51:12 -0000 Subject: [GHC] #15952: Reduce zonking-related invariants in the type checker In-Reply-To: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> References: <047.c42ea2b79609ea4ac043c4aadd1f2615@haskell.org> Message-ID: <062.e40a575a5f8e50a552f6bfe32d13e340@haskell.org> #15952: Reduce zonking-related invariants in the type checker -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/206 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/206 * resolution: => fixed * milestone: => 8.10.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/682783828275cca5fd8bf5be5b52054c75e0e22c 682783828275cca5fd8bf5be5b52054c75e0e22c]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 15:53:21 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 15:53:21 -0000 Subject: [GHC] #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. In-Reply-To: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> References: <047.c8cd5d08c6670129ab47a7226e6c441a@haskell.org> Message-ID: <062.8866d80613dba997d4635b06b26098f9@haskell.org> #15957: Provide warning for when RecordWildCards LHS {..} doesn't bind anything. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_compile/T15957, | rename/should_fail/T15957_Fail Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/346 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => rename/should_compile/T15957, rename/should_fail/T15957_Fail * status: new => closed * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/346 * resolution: => fixed * milestone: => 8.10.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/19626218566ea709b5f6f287d3c296b0c4021de2 19626218566ea709b5f6f287d3c296b0c4021de2]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 16:09:25 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 16:09:25 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.a4ad6910cfdde446f709633693af28f2@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found -------------------------------------+------------------------------------- Reporter: mietek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 (Linker) | Keywords: panic, Resolution: | dynamic linking Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #8935, #9034, | Differential Rev(s): #9074, #9278 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mietek): My test case repository is now named https://github.com/mietek/ghc- issue-9277. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 16:20:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 16:20:38 -0000 Subject: [GHC] #10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just In-Reply-To: <045.560814a380f9a1315a0b9eab831acc66@haskell.org> References: <045.560814a380f9a1315a0b9eab831acc66@haskell.org> Message-ID: <060.e35d84f14facb9c7b492258a1c23009d@haskell.org> #10173: Panic: Irrefutable pattern failed for pattern Data.Maybe.Just ---------------------------------------+------------------------------ Reporter: mietek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Comment (by mietek): This issue is no longer relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 16:21:11 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 16:21:11 -0000 Subject: [GHC] #10187: Panic: RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order; bad blockId c8xHd In-Reply-To: <045.854a7c2e83fb00658c4034e982e2f0f4@haskell.org> References: <045.854a7c2e83fb00658c4034e982e2f0f4@haskell.org> Message-ID: <060.7b6c1ad7c11c0f43320ae8dbe9866544@haskell.org> #10187: Panic: RegAlloc.Liveness.computeLivenss; SCCs aren't in reverse dependent order; bad blockId c8xHd ---------------------------------------+------------------------------ Reporter: mietek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: #9541, #9031 | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Comment (by mietek): This issue is no longer relevant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 16:46:42 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 16:46:42 -0000 Subject: [GHC] #16228: ghc-pkg and ghc do not agree about package with internal libraries In-Reply-To: <048.4844eff8eedd12903d2ac77488728672@haskell.org> References: <048.4844eff8eedd12903d2ac77488728672@haskell.org> Message-ID: <063.49928c7ef00b8db7f4aca88c297a7d77@haskell.org> #16228: ghc-pkg and ghc do not agree about package with internal libraries ---------------------------------+-------------------------------------- Reporter: michaelpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by michaelpj): This seems to only sometimes happen. In particular, depending on apparently unrelated downstream changes, the workaround of passing `-package foo` will occasionally stop working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 17:27:31 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 17:27:31 -0000 Subject: [GHC] #16208: map/coerce does not fire with all newtypes In-Reply-To: <047.6e6dd4b904ee0227174b737189ff29c7@haskell.org> References: <047.6e6dd4b904ee0227174b737189ff29c7@haskell.org> Message-ID: <062.0219d05b0853b75e9da931a4d52ac91e@haskell.org> #16208: map/coerce does not fire with all newtypes -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by aspiwack): * cc: aspiwack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 20:42:20 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 20:42:20 -0000 Subject: [GHC] #16320: Clean up printing of foralls Message-ID: <047.409f8fb8202cb591e7e03bb215b26444@haskell.org> #16320: Clean up printing of foralls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Simon and I agreed on several infelicities around the printing of types with foralls. Before cleaning up the code, though, we wanted a ''specification'' of what we should do. Here is what we have. When printing types for users (in GHCi and certain error messages), it is convenient to sometimes suppress `forall`s. Given a type `ty` to print, `forall`s will be suppressed when ''all'' of the following are true: 1. `-fprint-explicit-foralls` is not in effect. 2. The kinds of all bound type variables are Haskell98-style. That is, the kinds consist only of `Type` and `->`. 3. No bound type variable is `Required`. 4. The `forall`s are all at the top. Exception: `forall`s are allowed to be mixed with class constraints, but no `forall`s can appear under a proper `->`. 5. No two quantified type variables are spelled the same. This decision is made once, while looking at the overall type. Once made, it is not challenged: either all `forall`s in a type are printed, or none are. Reasons behind the conditions: 1. No comment. 2. Currently, we print `forall k (a :: k). ...` when there is a bound type variable with a variable kind. But, really, the fact that it's a variable isn't the only way it could be interesting. 3. `Required` type variables must be supplied; omitting these would be very confusing. 4. If a type has nested `forall`s, it's best to print. Reason for exception: the type of `return` is properly `forall (m :: Type -> Type). Monad m => forall (a :: Type). a -> m a`. Note that a `forall` is under a class constraint. But we want to suppress the `forall`s there, too. 5. Imagine this abuse of our language: {{{#!hs class C a b where meth :: forall a. a -> b }}} The type of `meth` is `forall a b. C a b => forall a. a -> b`. This is, actually, a well-formed type, where one type variable shadows another. But if we don't print the `forall`s, any reader will come to the wrong conclusion about the meaning of the type. This is a slight tweak to the current rules, meaning more `forall`s are printed than previously. Pointedly, this will not happen in Haskell98-style code, so they will not appear for beginners. The current state of affairs is messy, on the other hand, where some `forall`s may be suppressed in a type while others are printed, causing more trouble. While in town, any fix should also address comment:17:ticket:11786, which is about a seeming inefficiency of the implementation of `eliminateRuntimeReps`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 20:42:46 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 20:42:46 -0000 Subject: [GHC] #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks In-Reply-To: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> References: <046.943657e3f9ed3d83fd8aca1ffc9a9fa0@haskell.org> Message-ID: <061.1a7008f0414e045d9aaaef94ae781cbd@haskell.org> #11786: Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13275, #15181 | Differential Rev(s): Phab:D4733 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: It seems a new ticket makes more sense: #16320. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 21:20:42 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 21:20:42 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.d7cf7326e823aa36559785cfe0622f70@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): From the `Note [Pattern synonym existentials do not scope]`, it sounds like we aim to ''reject'' this code, not accept it. Do you find differently? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 21:22:14 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 21:22:14 -0000 Subject: [GHC] #15579: topNormaliseType is wrong In-Reply-To: <046.5b7180305b5f494ab9ca559038fad023@haskell.org> References: <046.5b7180305b5f494ab9ca559038fad023@haskell.org> Message-ID: <061.a7a32c09900c444987c293a23f12c3fd@haskell.org> #15579: topNormaliseType is wrong -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: This is, in reality, a documentation error. I updated the documentation in that patch. No bug here (despite "(1) is a bug"). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 21:27:34 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 21:27:34 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.4de6880d34349d0d10b8385f95b9dd53@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Yes, I wrote comment:1 in mind with the goal of rejecting the original program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 21:31:27 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 21:31:27 -0000 Subject: [GHC] #16321: Suggest -XScopedTypeVariables instead of -XRankNTypes Message-ID: <048.e17c3987d80b41f68a946f2ae2fb8449@haskell.org> #16321: Suggest -XScopedTypeVariables instead of -XRankNTypes -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When the parser encounters an explicit `forall` when `-XExplicitForAll` is disabled, it tries to guess what the user meant and suggests to enable `-XRankNTypes`: {{{ Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall . }}} Richard argues we are better off suggesting `-XScopedTypeVariables` by default: > Consider these workflows: > > 1a. User is writing a higher-rank type without extensions. GHC suggests to enable RankNTypes. Program is accepted. > > 1b. User is writing a higher-rank type without extensions. GHC suggests to enable ScopedTypeVariables. User compiles again, and GHC suggests to enable RankNTypes. Program is accepted. > > 2a. User is writing a program that requires scoped type variables. GHC suggests to enable RankNTypes. Program is rejected with inscrutable type errors claiming that `a` is not `a0`. > > 2b. User is writing a program that requires scoped type variables. GHC suggests to enable ScopedTypeVariables. Program is accepted. > > The question is: what's worse: 1b, or 2a? I claim that 2a is worse, and so I favor making the change so that we avoid 2a in favor of sometimes incurring 1b. The problem here is that in the grand scheme of things, we want neither 1b nor 2a to happen. What would it take to implement a proper diagnostic and always suggest the appropriate extension? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 22:57:58 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 22:57:58 -0000 Subject: [GHC] #16320: Clean up printing of foralls In-Reply-To: <047.409f8fb8202cb591e7e03bb215b26444@haskell.org> References: <047.409f8fb8202cb591e7e03bb215b26444@haskell.org> Message-ID: <062.9939f7ac835061590b0200fd66004159@haskell.org> #16320: Clean up printing of foralls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Simon and I agreed on several infelicities around the printing of types > with foralls. Before cleaning up the code, though, we wanted a > ''specification'' of what we should do. Here is what we have. > > When printing types for users (in GHCi and certain error messages), it is > convenient to sometimes suppress `forall`s. Given a type `ty` to print, > `forall`s will be suppressed when ''all'' of the following are true: > > 1. `-fprint-explicit-foralls` is not in effect. > 2. The kinds of all bound type variables are Haskell98-style. That is, > the kinds consist only of `Type` and `->`. > 3. No bound type variable is `Required`. > 4. The `forall`s are all at the top. Exception: `forall`s are allowed to > be mixed with class constraints, but no `forall`s can appear under a > proper `->`. > 5. No two quantified type variables are spelled the same. > > This decision is made once, while looking at the overall type. Once made, > it is not challenged: either all `forall`s in a type are printed, or none > are. > > Reasons behind the conditions: > > 1. No comment. > 2. Currently, we print `forall k (a :: k). ...` when there is a bound > type variable with a variable kind. But, really, the fact that it's a > variable isn't the only way it could be interesting. > 3. `Required` type variables must be supplied; omitting these would be > very confusing. > 4. If a type has nested `forall`s, it's best to print. Reason for > exception: the type of `return` is properly `forall (m :: Type -> Type). > Monad m => forall (a :: Type). a -> m a`. Note that a `forall` is under a > class constraint. But we want to suppress the `forall`s there, too. > 5. Imagine this abuse of our language: > > {{{#!hs > class C a b where > meth :: forall a. a -> b > }}} > > The type of `meth` is `forall a b. C a b => forall a. a -> b`. This is, > actually, a well-formed type, where one type variable shadows another. > But if we don't print the `forall`s, any reader will come to the wrong > conclusion about the meaning of the type. > > This is a slight tweak to the current rules, meaning more `forall`s are > printed than previously. Pointedly, this will not happen in > Haskell98-style code, so they will not appear for beginners. The current > state of affairs is messy, on the other hand, where some `forall`s may be > suppressed in a type while others are printed, causing more trouble. > > While in town, any fix should also address comment:17:ticket:11786, which > is about a seeming inefficiency of the implementation of > `eliminateRuntimeReps`. New description: Simon and I agreed on several infelicities around the printing of types with foralls. Before cleaning up the code, though, we wanted a ''specification'' of what we should do. Here is what we have. When printing types for users (in GHCi and certain error messages), it is convenient to sometimes suppress `forall`s. Given a type `ty` to print, `forall`s will be suppressed when ''all'' of the following are true: 1. `-fprint-explicit-foralls` is not in effect. 2. The kinds of all bound type variables are Haskell98-style. That is, the kinds consist only of `Type` and `->`. 3. No bound type variable is `Required`. 4. The `forall`s are all at the top. Exception: `forall`s are allowed to be mixed with class constraints, but no `forall`s can appear under a proper `->`. 5. No two quantified type variables are spelled the same. This decision is made once, while looking at the overall type. Once made, it is not challenged: either all `forall`s in a type are printed, or none are. Notice that if any foralls are suppressed, then they are all at the "top" of the type (albeit possibly under class constraints). Reasons behind the conditions: 1. No comment. The ''only'' effect of `-fprint-explicit-foralls` should be to turn off the suppression of foralls, and print all foralls unconditionally. 2. Currently, we print `forall k (a :: k). ...` when there is a bound type variable with a variable kind. But, really, the fact that it's a variable isn't the only way it could be interesting. E.g. `forall (a :: Nat). blah` 3. `Required` type variables must be supplied; omitting these would be very confusing. E.b. in `T :: forall k -> k -> Type` it would be jolly confusing to omit the `forall k ->` part, leaving `T :: k -> Type`. 4. If a type has nested `forall`s, it's best to print all the foralls, including any at the top. Example {{{ f :: forall a. (forall b. b -> b) -> a -> a }}} Currently we suppress the outer forall, but with the nested forall we are well out of Haskell98-land and it seems better to display them all. Reason for exception: the type of `return` is properly {{{ return :: forall (m :: Type -> Type). Monad m => forall (a :: Type). a -> m a }}} Note that a `forall` is under a class constraint. But we want to suppress the `forall`s there, too, to display {{{ return :: Monad m => a -> m a }}} 5. Imagine this abuse of our language: {{{#!hs class C a b where meth :: forall a. a -> b }}} The type of `meth` is `forall a b. C a b => forall a. a -> b`. This is, actually, a well-formed type, where one type variable shadows another. But if we don't print the `forall`s, any reader will come to the wrong conclusion about the meaning of the type. This is a slight tweak to the current rules, meaning more `forall`s are printed than previously. Pointedly, this will not happen in Haskell98-style code, so they will not appear for beginners. The current state of affairs is messy, on the other hand, where some `forall`s may be suppressed in a type while others are printed, causing more trouble. While in town, any fix should also address comment:17:ticket:11786, which is about a seeming inefficiency of the implementation of `eliminateRuntimeReps`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 14 23:16:21 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 14 Feb 2019 23:16:21 -0000 Subject: [GHC] #16313: Core Lint warning (Unsafe coercion: {left, right}-hand type is levity-polymorphic) In-Reply-To: <050.474e30199f4ed213e19d2a554c242efb@haskell.org> References: <050.474e30199f4ed213e19d2a554c242efb@haskell.org> Message-ID: <065.0e4d444d6f2dd724e433846f9f3907d9@haskell.org> #16313: Core Lint warning (Unsafe coercion: {left,right}-hand type is levity- polymorphic) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Hrm. Maybe I was too quick to say that any bleating from core-lint meant we have a GHC bug. I've never been comfortable with this sort of check, really. I advocate dropping the check... or finding a way to suppress the warning. Simon, this comes from #9122, where you wanted to institute this sorts of checks. The problem is that there's no way of getting rid of the warning (while keeping the more important `-dcore-lint` checks enabled). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 00:09:27 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 00:09:27 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop Message-ID: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- I was trying to create a newtype instance for the `SqlSelect`(https://hackage.haskell.org/package/esqueleto-2.5.3/docs /Database-Esqueleto-Internal-Sql.html#t:SqlSelect) class from the `esqueleto` library. It has multiple type arguments so I was using StandaloneDeriving: {{{ newtype X a b = X { unX :: b } deriving newtype instance SqlSelect b c => SqlSelect (X a b) (X a c) }}} Unfortunately, this generates code which must include an infinite loop, because the compiled code spins, but replacing it with the obvious handwritten instance seems to fix the problem. Apologies if this has been reported or fixed elsewhere, I was unable to find any matching issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 00:09:57 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 00:09:57 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.09a58813b21c61228602b792c3fc6878@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by paf31: Old description: > I was trying to create a newtype instance for the > `SqlSelect`(https://hackage.haskell.org/package/esqueleto-2.5.3/docs > /Database-Esqueleto-Internal-Sql.html#t:SqlSelect) class from the > `esqueleto` library. It has multiple type arguments so I was using > StandaloneDeriving: > > {{{ > newtype X a b = X { unX :: b } > > deriving newtype instance SqlSelect b c => SqlSelect (X a b) (X a c) > }}} > > Unfortunately, this generates code which must include an infinite loop, > because the compiled code spins, but replacing it with the obvious > handwritten instance seems to fix the problem. > > Apologies if this has been reported or fixed elsewhere, I was unable to > find any matching issues. New description: I was trying to create a newtype instance for the `SqlSelect`(https://hackage.haskell.org/package/esqueleto-2.5.3/docs /Database-Esqueleto-Internal-Sql.html#t:SqlSelect) class from the `esqueleto` library. It has multiple type arguments so I was using StandaloneDeriving and DerivingStrategies: {{{ newtype X a b = X { unX :: b } deriving newtype instance SqlSelect b c => SqlSelect (X a b) (X a c) }}} Unfortunately, this generates code which must include an infinite loop, because the compiled code spins, but replacing it with the obvious handwritten instance seems to fix the problem. Apologies if this has been reported or fixed elsewhere, I was unable to find any matching issues. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 00:41:01 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 00:41:01 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" In-Reply-To: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> References: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> Message-ID: <064.163ed2b83651c70553e2e5bd32aae70b@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ---------------------------------+---------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 basvandijk): I was able to create a minimal test-case for this. Please have a look at: https://github.com/basvandijk/macos-ghc863-panic -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 01:06:36 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 01:06:36 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" In-Reply-To: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> References: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> Message-ID: <064.a0f294db947004418cbcb87c03cbb8d4@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ---------------------------------+---------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.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 basvandijk): * priority: normal => high Old description: > When building the latest `opencv-extra` library on OS X I'm getting a GHC > panic. To reproduce git clone https://github.com/LumiGuide/haskell- > opencv, make sure Nix is installed and execute: > > {{{ > > nix-build -A haskellPackages.opencv-extra > ... > [11 of 11] Compiling OpenCV.Extra ( src/OpenCV/Extra.hs, > dist/build/OpenCV/Extra.p_o ) > ghc: panic! (the 'impossible' happened) > (GHC version 8.6.3 for x86_64-apple-darwin): > Data.Binary.Get.runGet at position 8: Invalid magic number > "INPUT(-l" > CallStack (from HasCallStack): > error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in > binary-0.8.6.0:Data.Binary.Get > }}} > > The library builds successfully on Linux. New description: When building the latest `opencv-extra` library on OS X I'm getting a GHC panic. To reproduce git clone https://github.com/LumiGuide/haskell-opencv, make sure Nix is installed and execute: {{{ > nix-build -A haskellPackages.opencv-extra ... [11 of 11] Compiling OpenCV.Extra ( src/OpenCV/Extra.hs, dist/build/OpenCV/Extra.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.3 for x86_64-apple-darwin): Data.Binary.Get.runGet at position 8: Invalid magic number "INPUT(-l" CallStack (from HasCallStack): error, called at libraries/binary/src/Data/Binary/Get.hs:351:5 in binary-0.8.6.0:Data.Binary.Get }}} The library builds successfully on Linux. Minimal test case: https://github.com/basvandijk/macos-ghc863-panic -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 04:31:21 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 04:31:21 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" In-Reply-To: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> References: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> Message-ID: <064.780c08677b75b15a0bbe8ef4ee1aa937@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ---------------------------------+---------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.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 basvandijk): As I just mentioned in the [https://github.com/basvandijk/macos- ghc863-panic#observations README] I discovered that the panic is caused by a `ghc -staticlib` invocation. When I disable building a static library the build succeeds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 08:24:08 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 08:24:08 -0000 Subject: [GHC] #16313: Core Lint warning (Unsafe coercion: {left, right}-hand type is levity-polymorphic) In-Reply-To: <050.474e30199f4ed213e19d2a554c242efb@haskell.org> References: <050.474e30199f4ed213e19d2a554c242efb@haskell.org> Message-ID: <065.136dd276386dc0e386d8aacf7c0bb5f1@haskell.org> #16313: Core Lint warning (Unsafe coercion: {left,right}-hand type is levity- polymorphic) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Precisely which checks are you advocating removing? Are you arguing that if Lint sees `3# |> UnsafeCoerce(..) :: Int`, which coerces an `Int#` to an `Int`, that it should remain silent? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 08:53:01 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 08:53:01 -0000 Subject: [GHC] #16323: Cannot deduce X error with X provided Message-ID: <049.3fcc7dff885b59db8882798907b77f4c@haskell.org> #16323: Cannot deduce X error with X provided ----------------------------------------+--------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- The following code {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE TypeFamilies #-} module TorXakis.Test ( -- * Referable Referable(..) ) where import Data.Hashable import qualified Data.HashMap as HashMap -- | A referable class class Referable a where type Ref a toRef :: a -> Ref a -- | Map of Referable objects. data (Referable a, Ord (Ref a), Hashable (Ref a)) => RefMap a = RefMap { -- | the HashMap toHashMap :: HashMap.Map (Ref a) a } deriving (Eq, Ord, Show, Read) }}} gives the following errors {{{ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:43: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Eq a, Referable a) bound by the deriving clause for `Eq (RefMap a)' at src\TorXakis\Test.hs:20:43-44 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Eq (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:47: error: * Could not deduce (Hashable (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Ord a, Referable a) bound by the deriving clause for `Ord (RefMap a)' at src\TorXakis\Test.hs:20:47-49 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Ord (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:52: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Show a, Referable a) bound by the deriving clause for `Show (RefMap a)' at src\TorXakis\Test.hs:20:52-55 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Show (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:58: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Read a, Referable a) bound by the deriving clause for `Read (RefMap a)' at src\TorXakis\Test.hs:20:58-61 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Read (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^^ -- While building package txs-basics-0.1.0.0 using: C:\sr\setup-exe-cache\x86_64-windows-integersimple\Cabal- simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe --builddir=.stack-w ork\dist\67675594 build lib:txs-basics --ghc-options " -ddump-hi -ddump- to-file" Process exited with code: ExitFailure 1 }}} yet the requirements such as {{{Ord (Ref a)}}} are clearly given to the data definition! possibly related to #16319 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 08:53:38 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 08:53:38 -0000 Subject: [GHC] #16323: Cannot deduce X error with X provided in TypeFamilies (was: Cannot deduce X error with X provided) In-Reply-To: <049.3fcc7dff885b59db8882798907b77f4c@haskell.org> References: <049.3fcc7dff885b59db8882798907b77f4c@haskell.org> Message-ID: <064.bd50950b0d8f11c6e7cd68ae17864fa7@haskell.org> #16323: Cannot deduce X error with X provided in TypeFamilies ---------------------------------+---------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 08:57:05 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 08:57:05 -0000 Subject: [GHC] #16323: Cannot deduce X error with X provided in TypeFamilies In-Reply-To: <049.3fcc7dff885b59db8882798907b77f4c@haskell.org> References: <049.3fcc7dff885b59db8882798907b77f4c@haskell.org> Message-ID: <064.d361e3f38acad394a1c0c0cbd1b367ae@haskell.org> #16323: Cannot deduce X error with X provided in TypeFamilies ---------------------------------+---------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Deriving 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 simonpj): * keywords: => Deriving -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 09:14:54 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 09:14:54 -0000 Subject: [GHC] #16323: Cannot deduce X error with X provided in TypeFamilies In-Reply-To: <049.3fcc7dff885b59db8882798907b77f4c@haskell.org> References: <049.3fcc7dff885b59db8882798907b77f4c@haskell.org> Message-ID: <064.b8a9a2d92d7d3c210be48de3cf40a827@haskell.org> #16323: Cannot deduce X error with X provided in TypeFamilies ---------------------------------+---------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Deriving Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by pjljvdlaar): replacing data by newtype give slightly different errors {{{Eq (Ref a)}}} is also required. Adding this to the definition, i.e. {{{#!hs newtype (Referable a, Eq (Ref a), Ord (Ref a), Hashable (Ref a)) => RefMap a = RefMap { -- | the HashMap toHashMap :: HashMap.Map (Ref a) a } deriving (Eq, Ord, Show, Read) }}} still give the same errors for newtype (yet different from data): {{{ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:43: error: * Could not deduce (Eq (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: Eq a bound by the deriving clause for `Eq (RefMap a)' at src\TorXakis\Test.hs:20:43-44 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Eq (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:47: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: Ord a bound by the deriving clause for `Ord (RefMap a)' at src\TorXakis\Test.hs:20:47-49 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Ord (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:52: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Show a, Referable a) bound by the deriving clause for `Show (RefMap a)' at src\TorXakis\Test.hs:20:52-55 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Show (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^^ C:\TorXakis\sys\txs-basics\src\TorXakis\Test.hs:20:58: error: * Could not deduce (Ord (Ref a)) arising from the 'deriving' clause of a data type declaration from the context: (Read a, Referable a) bound by the deriving clause for `Read (RefMap a)' at src\TorXakis\Test.hs:20:58-61 Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Read (RefMap a)) | 20 | } deriving (Eq, Ord, Show, Read) | ^^^^ -- While building package txs-basics-0.1.0.0 using: C:\sr\setup-exe-cache\x86_64-windows-integersimple\Cabal- simple_Z6RU0evB_2.0.1.0_ghc-8.2.2.exe --builddir=.stack-w ork\dist\67675594 build lib:txs-basics --ghc-options " -ddump-hi -ddump- to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 10:16:52 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 10:16:52 -0000 Subject: [GHC] #16324: ghc-pkg: Batched package unregister takes time linear to the batch size Message-ID: <045.3bf0ab18905d99b5c6e2ee102c60ea45@haskell.org> #16324: ghc-pkg: Batched package unregister takes time linear to the batch size -------------------------------------+------------------------------------- Reporter: qrilka | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- When started using batched `ghc-pkg unregister` (implemented in #12637) we have noticed that it did not give much time speed improvements. I've created a simple reproduction of that behavior in https://github.com/qrilka/pkg-db-problems (which is a bit of package db abuse of cause as the same package gets registered multiple times with different ids). The last run of that script gave me: {{{ qrilka at qdesktop ~/ws/h/pkg-db-problems $ ./test.sh Up to date Reading package info from "dist- newstyle/packagedb/ghc-8.6.3/sample-1.0.0-inplace.conf" ... done. sample-1.0.0: Warning: haddock-interfaces: /home/qrilka/ws/h/pkg-db- problems/dist- newstyle/build/x86_64-linux/ghc-8.6.3/sample-1.0.0/doc/html/sample/sample.haddock doesn't exist or isn't a file sample-1.0.0: Warning: haddock-html: /home/qrilka/ws/h/pkg-db-problems /dist-newstyle/build/x86_64-linux/ghc-8.6.3/sample-1.0.0/doc/html/sample doesn't exist or isn't a directory Unregistering single package: real 0m0,196s user 0m0,175s sys 0m0,020s Unregistering 15 packages: real 0m2,471s user 0m2,340s sys 0m0,130s }}} Which clearly shows speed problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 10:21:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 10:21:56 -0000 Subject: [GHC] #16001: hadrian doesn't support setting intree gmp configuration explicitly In-Reply-To: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> References: <045.49f16aa27c3b3d99b33ed08a9782ab14@haskell.org> Message-ID: <060.34938cbeeeeeeb16a5e12ce596700691@haskell.org> #16001: hadrian doesn't support setting intree gmp configuration explicitly -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/138 -------------------------------------+------------------------------------- Changes (by alpmestan): * status: patch => closed * differential: Phab:D5417 => https://gitlab.haskell.org/ghc/ghc/merge_requests/138 * resolution: => fixed Comment: The patch got merged on gitlab: https://gitlab.haskell.org/ghc/ghc/merge_requests/138 Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 12:06:42 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 12:06:42 -0000 Subject: [GHC] #16176: Let-insertion for template haskell In-Reply-To: <049.678d9aad95242ee2e33cd275ecfba41c@haskell.org> References: <049.678d9aad95242ee2e33cd275ecfba41c@haskell.org> Message-ID: <064.bf1a5b077e45f0861ec990e3b969d154@haskell.org> #16176: Let-insertion for template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.3 Resolution: | Keywords: | TypedTemplateHaskell Operating System: 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): A paper about let insertion and how it works in MetaOcaml. https://www.cl.cam.ac.uk/~jdy22/papers/generating-mutually-recursive- definitions-short-paper.pdf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 13:37:02 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 13:37:02 -0000 Subject: [GHC] #16311: Suggest -XExistentialQuantification for 'forall' in data declarations In-Reply-To: <048.8e11135b0672563b5f793c5e90494439@haskell.org> References: <048.8e11135b0672563b5f793c5e90494439@haskell.org> Message-ID: <063.a70e2dd068c9e8ab7338bba135635f6b@haskell.org> #16311: Suggest -XExistentialQuantification for 'forall' in data declarations -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/rnfail053 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/363 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => rename/should_fail/rnfail053 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/887454d8889ca5dbba70425de41d97939cb9ac60 887454d8889ca5dbba70425de41d97939cb9ac60]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 14:12:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 14:12:41 -0000 Subject: [GHC] #16325: Hadrian should respect the build root setting for the testsuite and its own binaries Message-ID: <050.da86ece9240730c7fd61c1e01f766897@haskell.org> #16325: Hadrian should respect the build root setting for the testsuite and its own binaries -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the `--build-root` setting is respected only partially: * The `test` rule appears to be placing all testsuite build artefacts right in the GHC tree `./testsuite`. * Hadrian puts its own binaries also in the GHC tree, into the `./hadrian/X` directory, where `X` depends on whether we build with Cabal or Stack. We should improve on this and provide more guarantees about where all build artefacts go. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 14:20:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 14:20:41 -0000 Subject: [GHC] #16323: Cannot deduce X error with X provided in TypeFamilies In-Reply-To: <049.3fcc7dff885b59db8882798907b77f4c@haskell.org> References: <049.3fcc7dff885b59db8882798907b77f4c@haskell.org> Message-ID: <064.579330915b5d6ac2d710d1f22675be68@haskell.org> #16323: Cannot deduce X error with X provided in TypeFamilies -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: duplicate | Keywords: Deriving Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11008, #15868 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #11008, #15868 Comment: This is by design. Per the [https://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/glasgow_exts.html #inferred-context-for-deriving-clauses users' guide section] on `deriving`: > The Haskell Report is vague about exactly when a deriving clause is legal. For example: > > {{{#!hs > data T0 f a = MkT0 a deriving( Eq ) > data T1 f a = MkT1 (f a) deriving( Eq ) > data T2 f a = MkT2 (f (f a)) deriving( Eq ) > }}} > > The natural generated Eq code would result in these instance declarations: > > {{{#!hs > instance Eq a => Eq (T0 f a) where ... > instance Eq (f a) => Eq (T1 f a) where ... > instance Eq (f (f a)) => Eq (T2 f a) where ... > }}} > > The first of these is obviously fine. The second is still fine, although less obviously. The third is not Haskell 98, and risks losing termination of instances. > > GHC takes a conservative position: it accepts the first two, but not the third. The rule is this: each constraint in the inferred instance context must consist only of type variables, with no repetitions. > > This rule is applied regardless of flags. If you want a more exotic context, you can write it yourself, using the standalone deriving mechanism. A similar situation is happening in the code that you are trying to derive. For instance, this: {{{#!hs data RefMap a = RefMap (Map (Ref a) a) deriving Eq }}} Would require generating the following code: {{{#!hs instance (Eq a, Eq (Ref a)) => Eq (RefMap a) where ... }}} The constraint `Eq (Ref a)` has an occurrence of `Ref` underneath the class `Eq`, which isn't a type variable. Therefore, GHC conservatively backs out and refuses to infer it. In order to write this, GHC requires that you use `StandaloneDeriving`, like so: {{{#!hs deriving instance (Eq a, Eq (Ref a)) => Eq (RefMap a) }}} #11008 and #15868 are about this same issue, so I'll close this ticket as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 14:21:26 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 14:21:26 -0000 Subject: [GHC] #16319: unexpected difference between newtype and data In-Reply-To: <049.b77ffeefa62b8da598a1a219151c19c3@haskell.org> References: <049.b77ffeefa62b8da598a1a219151c19c3@haskell.org> Message-ID: <064.f9277e730ad552473a25061635711d09@haskell.org> #16319: unexpected difference between newtype and data ---------------------------------+---------------------------------------- Reporter: pjljvdlaar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: DatatypeContexts 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 RyanGlScott): * keywords: => DatatypeContexts -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 14:29:08 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 14:29:08 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.e95a15040bc667b558c5971fef2d75c2@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): In case it wasn't clear: Replying to [comment:1 RyanGlScott]: > We also bring the "existential" (provided) type variables into scope so that if we find any occurrences of them in the pattern synonym body, //we can throw the relevant `APromotionErr` error//. (emphasis added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 14:31:19 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 14:31:19 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.88d803835097ad1a9f0a0f64f1dfac37@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Comment: I'm afraid that I can't reproduce the issue. Can you post a minimal example (preferably with no external dependencies like `esqueleto`) that demonstrates the bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 14:38:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 14:38:23 -0000 Subject: [GHC] #16326: Implement visible dependent quantification Message-ID: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> #16326: Implement visible dependent quantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Keywords: GHCProposal | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15658 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC proposal 35 ([https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0035-forall-arrow.rst A syntax for visible dependent quantification]) has been accepted. This ticket tracks its implementation. Along with implementing it, we should also document it in the users' guide (the subject of #15658). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 15:20:25 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 15:20:25 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.dee2a7d50b9c157e50e83cbc1fcc1951@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. Now I understand what you're doing better. Here is how I see it: 1. The renamer really shouldn't bring any of the existentials into scope, as existentials in a pattern synonym type don't scope over the (entire) pattern synonym body. 2. But the renamer can't tell existential implicitly bound variables from universal ones. 3. So, the renamer brings into scope only the universals and all the implicitly bound ones. This brings more variables into scope than it should. 4. The pattern synonym body then is renamed with some extra variables in scope, so more uniques match between the body and the type than morally should. In addition, less implicit quantification happens in the body than morally should. 5. The type-checker must deal with this unfolding disaster by duplicating the renamer's strange behavior: it brings into scope implicitly-bound existentials, just so that weird out-of-scope errors don't happen in the body. But it arranges to error if these are encountered, regardless. 6. The program in this ticket observes that the difference in treatment between implicitly bound and explicitly bound is awkward. 7. Your proposed solution is just to bring all existentials into scope in both the renamer and the type-checker, so that treatment is uniform. This is done even though existentials really shouldn't scope over the body. 8. This ticket is all about uniformity. The behavior in both the explicit case and the implicit case is, by itself, correct. But it's awkward for GHC's behavior to depend on the user's choice of implicit vs explicit binding. Is that a fair assessment? If so, I advocate: do nothing. This problem goes away when type variables and kind variables are treated identically, because if the user writes a `forall`, they will have to bind the kind variables explicitly anyway. If the user does not write a `forall`, then no scoping of type variables happens, so there's no problem here. And, the patch as written actually makes GHC's behavior worse, in that it's further from the ideal of "existentials do not scope". The only reason to do this patch is that we cannot achieve the ideal, and this patch does indeed (and correctly, as far as I can tell) make the behavior more uniform. So I do think the best way to fix this problem is to ignore it and wait for it to go away. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 15:25:53 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 15:25:53 -0000 Subject: [GHC] #16326: Implement visible dependent quantification In-Reply-To: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> References: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> Message-ID: <065.dd17504ef00f75cfc4a8d7018ff19637@haskell.org> #16326: Implement visible dependent quantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15658 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What about GHC Proposal 81 [https://github.com/ghc-proposals/ghc- proposals/pull/81 Syntax for visible dependent quantification]. How do 35 and 81 relate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 15:26:38 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 15:26:38 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.e3718787286d0fd81d3077e6f544ecd7@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:5 goldfire]: > If so, I advocate: do nothing. This problem goes away when type variables and kind variables are treated identically, because if the user writes a `forall`, they will have to bind the kind variables explicitly anyway. If the user does not write a `forall`, then no scoping of type variables happens, so there's no problem here. You lost me here. The problem is that if you write out the kind variable in the original program explicitly: {{{#!hs pattern P :: forall. () => forall k (a :: k). Proxy a -> T pattern P x = MkT (x :: Proxy (a :: k)) }}} Then GHC //accepts// it, contrary to the claims of `Note [Pattern synonym existentials do not scope]`. So no, this problem won't go away when type and kind variables are treated identically. (In fact, int-index had to specifically mark this test case as `expect_broken` in his [https://gitlab.haskell.org/ghc/ghc/merge_requests/361 patch] to implement the type-kind-variable merger.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 15:29:04 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 15:29:04 -0000 Subject: [GHC] #16326: Implement visible dependent quantification In-Reply-To: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> References: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> Message-ID: <065.9efcfb077a222b340d0b4b3a9ab8173c@haskell.org> #16326: Implement visible dependent quantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15658 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Those are the exact same thing. The link you gave is the pull request that was later assigned the number 35 in `ghc-proposals`' indexing scheme when it was merged. (The number 81 just means that it was the 81st pull request that the repo had in its history.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 15:34:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 15:34:41 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.18aec5a671cf2b2b70afaa711ce55bab@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): You have a red herring in your soup. The following snippet is also accepted: {{{#!hs pattern P :: forall. () => forall k (a :: k). Proxy a -> T pattern P x = MkT (x :: Proxy (b :: j)) }}} There's no scoping going on here, just the fact that these type variables are unconstrained. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 15:43:29 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 15:43:29 -0000 Subject: [GHC] #16313: Core Lint warning (Unsafe coercion: {left, right}-hand type is levity-polymorphic) In-Reply-To: <050.474e30199f4ed213e19d2a554c242efb@haskell.org> References: <050.474e30199f4ed213e19d2a554c242efb@haskell.org> Message-ID: <065.5e156de586632b4cde20c94943aa691a@haskell.org> #16313: Core Lint warning (Unsafe coercion: {left,right}-hand type is levity- polymorphic) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes. Or at least such a warning is enabled by something other than `-dcore-lint`. Presumably, that unsafe coerce was written by the user. `-dcore-lint` should be used exclusively for finding GHC bugs. That is a user bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 15:44:07 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 15:44:07 -0000 Subject: [GHC] #16313: Core Lint warning (Unsafe coercion: {left, right}-hand type is levity-polymorphic) In-Reply-To: <050.474e30199f4ed213e19d2a554c242efb@haskell.org> References: <050.474e30199f4ed213e19d2a554c242efb@haskell.org> Message-ID: <065.692c16e9a1ada8e7190dc6460ede0cdb@haskell.org> #16313: Core Lint warning (Unsafe coercion: {left,right}-hand type is levity- polymorphic) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): > Precisely which checks are you advocating removing? The checks in #9122. As far as I can tell, they check only user-written programs, not GHC bugs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 15:47:20 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 15:47:20 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.6f0304868540006b6bc544f21ca82b29@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK. If I understand you correctly, then the original program with `k` uncommented should be accepted. (I think you were hinting at this all along, but it wasn't obvious to me until comment:7.) If that's the case, then it sounds like the proper course of action is to: * Proceed with https://gitlab.haskell.org/ghc/ghc/merge_requests/374, as it will get rid of the awkwardness brought about by implicitly quantified variables being brought into scope. * Moreover, !374 can revert most of #14998: * There is no longer any need for `PatSynExPE`, since implicitly quantified existentials are no longer brought into scope. * `Note [Pattern synonym existentials do not scope]` can go away. * The `T14498` test case can be removed. (Or, alternatively, we could explicitly quantify `k` and move it to `patsyn/should_compile`.) Does this sound right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 15:47:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 15:47:41 -0000 Subject: [GHC] #16313: Core Lint warning (Unsafe coercion: {left, right}-hand type is levity-polymorphic) In-Reply-To: <050.474e30199f4ed213e19d2a554c242efb@haskell.org> References: <050.474e30199f4ed213e19d2a554c242efb@haskell.org> Message-ID: <065.cf30818ff05e7c8f0429490d3f08c65d@haskell.org> #16313: Core Lint warning (Unsafe coercion: {left,right}-hand type is levity- polymorphic) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Let me ask again Are you really arguing that if Lint sees `3# |> UnsafeCoerce(..) :: Int`, which coerces an Int# to an Int, that it should remain silent? Maybe a compiler bug put it there; it's certainly wrong isn't it? After all, if the compiler was always right we would not need Core Lint. I'm all for adding a user-level bug-detection thing for `unsafeCoerce` as well, which you are perhaps implicitly suggesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 15:51:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 15:51:56 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.433e8f486e24fadd983206821c60cba5@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): > Does this sound right? Yes, precisely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 15:51:58 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 15:51:58 -0000 Subject: [GHC] #16208: map/coerce does not fire with all newtypes In-Reply-To: <047.6e6dd4b904ee0227174b737189ff29c7@haskell.org> References: <047.6e6dd4b904ee0227174b737189ff29c7@haskell.org> Message-ID: <062.7f52af944d3b6dfcb702376ef496b557@haskell.org> #16208: map/coerce does not fire with all newtypes -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/377 -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/377 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 16:42:14 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 16:42:14 -0000 Subject: [GHC] #16306: Hadrian: First test after a full rebuild normally fails due to an additional stdout line In-Reply-To: <049.3c4b1c797246bc27fd2a35aaddab357f@haskell.org> References: <049.3c4b1c797246bc27fd2a35aaddab357f@haskell.org> Message-ID: <064.3b8b85449c1fd245a6a0ee0a0f61e229@haskell.org> #16306: Hadrian: First test after a full rebuild normally fails due to an additional stdout line -------------------------------------+------------------------------------- Reporter: RolandSenn | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: snowleopard (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 16:46:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 16:46:56 -0000 Subject: [GHC] #16326: Implement visible dependent quantification In-Reply-To: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> References: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> Message-ID: <065.154eb41247c62d2b3d0da24b2df78a7f@haskell.org> #16326: Implement visible dependent quantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15658 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/378 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/378 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 16:48:49 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 16:48:49 -0000 Subject: [GHC] #15658: strange inferred kind with TypeInType In-Reply-To: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> References: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> Message-ID: <059.cd50c640f25059931b04bd7a99b3b300@haskell.org> #15658: strange inferred kind with TypeInType -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: TypeInType, | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16326 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/378 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/378 * related: => #16326 * milestone: 8.6.1 => 8.10.1 Comment: https://gitlab.haskell.org/ghc/ghc/merge_requests/378 implements the ability to write this in the source syntax (and documents it in the users' guide). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 18:02:28 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 18:02:28 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.d5008fbb9ca28a4b4bf8e2f0e6560a51@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by paf31): This loops in the REPL: {{{ :set -XDerivingStrategies :set -XFlexibleInstances :set -XFunctionalDependencies :set -XGeneralizedNewtypeDeriving :set -XMultiParamTypeClasses :set -XStandaloneDeriving :set -XUndecidableInstances import Data.Proxy class C a b | a -> b, b -> a where c :: Proxy a -> Int instance C Int Int where c _ = 1 newtype X a b = X { unX :: b } deriving newtype instance C a b => C (X String a) (X String b) }}} when I evaluate {{{ > c (Proxy :: Proxy (X String Int)) }}} Most likely `UndecidableInstances` is the culprit here, since I can't derive the instance otherwise, but it seems like it should be possible to derive anyway. `-ddump-deriv` shows this: {{{ Derived class instances: instance Ghci1.C a b => Ghci1.C (Ghci3.X GHC.Base.String a) (Ghci3.X GHC.Base.String b) where Ghci1.c = GHC.Prim.coerce @((Data.Proxy.Proxy (Ghci3.X GHC.Base.String a_a1Ei) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Int) @((Data.Proxy.Proxy (Ghci3.X GHC.Base.String a_a1Ei) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Int) Ghci1.c :: (Data.Proxy.Proxy (Ghci3.X GHC.Base.String a_a1Ei) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Int }}} which identifies the issue: GHC is not coercing away the newtype, but deriving an identity coercion. Apologies again if I'm missing something obvious here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 19:39:59 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 19:39:59 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.012195a3d8685492d30f5b83008b572d@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, I misinterpreted your comment—I thought that you were implying that the code was infinitely looping at compile-time, not runtime. My apologies. The code that `deriving newtype instance C a b => C (X String a) (X String b)` generates is expected behavior, as it turns out. From the [https://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/glasgow_exts.html #extension-StandaloneDeriving users' guide section] on `StandaloneDeriving`: > The stand-alone syntax is generalised for newtypes in exactly the same way that ordinary deriving clauses are generalised [...]. For example: > > {{{#!hs > newtype Foo a = MkFoo (State Int a) > > deriving instance MonadState Int Foo > }}} > > GHC always treats the //last// parameter of the instance (Foo in this example) as the type whose instance is being derived. In other words, the generated code will `coerce` underneath the last type argument, and nothing more. In your example, you have: {{{#!hs class C a b | a -> b, b -> a where c :: Proxy a -> Int newtype X a b = X b deriving newtype instance C a b => C (X String a) (X String b) }}} This will `coerce` from `X String b` to `b`, and nothing more. Because the type of `c` happens to never mention the last type parameter of `C`, this results in the "identity coercion" behavior you see with `-ddump-deriv`. It's a bit strange, but there's a certain consistency to it. After all, `deriving newtype instance C a b => C (X String a) (X String b)` could mean three different things: 1. Coerce underneath `X String a` only. 2. Coerce underneath `X String b` only. 3. Coerce underneath `X String a` and `X String b`. In general, if a multi-parameter type class has //n// type parameters, then there are 2^//n//^ - 1 different potential choices of code to generate. Since `deriving` clauses only `coerce` underneath the last type parameter, `StandaloneDeriving` picks the same convention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 19:44:49 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 19:44:49 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.17b457ba2c3c62618a5700bc5fef5e93@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by paf31): I understand that only the last argument is coerced, but even so, that would require an instance for `C (X String a) b`, which in this specific case instantiates to `C (X String Int) Int`, and the functional dependency should (I think) force this to fail via `X String Int ~ Int`. No? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 19:49:35 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 19:49:35 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.c462369fb782ec501e01392fd6449e94@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by paf31): To be clear, I now understand why this code should fail to compile, because the instance precondition should be `C (X String a) b`, and not `C a b`. But I still think it shouldn't loop at runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 20:05:52 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 20:05:52 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.5b05127cd658c3f7b35f870ded4884e2@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:5 paf31]: > I understand that only the last argument is coerced, but even so, that would require an instance for `C (X String a) b`, which in this specific case instantiates to `C (X String Int) Int`, and the functional dependency should (I think) force this to fail via `X String Int ~ Int`. No? If you had written `instance C (X String a) b => C (X String a) (X String b)`, then that would be the case. But you didn't—you specifically wrote `instance C a b => C (X String a) (X String b)`, which has no functional dependency issues. > But I still think it shouldn't loop at runtime. For the same reasons I explained in comment:4, the code that gets generated is `c = coerce c`, where the two occurrences of `c` have the same type, i.e., an infinite loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 20:40:37 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 20:40:37 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.3709a7d77402b84b1d498f86c997078d@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by paf31): I'll break down my understanding step-by-step based on what you've said above, and please let me know where I go wrong: 1. I require `C (X String a) (X String b)` given `C a b` 2. `deriving newtype` uses the newtype only in the last type argument, so GHC reduces this to looking for an instance of `C (X String a) b`. 3. The only instances that could ever possibly be applicable (even just based on the class) are `C Int Int`, `C a b` (in scope locally) and `C (X String a) (X String b)` itself (the recursive instance which is apparently chosen) but each leads to a contradiction (note that the functional dependency means I can infer the first type argument from the second): - `C Int Int` fails via `Int ~ X String a`. - `C a b` forces `X String a ~ a` - `C (X String a) (X String b)` forces `X String b ~ b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 20:54:40 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 20:54:40 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.d505e9334fe128eb4b62e21c200ddc60@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Step 2 isn't quite accurate. In general, saying "GHC reduces to looking for an instance of ..." is a decent intuition for how `GeneralizedNewtypeDeriving` works, but it breaks down in the particular case of `C`. Given the standalone `deriving` declaration you've written, GHC will first generate this code: {{{#!hs instance C a b => C (X String a) (X String b) where c :: Proxy (X String a) -> Int c = coerce @(Proxy (X String a) -> Int) @(Proxy (X String a) -> Int) c }}} At this point, GHC will typecheck this code. GHC has no issues with this code—the only class constraint that needs to be satisfies in order to typecheck is `C (X String a) (X String b)`, but since that's exactly the instance we're defining, this works. Moreover, that's why `c` loops at runtime, since we're recursively invoking `c` from the same instance without end. (Note that the `C a b =>` constraint is never really used at runtime—the only purpose it serves is to satisfy the functional dependency coverage condition.) All of this weirdness is ultimately due to the fact that the type of `c` never mentions `b` anywhere. If `c`'s type were `Proxy b -> Int`, then the generated code would instead be: {{{#!hs instance C a b => C (X String a) (X String b) where c :: Proxy (X String b) -> Int c = coerce @(Proxy b -> Int) @(Proxy (X String b) -> Int) c }}} In order to typecheck this, GHC would need actually need to satisfy a `C a b` constraint. In that scenario, it would be fair to summarize the whole thing as "reducing to looking for an instance of `C a b`". But in the program you've presented, you have an atypical corner case where the method's type does not mention the last type parameter of the class, so the usual intuition doesn't apply. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 21:06:17 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 21:06:17 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.f65adb6b7b83235cc3f0877c30326e64@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by paf31): I see, thank you. My understanding of `GeneralizedNewtypeDeriving` in the presence of MPTCs was faulty then. I'm a little surprised to hear this is the intended behavior, since I find it unintuitive that adding a new type class member could change the deriving behavior of existing member, but at least now I understand what's going on here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 21:09:04 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 21:09:04 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.32534f006c39b5e3d20210750af08a1d@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): If it makes you feel any better, the code you were trying to write will be rejected with an error message in GHC 8.8 due to a slight tweak in the code generation strategy for `GeneralizedNewtypeDeriving` (notice the extra visible type applications): {{{ λ> deriving instance C a b => C (X String a) (X String b) ==================== Derived instances ==================== Derived class instances: instance Ghci1.C a b => Ghci1.C (Ghci2.X GHC.Base.String a) (Ghci2.X GHC.Base.String b) where Ghci1.c = GHC.Prim.coerce @(Data.Proxy.Proxy (Ghci2.X GHC.Base.String a_a1I3) -> GHC.Types.Int) @(Data.Proxy.Proxy (Ghci2.X GHC.Base.String a_a1I3) -> GHC.Types.Int) (Ghci1.c @(Ghci2.X GHC.Base.String a_a1I3) @b_a1I4) :: Data.Proxy.Proxy (Ghci2.X GHC.Base.String a_a1I3) -> GHC.Types.Int Derived type family instances: :13:1: error: • Occurs check: cannot construct the infinite type: b ~ X String b arising from a functional dependency between constraints: ‘C a b’ arising from a use of ‘c’ at :13:1-54 ‘C a b1’ arising from the instance declaration at :13:1-54 • In the third argument of ‘GHC.Prim.coerce’, namely ‘(c @(X String a) @b)’ In the expression: GHC.Prim.coerce @(Proxy (X String a) -> Int) @(Proxy (X String a) -> Int) (c @(X String a) @b) :: Proxy (X String a) -> Int In an equation for ‘c’: c = GHC.Prim.coerce @(Proxy (X String a) -> Int) @(Proxy (X String a) -> Int) (c @(X String a) @b) :: Proxy (X String a) -> Int When typechecking the code for ‘c’ in a derived instance for ‘C (X String a) (X String b)’: To see the code I am typechecking, use -ddump-deriv :13:1: error: • Occurs check: cannot construct the infinite type: a ~ X String a arising from a functional dependency between constraints: ‘C (X String a) b1’ arising from a use of ‘c’ at :13:1-54 ‘C a b1’ arising from the instance declaration at :13:1-54 • In the third argument of ‘GHC.Prim.coerce’, namely ‘(c @(X String a) @b)’ In the expression: GHC.Prim.coerce @(Proxy (X String a) -> Int) @(Proxy (X String a) -> Int) (c @(X String a) @b) :: Proxy (X String a) -> Int In an equation for ‘c’: c = GHC.Prim.coerce @(Proxy (X String a) -> Int) @(Proxy (X String a) -> Int) (c @(X String a) @b) :: Proxy (X String a) -> Int When typechecking the code for ‘c’ in a derived instance for ‘C (X String a) (X String b)’: To see the code I am typechecking, use -ddump-deriv • Relevant bindings include c :: Proxy (X String a) -> Int (bound at :13:1) }}} ----- If this discussion answers your question, can this issue be closed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 21:09:37 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 21:09:37 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.9dd04f20d43342e7abffa789dc1d9fcc@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by paf31): Perfect! Yes, please do close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 21:15:11 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 21:15:11 -0000 Subject: [GHC] #16322: "deriving newtype instance" generates an infinite loop In-Reply-To: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> References: <044.d689e8013b958ee7e61870c64ce99509@haskell.org> Message-ID: <059.385b97b23cce0c5b3526c1237fc6db8f@haskell.org> #16322: "deriving newtype instance" generates an infinite loop -------------------------------------+------------------------------------- Reporter: paf31 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 21:20:18 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 21:20:18 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" In-Reply-To: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> References: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> Message-ID: <064.8bc70d1cc02701e1e889a895690cdada@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ---------------------------------+---------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.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 basvandijk): Corresponding [https://github.com/NixOS/nixpkgs/issues/55848 NixOS issue #55848]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 21:48:51 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 21:48:51 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" In-Reply-To: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> References: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> Message-ID: <064.b4675df843030ff1aec4639c289dafb0@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ---------------------------------+---------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.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 basvandijk): As I [https://github.com/NixOS/nixpkgs/issues/55848#issuecomment-464212640 just discovered], apparently my `libc++.a` in my Nix store contains the following: {{{ > cat /nix/store/jv40yw2ny28nnpbf860aaqq1dhga0f0r- libc++-5.0.2/lib/libc++.a INPUT(-lc++_static -lc++abi) }}} Note that the first 8 bytes of this file are `INPUT(-` which is exactly what GHC is panicking about. It seems that GHC is expecting `libc++.a` to be a binary archive while in fact it's some kind of textual reference to the real archive `libc++_static.a` which can be found in the same directory. Are these textual archive file a Nix-specific thing that GHC doesn't support? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 15 22:43:51 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Feb 2019 22:43:51 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" In-Reply-To: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> References: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> Message-ID: <064.617cf82fa879159717aee3b897a56fa1@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ---------------------------------+---------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.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 basvandijk): Ok so on Nix `libc++.a` is an [https://sourceware.org/binutils/docs/ld /Implicit-Linker-Scripts.html#Implicit-Linker-Scripts implicit linker script]: `INPUT(-lc++_static -lc++abi)`. Maybe we should give GHC support for linker scripts. Initially it could just support the [https://sourceware.org/binutils/docs/ld/File- Commands.html#File-Commands INPUT] command. This shouldn't be that hard. [https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/main/Ar.hs compiler/main/Ar.hs] needs to be adapted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 00:51:39 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 00:51:39 -0000 Subject: [GHC] #16327: NCG: Don't double adjust SP before calls on Windows. Message-ID: <047.cdf43920addce98c860f94fc7dbe5aca@haskell.org> #16327: NCG: Don't double adjust SP before calls on Windows. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Windows ABI requires callers to allocate 32 byte of space in the parameter stack space. This should be rolled into the stack adjustment for Currently we generate this code: {{{ subq $8,%rsp # for stack alignment? movq %r13,%rcx # Arg1 movq %rbx,%rdx # Arg2 subq $32,%rsp # Reserve "shadow" space + align stack if required xorl %eax,%eax # Not required for windows, even on linux only for vararg functions call newCAF addq $40,%rsp testq %rax,%rax je _c9N5 }}} Ideally this should become {{{ movq %r13,%rcx # Arg1 movq %rbx,%rdx # Arg2 subq $40,%rsp # Reserve "shadow" space xorl %eax,%eax call newCAF addq $40,%rsp testq %rax,%rax je _c9N5 }}} I haven't looked deeper into this and don't plan in the near future. But if anyone is interested I'm willing to lend a hand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 01:17:59 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 01:17:59 -0000 Subject: [GHC] #16328: NCG: Only adjust al before foreign calls if required. Message-ID: <047.65c72f841b00f56b2418e004472a8764@haskell.org> #16328: NCG: Only adjust al before foreign calls if required. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a typical sequence for a foreign call (although newCAF is a RTS function). We zero rax to indicate the number of vector registers used. However this is here (and usually) redundant. {{{ subq $8,%rsp movq %r13,%rax movq %rbx,%rsi movq %rax,%rdi xorl %eax,%eax call newCAF }}} The xor eax, eax here is redundant The System V spec says: > For calls that may call functions that use varargs or stdargs (prototype-less > calls or calls to functions containing ellipsis (...) in the declaration) %al is used > as hidden argument to specify the number of vector registers used. > The contents of %al do not need to match exactly the number of registers, but must be an upper bound on the number of vector registers used and is in the range 0–8 inclusive. This means we can omit the zeroing when we call things like RTS functions or memmov which take a fixed number of arguments at least. On windows this isn't part of the ABI at all so there we can just omit it completely. It's not a huge deal. For nofib/fannkuch-redux these xors are ~0,3% of the size of the .text segment. But it might help with cache in some edge cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 07:22:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 07:22:32 -0000 Subject: [GHC] #16329: Simplifier ticks exhausted when fusioning list literals Message-ID: <048.79eac52d9113bdb7b73038e1697ff24d@haskell.org> #16329: Simplifier ticks exhausted when fusioning list literals -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- GHC 8.6.3 cannot compile the following code with `-O`. {{{#!hs module Main10(func) where import Control.Monad import Data.IORef func :: Int -> IO Int func n = do ref <- newIORef False let xs = map (n+) [1,2,3,4,5,6,7,8,9,10] step acc x = do when (x `mod` 2 == 0) $ modifyIORef' ref not pure (acc + 1) foldM step 0 xs }}} {{{ $ stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.6.3 $ stack ghc -- -O Main10.hs [1 of 1] Compiling Main10 ( Main10.hs, Main10.o ) Simplifier ticks exhausted When trying RuleFired +# To increase the limit, use -fsimpl-tick-factor=N (default 100). If you need to increase the limit substantially, please file a bug report and indicate the factor you needed. If GHC was unable to complete compilation even with a very large factor (a thousand or more), please consult the "Known bugs or infelicities" section in the Users Guide before filing a report. There are a few situations unlikely to occur in practical programs for which simplifier non-termination has been judged acceptable. To see detailed counts use -ddump-simpl-stats Total ticks: 14321 }}} GHC 8.4.4 and 8.2.2 also fail to compile this but GHC 8.0.2 can. I tried `-fsimpl-tick-factor=10000`, then GHC could compile the program but quite slow (it took some minutes). I measured the total ticks in the dumps from `-ddump-simpl-stats`, while changing the length of the constant literal (`[1,2,...,10]`) in the program between 3 to 10. Here is the result. Simplifier ticks seems to be exponential in the length of the constant list. {{{ # length, Total ticks 3, 706 4, 1286 5, 2982 6, 8026 7, 23114 8, 68334 9, 203950 10,610754 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 10:41:39 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 10:41:39 -0000 Subject: [GHC] #16329: Simplifier ticks exhausted when fusioning list literals In-Reply-To: <048.79eac52d9113bdb7b73038e1697ff24d@haskell.org> References: <048.79eac52d9113bdb7b73038e1697ff24d@haskell.org> Message-ID: <063.153e2cb68782ec71710d2dcc62723d58@haskell.org> #16329: Simplifier ticks exhausted when fusioning list literals -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by autotaker): A simpler example is found. {{{#!hs module Main10S(func) where foldM :: (Monad m) => (b -> a -> m b) -> b -> [a] -> m b foldM f z0 xs = foldr (\x k z -> f z x >>= k) pure xs z0 func :: Int -> IO Int func n = foldM step 0 xs where xs = map (n+) [1,2,3,4,5,6,7,8,9,10] step acc x = case x `mod` 3 of 0 -> pure acc 1 -> pure $ acc + 1 2 -> pure $ acc + 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 11:56:29 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 11:56:29 -0000 Subject: [GHC] #16330: Type inference in presence of pattern matching on GADTs Message-ID: <045.a9dc981735183026a47b756bb7a7da0b@haskell.org> #16330: Type inference in presence of pattern matching on GADTs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.6.3 Keywords: GADTs | 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 small example {{{ {-# LANGUAGE GADTs #-} data G a where I :: G Integer f g = case g of I -> () }}} yields {{{ • Couldn't match expected type ‘p’ with actual type ‘()’ ‘p’ is untouchable inside the constraints: a ~ Integer bound by a pattern with constructor: I :: G Integer, in a case alternative at gadtsInference.hs:6:17 ‘p’ is a rigid type variable bound by the inferred type of f :: G a -> p at gadtsInference.hs:6:1-23 Possible fix: add a type signature for ‘f’ • In the expression: () In a case alternative: I -> () In the expression: case g of { I -> () } • Relevant bindings include f :: G a -> p (bound at gadtsInference.hs:6:1) | 6 | f g = case g of I -> () | ^^ }}} Without providing the type annotation for f `f :: G a -> ()` GHC cannot infer the correct result type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 12:25:00 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 12:25:00 -0000 Subject: [GHC] #16331: REGRESSION: --supported-languages lies about supported languages, again Message-ID: <042.409c6663f2535c65d9d4fe82ed573178@haskell.org> #16331: REGRESSION: --supported-languages lies about supported languages, again -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- To make it short, recent version of GHC broke the very thing we fixed in #11102 for GHC 8.0. This is utterly frustrating to me. ;-( Basically, if GHC advertises an extension, it's supposed to work without jumping through hoops if you enable it via `{-# LANGUAGE ... #-}` or `-X`-flags. Otherwise this breaks the whole idea of `other-extensions` and related cabal spec features which use `--supported-languages` to infer whether e.g. GHC when invoked with `-XTemplateHaskell` will succeed. However, consider the `Main.hs` below {{{#!hs {-# LANGUAGE TemplateHaskell #-} main = $undefined }}} Unfortuantely now GHC lies unconditionally about supporting TH, thereby undermining the infrastructure we setup in and for #11102: {{{ $ ghc --supported-languages | grep ^TemplateHaskell$ TemplateHaskell $ ghc --make Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) ghc-stage2: this operation requires -fexternal-interpreter }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 12:54:16 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 12:54:16 -0000 Subject: [GHC] #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances In-Reply-To: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> References: <051.87dec5efb3e2c1b1ed14134e69bce29b@haskell.org> Message-ID: <066.c21b433f7bd366820e757b0f1117c7a3@haskell.org> #16248: ImplicitParams does not imply FlexibleContexts or FlexibleInstances -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * status: new => closed * resolution: => fixed Comment: Fixed in https://gitlab.haskell.org/ghc/ghc/merge_requests/282/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 13:04:11 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 13:04:11 -0000 Subject: [GHC] #16329: Simplifier ticks exhausted when fusioning list literals In-Reply-To: <048.79eac52d9113bdb7b73038e1697ff24d@haskell.org> References: <048.79eac52d9113bdb7b73038e1697ff24d@haskell.org> Message-ID: <063.ae4230947d1a7e4f17140d7f59194f90@haskell.org> #16329: Simplifier ticks exhausted when fusioning list literals -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by autotaker): {{{#!hs func :: Int -> IO Int func n = foldM step 0 xs where xs = map (n+) [1,2,3] step acc x = case x `mod` 3 of 0 -> pure acc 1 -> pure $ acc + 1 2 -> pure $ acc + 2 }}} is simplified to the following core code {{{ func n = case n + 1 `mod` 3 of 0 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 0 1 -> pure 1 2 -> pure 2 1 -> case n + 3 `mod` 3 of 0 -> pure 1 1 -> pure 2 2 -> pure 3 2 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 1 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 1 1 -> pure 2 2 -> pure 3 1 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 2 -> case n + 3 `mod` 3 of 0 -> pure 3 1 -> pure 4 2 -> pure 5 2 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 1 -> case n + 3 `mod` 3 of 0 -> pure 3 1 -> pure 4 2 -> pure 5 2 -> case n + 3 `mod` 3 of 0 -> pure 4 1 -> pure 5 2 -> pure 6 }}} The size of this code is O(3^L^). On the other hand, a pure version of `func`, that is {{{#!hs func' n = foldl step 0 xs where xs = map (n+) [1,2,3] step acc x = case x `mod` 3 of 0 -> acc 1 -> acc + 1 2 -> acc + 2 }}} is simplified to the following core code {{{ func' n = join j2 w2 = join j1 w1 = case n + 3 `mod` 3 of 0 -> w1 1 -> w1 + 1 2 -> w1 + 2 in case n + 2 `mod` 3 of 0 -> jump j1 w2 1 -> jump j1 (w2 + 1) 2 -> jump j1 (w2 + 2) in case n + 1 `mod` 3 of 0 -> jump j2 0 1 -> jump j2 1 2 -> jump j2 2 }}} The size of this code is O(L). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 13:48:24 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 13:48:24 -0000 Subject: [GHC] #16329: Simplifier ticks exhausted when fusing list literals (was: Simplifier ticks exhausted when fusioning list literals) In-Reply-To: <048.79eac52d9113bdb7b73038e1697ff24d@haskell.org> References: <048.79eac52d9113bdb7b73038e1697ff24d@haskell.org> Message-ID: <063.b4495bb20cb548979d6b3c0a965c815c@haskell.org> #16329: Simplifier ticks exhausted when fusing list literals -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 17:10:27 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 17:10:27 -0000 Subject: [GHC] #16330: Type inference in presence of pattern matching on GADTs In-Reply-To: <045.a9dc981735183026a47b756bb7a7da0b@haskell.org> References: <045.a9dc981735183026a47b756bb7a7da0b@haskell.org> Message-ID: <060.ef6f1e500547630bed61f805bac974fd@haskell.org> #16330: Type inference in presence of pattern matching on GADTs -------------------------------------+------------------------------------- Reporter: v0d1ch | Owner: (none) Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 8.6.3 Resolution: invalid | Keywords: GADTs 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: This is expected behavior. Per the [https://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/glasgow_exts.html #extension-GADTs users' guide section on GADTs]: > The key point about GADTs is that pattern matching causes type refinement. For example, in the right hand side of the equation > > {{{#!hs > eval :: Term a -> a > eval (Lit i) = ... > }}} > > the type `a` is refined to `Int`. That’s the whole point! A precise specification of the type rules is beyond what this user manual aspires to, but the design closely follows that described in the paper [http://research.microsoft.com/%7Esimonpj/papers/gadt/ Simple unification- based type inference for GADTs], (ICFP 2006). The general principle is this: //type refinement is only carried out based on user-supplied type annotations//. So if no type signature is supplied for eval, no type refinement happens, and lots of obscure error messages will occur. Type inference in the presence of GADT pattern matching is extremely difficult in general (for reasons explained in further detail in the linked paper), and GHC deliberately requires that you supply a type signature to avoid these difficulties. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 17:55:05 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 17:55:05 -0000 Subject: [GHC] #14860: QuantifiedConstraints: Can't quantify constraint involving type family In-Reply-To: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> References: <050.75aef137861754a0f028d770bc4bb31e@haskell.org> Message-ID: <065.b8613ad245d66ddf77f2ccdba15be1a0@haskell.org> #14860: QuantifiedConstraints: Can't quantify constraint involving type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #16123 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Out of all the workarounds documented on this issue, I somehow overlooked the best one: Iceland_jack's solution in comment:16 involving `Dict`s. This offers a general blueprint to how to sneak type families into quantified constraints in the event that the trick in comment:1 doesn't work. In the particular example of comment:18, we wish to use `Show (T a b)` in the head of a quantified constraint. While this isn't directly possible, we can define a "class newtype" around `Show (T a b)` and use //that// in the head of a quantified constraint: {{{#!hs class Show (T a b) => ShowT a b instance Show (T a b) => ShowT a b class (forall b. Show b => ShowT a b) => C a where type family T a :: * -> * }}} If we try to define a `Show` instance for `D`, it first appears as though we are stuck: {{{#!hs data D a = MkD (T a Int) instance C a => Show (D a) where showsPrec p (MkD x) = showParen (p > 10) $ showString "MkD " . showsPrec 11 x }}} {{{ Bug.hs:35:48: error: • Could not deduce (Show (T a Int)) arising from a use of ‘showsPrec’ from the context: C a bound by the instance declaration at Bug.hs:33:10-26 • In the second argument of ‘(.)’, namely ‘showsPrec 11 x’ In the second argument of ‘($)’, namely ‘showString "MkD " . showsPrec 11 x’ In the expression: showParen (p > 10) $ showString "MkD " . showsPrec 11 x | 35 | = showParen (p > 10) $ showString "MkD " . showsPrec 11 x | ^^^^^^^^^^^^^^ }}} GHC appears to be unable to conclude `Show (T a Int)` from `ShowT a Int`. But we can help guide GHC along manually by taking advantage of the ever- helpful `Dict` data type: {{{ data Dict c = c => Dict showTDict :: forall a b. Dict (ShowT a b) -> Dict (Show (T a b)) showTDict Dict = Dict }}} Using `showTDict`, we can make our `Show` instance for `D` compile with a pinch of pattern guards: {{{#!hs instance C a => Show (D a) where showsPrec p (MkD x) | Dict <- showTDict @a @Int Dict = showParen (p > 10) $ showString "MkD " . showsPrec 11 x }}} That's it! With enough persistence, we were able to finally realize edsko's dream in comment:18. Having to explicitly match on `Dict`s is a bit crude, granted, but this appears to be the best that we can do here at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 16 20:00:28 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 16 Feb 2019 20:00:28 -0000 Subject: [GHC] #16243: Improve fregs-graph. In-Reply-To: <047.c51e05612d1f950acb9a8eb123109828@haskell.org> References: <047.c51e05612d1f950acb9a8eb123109828@haskell.org> Message-ID: <062.71316debd1abb5a39e450383535fab38@haskell.org> #16243: Improve fregs-graph. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Resolution: | Keywords: fregs-graph Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7679 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): == The case for live range splitting. I've looked a bit at loops recently. Below is a inner loop from nofib/fannkuch-redux. It's not some random code either. The loop makes up ~30% of the programs execution time First of the code we generate isn't great. We spill/reload variables across the call that are not used in the loop. Even so the final result is code that uses fewer vregs than we have registers available: {{{ #!C ca12: // global _s9D0::I64 = %MO_UU_Conv_W8_W64(I8[_s9zN::I64]); if (_s9D0::I64 != 0) goto ca1f; else goto ca1i; ca1f: // global I64[Sp - 16] = block_ca1d_info; R3 = _s9zN::I64 + _s9D0::I64; R2 = _s9zN::I64; I64[Sp - 8] = _s9CV::I64; I64[Sp] = _s9Cd::I64; I64[Sp + 40] = _s9Cc::I64; I64[Sp + 48] = _s9Cb::I64; I64[Sp + 56] = _s9zN::I64; Sp = Sp - 16; call $wflopp_r9x0_info(R3, R2) returns to ca1d, args: 8, res: 8, upd: 8; ca1d: // global _s9z5::I64 = I64[Sp + 24]; _s9zv::I64 = I64[Sp + 32]; _s9zx::I64 = I64[Sp + 40]; _s9zz::I64 = I64[Sp + 48]; _s9zN::I64 = I64[Sp + 72]; _s9Cb::I64 = I64[Sp + 64]; _s9Cc::I64 = I64[Sp + 56]; _s9Cd::I64 = I64[Sp + 16]; _s9CV::I64 = I64[Sp + 8] + 1; Sp = Sp + 16; goto ca12; }}} We get this liveness: {{{ #!asm ca12: movzbl (%vI_s9zN),%vI_s9D0 # born: %vI_s9D0 testq %vI_s9D0,%vI_s9D0 jne _ca1f # r_dying: %vI_s9D0 jmp _ca1i # r_dying: %vI_s9z5 %vI_s9zv %vI_s9zx %vI_s9zz %vI_s9zN %vI_s9Cb %vI_s9Cc %vI_s9Cd %vI_s9CV NONREC ca1f: movq $block_ca1d_info,-16(%rbp) movq %vI_s9zN,%rsi # born: %r4 addq %vI_s9D0,%rsi # r_dying: %vI_s9D0 movq %vI_s9zN,%r14 # born: %r14 movq %vI_s9CV,-8(%rbp) # r_dying: %vI_s9CV movq %vI_s9Cd,(%rbp) # r_dying: %vI_s9Cd movq %vI_s9Cc,40(%rbp) # r_dying: %vI_s9Cc movq %vI_s9Cb,48(%rbp) # r_dying: %vI_s9Cb movq %vI_s9zN,56(%rbp) # r_dying: %vI_s9zN addq $-16,%rbp jmp $wflopp_r9x0_info # r_dying: %r4 %r14 NONREC ca1d: movq 24(%rbp),%vI_s9z5 # born: %vI_s9z5 movq 32(%rbp),%vI_s9zv # born: %vI_s9zv movq 40(%rbp),%vI_s9zx # born: %vI_s9zx movq 48(%rbp),%vI_s9zz # born: %vI_s9zz movq 72(%rbp),%vI_s9zN # born: %vI_s9zN movq 64(%rbp),%vI_s9Cb # born: %vI_s9Cb movq 56(%rbp),%vI_s9Cc # born: %vI_s9Cc movq 16(%rbp),%vI_s9Cd # born: %vI_s9Cd movq 8(%rbp),%vI_nakO # born: %vI_nakO leaq 1(%vI_nakO),%vI_s9CV # born: %vI_s9CV # r_dying: %vI_nakO addq $16,%rbp jmp _ca12 # r_dying: %vI_s9z5 %vI_s9zv %vI_s9zx %vI_s9zz %vI_s9zN %vI_s9Cb %vI_s9Cc %vI_s9Cd %vI_s9CV }}} However the graph register spills many of these: * vI_s9zN - 5 uses * vI_s9Cd - 2 uses * and a few more but the details don't matter that much. With live range splitting ideally we just split ranges overlapping the loop into three ranges, so the ranges overlapping the loop could be spilled/loaded on loop entry/exit not affecting the performance of the loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 17 02:52:17 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Feb 2019 02:52:17 -0000 Subject: [GHC] #16332: Feature request: Data.Foldable.asumMap Message-ID: <051.e5202b24986e521207d96a8564ec30c8@haskell.org> #16332: Feature request: Data.Foldable.asumMap -------------------------------------+------------------------------------- Reporter: josephcsible | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 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: -------------------------------------+------------------------------------- I'd like to request that an `asumMap` function be added to `Data.Foldable`, which would be a generalization of `concatMap` in the same way that `asum` is a generalization of `concat`. Its proposed definition: {{{#!hs asumMap :: (Foldable t, Alternative f) => (a -> f b) -> t a -> f b asumMap f = foldr ((<|>) . f) empty }}} This is almost equivalent to a combination of "asum" and "fmap", but it doesn't require a "Functor t" constraint like that does. Notes on its usefulness: * Here's a Stack Overflow question that asks for a function ((a -> Maybe b) -> [a] -> Maybe b) that this is a more general form of: https://stackoverflow.com/questions/19643664/standard-haskell- function-a-maybe-b-a-maybe-b * The alternative prelude Relude includes this function (although theirs is implemented in terms of foldMap and Alt instead of foldr and <|>): https://hackage.haskell.org/package/relude-0.4.0/docs/Relude-Foldable- Fold.html#v:asumMap * This can also be thought of as a more useful version of `Data.Foldable.find`. For example, if you have a sum type such as `Either` and want to find the value in first one of it that's `Right`, you could do `asumMap rightToMaybe x`. If you were to instead do `find isRight x`, the `Either` won't be unwrapped even though you know it's `Right`, so you'll then have to do something unclean (like a partial function) to get the value out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 17 02:54:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Feb 2019 02:54:32 -0000 Subject: [GHC] #16332: Feature request: Data.Foldable.asumMap In-Reply-To: <051.e5202b24986e521207d96a8564ec30c8@haskell.org> References: <051.e5202b24986e521207d96a8564ec30c8@haskell.org> Message-ID: <066.3ba33137c9e87c58fea51832113353ae@haskell.org> #16332: Feature request: Data.Foldable.asumMap -------------------------------------+------------------------------------- Reporter: josephcsible | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by josephcsible: Old description: > I'd like to request that an `asumMap` function be added to > `Data.Foldable`, which would be a generalization of `concatMap` in the > same way that `asum` is a generalization of `concat`. Its proposed > definition: > > {{{#!hs > asumMap :: (Foldable t, Alternative f) => (a -> f b) -> t a -> f b > asumMap f = foldr ((<|>) . f) empty > }}} > > This is almost equivalent to a combination of "asum" and "fmap", but it > doesn't require a "Functor t" constraint like that does. > > Notes on its usefulness: > * Here's a Stack Overflow question that asks for a function ((a -> Maybe > b) -> [a] -> Maybe b) that this is a more general form of: > https://stackoverflow.com/questions/19643664/standard-haskell- > function-a-maybe-b-a-maybe-b > * The alternative prelude Relude includes this function (although theirs > is implemented in terms of foldMap and Alt instead of foldr and <|>): > https://hackage.haskell.org/package/relude-0.4.0/docs/Relude-Foldable- > Fold.html#v:asumMap > * This can also be thought of as a more useful version of > `Data.Foldable.find`. For example, if you have a sum type such as > `Either` and want to find the value in first one of it that's `Right`, > you could do `asumMap rightToMaybe x`. If you were to instead do `find > isRight x`, the `Either` won't be unwrapped even though you know it's > `Right`, so you'll then have to do something unclean (like a partial > function) to get the value out. New description: I'd like to request that an `asumMap` function be added to `Data.Foldable`, which would be a generalization of `concatMap` in the same way that `asum` is a generalization of `concat`. Its proposed definition: {{{#!hs asumMap :: (Foldable t, Alternative f) => (a -> f b) -> t a -> f b asumMap f = foldr ((<|>) . f) empty }}} This is almost equivalent to a combination of `asum` and `fmap`, but it doesn't require a `Functor t` constraint like that does. Notes on its usefulness: * Here's a Stack Overflow question that asks for a function (`(a -> Maybe b) -> [a] -> Maybe b`) that this is a more general form of: https://stackoverflow.com/questions/19643664/standard-haskell- function-a-maybe-b-a-maybe-b * The alternative prelude Relude includes this function (although theirs is implemented in terms of `foldMap` and `Alt` instead of `foldr` and `<|>`): https://hackage.haskell.org/package/relude-0.4.0/docs/Relude- Foldable-Fold.html#v:asumMap * This can also be thought of as a more useful version of `Data.Foldable.find`. For example, if you have a sum type such as `Either` and want to find the value in first one of it that's `Right`, you could do `asumMap rightToMaybe x`. If you were to instead do `find isRight x`, the `Either` won't be unwrapped even though you know it's `Right`, so you'll then have to do something unclean (like a partial function) to get the value out. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 17 10:02:28 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Feb 2019 10:02:28 -0000 Subject: [GHC] #16333: Implement Loop-invariant code motion / Hoisting for Cmm Message-ID: <047.dcae1d82ab8c7a5cf4205a9455a0564b@haskell.org> #16333: Implement Loop-invariant code motion / Hoisting for Cmm -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12808 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently we don't but we should. An example from nofib: This is the innermost loop of fannkuch-redux. {{{ #!C ca12: _s9D0::I64 = %MO_UU_Conv_W8_W64(I8[_s9zN::I64]); if (_s9D0::I64 != 0) goto ca1f; else goto ca1i; ca1f: I64[Sp - 16] = ca1d; R3 = _s9zN::I64 + _s9D0::I64; R2 = _s9zN::I64; I64[Sp - 8] = _s9CV::I64; I64[Sp] = _s9Cd::I64; I64[Sp + 40] = _s9Cc::I64; I64[Sp + 48] = _s9Cb::I64; I64[Sp + 56] = _s9zN::I64; Sp = Sp - 16; call $wflopp_r9x0_info(R3, R2) returns to ca1d, args: 8, res: 8, upd: 8; ca1d: Sp = Sp + 16; _s9CV::I64 = I64[Sp - 8] + 1; _s9Cd::I64 = I64[Sp + 0]; 16 _s9z5::I64 = I64[Sp + 8]; //24 _s9zv::I64 = I64[Sp + 16]; 32 _s9zx::I64 = I64[Sp + 24]; 40 _s9zz::I64 = I64[Sp + 32]; 48 _s9Cc::I64 = I64[Sp + 40]; 56 _s9Cb::I64 = I64[Sp + 48]; 64 _s9zN::I64 = I64[Sp + 56]; 72 goto ca12; }}} We should try to move the loads NOT used in the loop out of the loop at least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 17 14:26:14 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Feb 2019 14:26:14 -0000 Subject: [GHC] #16334: Named wildcards in kinds Message-ID: <048.1c12b4f97b648562a3f1fdca2d35171a@haskell.org> #16334: Named wildcards in kinds -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 (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: -------------------------------------+------------------------------------- This works: {{{ Prelude> :set -XNamedWildCards -XPartialTypeSignatures -XPolyKinds Prelude> k :: (Int :: _); k = 42 :2:14: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘*’ • In the type signature: k :: (Int :: _) }}} And this doesn't: {{{ Prelude> k :: (Int :: _t); k = 42 :3:7: error: • Expected kind ‘_t’, but ‘Int’ has kind ‘*’ • In the type signature: k :: (Int :: _t) }}} The issue, I suspect, is in `partition_nwcs`, which ignores kind variables for some reason. I plan to fix it as part of https://gitlab.haskell.org/ghc/ghc/merge_requests/361 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 17 20:02:05 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Feb 2019 20:02:05 -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.826aa0893594f8a7540915d5b49b8866@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: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): See also https://github.com/haskell/cabal/issues/5893 which hits the same issue and makes GHC itself compile slowly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 17 20:51:03 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 17 Feb 2019 20:51:03 -0000 Subject: [GHC] #14533: Make GHC more robust against PC crashes by using atomic writes In-Reply-To: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> References: <042.6f078c53750e85c0c893c4f87dfef677@haskell.org> Message-ID: <057.d0ed8c83725b233d11ac45a4084409b0@haskell.org> #14533: Make GHC more robust against PC crashes by using atomic writes -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14788 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): I've started a new initiative to rid the Haskell build ecosystem of persistent build errors due to truncated files: https://github.com/commercialhaskell/stack/issues/4559 ---- First PR for this in: https://gitlab.haskell.org/ghc/ghc/merge_requests/391 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 00:11:54 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 00:11:54 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" In-Reply-To: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> References: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> Message-ID: <064.6a478a5d20cdfb500daaec698bbcd9bc@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ---------------------------------+---------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.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 basvandijk): Here's some work-in-progress on this: https://github.com/basvandijk/ghc/commit/79f71de60f3eda37f552bfcb98a440da69c32326 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 02:19:55 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 02:19:55 -0000 Subject: [GHC] #16233: HIE file generation is inefficient In-Reply-To: <050.9a8af98be708c8bc79f0ecd2c361995e@haskell.org> References: <050.9a8af98be708c8bc79f0ecd2c361995e@haskell.org> Message-ID: <065.d74907bcc56b9b5a111ee641f427ee06@haskell.org> #16233: HIE file generation is inefficient -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15320 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Since 5ed48d25decc9dec29659482644b136cff91606e, we avoid most of the expensive calls to `deSugarExpr`. For a handful of expressions (ex: `HsLam`), the type already exists in the extensions field, so we use that. For some other expressions that are prone to the quartic desugaring performance (eg. `HsApp`), we've just disabled getting their type information completely for now. The rest (ex. `HsVar`), we still perform the desugaring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 02:26:38 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 02:26:38 -0000 Subject: [GHC] #16206: Run Haddock's test suite in CI In-Reply-To: <046.45e8b6d65ce692f099b4b1d0d1ad5d4b@haskell.org> References: <046.45e8b6d65ce692f099b4b1d0d1ad5d4b@haskell.org> Message-ID: <061.59f38340f0b2713d5ded8baa4a7c5e7e@haskell.org> #16206: Run Haddock's test suite in CI -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/291 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: patch => closed * resolution: => fixed Comment: Fixed in 4a09d30bffa0c9df10ab5e7d22293c1f39c75728. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 05:10:44 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 05:10:44 -0000 Subject: [GHC] #12218: Implement -fexternal-interpreter via static linking In-Reply-To: <047.d2ead1284e240e7bcc878975afeb5ae1@haskell.org> References: <047.d2ead1284e240e7bcc878975afeb5ae1@haskell.org> Message-ID: <062.2b2e048e0ca96cf8983d6d139139a9db@haskell.org> #12218: Implement -fexternal-interpreter via static linking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 06:01:10 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 06:01:10 -0000 Subject: [GHC] #12612: Allow kinds of associated types to depend on earlier associated types In-Reply-To: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> References: <051.03b4bda1b1ebc27d0a28baf47d735e88@haskell.org> Message-ID: <066.0b7f36d6bdabf214ebc0ab56f0da47e3@haskell.org> #12612: Allow kinds of associated types to depend on earlier associated types -------------------------------------+------------------------------------- Reporter: davemenendez | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11962, #15942 | 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 Mon Feb 18 06:17:25 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 06:17:25 -0000 Subject: [GHC] #16314: Improve confusing error message with MINIMAL pragma In-Reply-To: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> References: <045.58cd4fedc5dd772b442f093f40b1bb38@haskell.org> Message-ID: <060.cea38374f9966ab28db6e99fc4c0c924@haskell.org> #16314: Improve confusing error message with MINIMAL pragma -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lerkok): Proposal submitted at: https://github.com/ghc-proposals/ghc- proposals/pull/210 Feedback most welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 08:20:23 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 08:20:23 -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.74f92afcc183ae7c9d580e33a8dc3f59@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, Deriving 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 simonpj): * keywords: deriving-perf, Generics => deriving-perf, Generics, Deriving Comment: Ben, when we emerge from the CI swamp, this ticket looks like one of several GHC-perf tickets that deserve renewed attention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 08:23:23 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 08:23:23 -0000 Subject: [GHC] #16334: Named wildcards in kinds In-Reply-To: <048.1c12b4f97b648562a3f1fdca2d35171a@haskell.org> References: <048.1c12b4f97b648562a3f1fdca2d35171a@haskell.org> Message-ID: <063.5d9928907173413759e712caabe4e45e@haskell.org> #16334: Named wildcards in kinds -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.4.4 checker) | Keywords: Resolution: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PartialTypeSignatures -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 08:31:03 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 08:31:03 -0000 Subject: [GHC] #16333: Implement Loop-invariant code motion / Hoisting for Cmm In-Reply-To: <047.dcae1d82ab8c7a5cf4205a9455a0564b@haskell.org> References: <047.dcae1d82ab8c7a5cf4205a9455a0564b@haskell.org> Message-ID: <062.3018c5383cb76cabeaae715146f236ca@haskell.org> #16333: Implement Loop-invariant code motion / Hoisting for Cmm -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12808 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 08:33:22 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 08:33:22 -0000 Subject: [GHC] #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm In-Reply-To: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> References: <050.9ed7551800b5fadcbeedeacbf684b884@haskell.org> Message-ID: <065.4c1735503898b53bd4f2423400c9a253@haskell.org> #16111: Inconsistent behavior of Data.Bits.shiftL with different optimization levels and -fllvm -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: harpocrates Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/113 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => harpocrates -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 09:14:30 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 09:14:30 -0000 Subject: [GHC] #16243: Improve fregs-graph. In-Reply-To: <047.c51e05612d1f950acb9a8eb123109828@haskell.org> References: <047.c51e05612d1f950acb9a8eb123109828@haskell.org> Message-ID: <062.b954142ad79656778ad903b539f66534@haskell.org> #16243: Improve fregs-graph. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Keywords: fregs-graph, Resolution: | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7679 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: fregs-graph => fregs-graph, CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 11:02:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 11:02:00 -0000 Subject: [GHC] #16312: Optimization + adding an INLINE pragma triggers Core Lint error (Type of case alternatives not the same as the annotation on case) In-Reply-To: <050.2616a09c9703c7abb703460264929e5d@haskell.org> References: <050.2616a09c9703c7abb703460264929e5d@haskell.org> Message-ID: <065.c631bc5a9633fa79172ed32537f476b3@haskell.org> #16312: Optimization + adding an INLINE pragma triggers Core Lint error (Type of case alternatives not the same as the annotation on case) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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 simonpj): Definite bug here! I investigated a bit. Here's a simpler example that crashes in the same way. {{{ {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes, KindSignatures #-} module Bug where import GHC.Base data Curried (g :: * -> *) (h :: * -> *) a instance Functor (Curried g h) where fmap = error "urk2" instance (g ~ h) => Applicative (Curried g h) where pure = error "urk" liftA2 = error "urk" (<*) = error "urk" (*>) = error "urk" (<*>) = grstargr wib :: (g ~ h) => Curried g h (b->b) -> Curried g h b -> Curried g h b wib a1 a2 = a1 <*> a2 grstargr :: Curried g h (a->b) -> Curried g h a -> Curried g h b {-# NOINLINE grstargr #-} grstargr = error "urk" }}} I'm pretty sure that the wrong-ness is that the result type attached to a `Case` in Core is getting out of date. I don't yet know how though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 11:16:08 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 11:16:08 -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.73d322585ece5eae3890a98d122c56e7@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: partial- crash or panic | sigs/should_fail/T14040a Blocked By: | Blocking: Related Tickets: #13877, #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The original program now reports just one error {{{ T14040.hs:41:8: error: • Cannot apply expression of type ‘Sing wl0 -> (forall y. p0 _0 'WeirdNil) -> (forall z1 (x :: z1) (xs :: WeirdList (WeirdList z1)). Sing x -> Sing xs -> p0 _1 xs -> p0 _2 ('WeirdCons x xs)) -> p0 _3 wl0’ to a visible type argument ‘(WeirdList z)’ }}} And that's right: the signature for `elimWierdList` is a partial signature, so we do ''inference'' on the definition. So at the recursive call to `elimWierdList`, the function is a monotype, and can't be applied to type arguments. However, for the `elimWierdList x = error "urk"` version I get {{{ WARNING: file compiler/types/TyCoRep.hs, line 3033 in_scope InScope {a_a10j wl_a10k p_a10l} tenv [aX1 :-> a_a10j[tyv:1], aX2 :-> wl_a10k[tyv:1], aX4 :-> p_a10l[tyv:1]] cenv [] tys [Sing wl_aX2[tyv:1] -> (forall y. p_aX4[tyv:1] __aZo[tau:2] 'WeirdNil) -> (forall z (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p_aX4[tyv:1] __aZL[tau:2] xs -> p_aX4[tyv:1] __aZP[tau:2] ('WeirdCons x xs)) -> p_aX4[tyv:1] __aZW[tau:1] wl_aX2[tyv:1]] cos [] needInScope {z_aX6[sk:2], x_aZm[tau:2], __aZo[tau:2], __aZL[tau:2], __aZP[tau:2], __aZW[tau:1]} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1211:29 in ghc:Outputable warnPprTrace, called at compiler/types/TyCoRep.hs:3027:6 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:3050:29 in ghc:TyCoRep substTy, called at compiler/typecheck/TcSigs.hs:507:49 in ghc:TcSigs ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20190215 for x86_64-unknown-linux): ASSERT failed! 2 0 __a23h[tau:0] Any Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1220:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcMType.hs:805:54 in ghc:TcMType Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug }}} So there is still stuff wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 12:21:04 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 12:21:04 -0000 Subject: [GHC] #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> References: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> Message-ID: <062.e594b5d14df7978db314c89176e143ce@haskell.org> #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Simplifier Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: 15840 Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/325 -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Simplifier Comment: I'm ok with the patch for now, but I'd like to keep this ticket open because I think a Better Solution is really to make the occurrence analyser perform the substitution instead of creating a 'let'. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 12:22:29 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 12:22:29 -0000 Subject: [GHC] #16296: OccurAnal should not break the linter assumptions In-Reply-To: <047.644681ea1af3bb09669b9aa1303ac010@haskell.org> References: <047.644681ea1af3bb09669b9aa1303ac010@haskell.org> Message-ID: <062.2c9ad838ff59f60bb5b974c283648b47@haskell.org> #16296: OccurAnal should not break the linter assumptions -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Simplifier 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: => Simplifier -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 14:53:03 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 14:53:03 -0000 Subject: [GHC] #16168: Prelude docs for Integer mention J# In-Reply-To: <046.910a4bfcf428436f923f4f369d2e5583@haskell.org> References: <046.910a4bfcf428436f923f4f369d2e5583@haskell.org> Message-ID: <061.7592225f46a619ad290856dbfe89e755@haskell.org> #16168: Prelude docs for Integer mention J# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: Component: Core Libraries | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/308 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/308 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 16:28:11 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 16:28:11 -0000 Subject: [GHC] #13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules In-Reply-To: <049.ea180dc159da65b4270e906a17cf9067@haskell.org> References: <049.ea180dc159da65b4270e906a17cf9067@haskell.org> Message-ID: <064.6bbf59ba042bbf654da93b511c7842aa@haskell.org> #13706: ghci messages like "Ok, modules loaded: ..." are impractical for large sets of modules -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => closed * resolution: => fixed Comment: This ticket was fixed with Phab:D3651. Then #14427 (Phab:D4164) introduced a new flag `-fshow-loaded-modules` which allows to get back the previous behaviour -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 16:37:35 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 16:37:35 -0000 Subject: [GHC] #16334: Named wildcards in kinds In-Reply-To: <048.1c12b4f97b648562a3f1fdca2d35171a@haskell.org> References: <048.1c12b4f97b648562a3f1fdca2d35171a@haskell.org> Message-ID: <063.31a8f620d2dff559352921af62fbca2e@haskell.org> #16334: Named wildcards in kinds -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.4.4 checker) | Keywords: Resolution: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/361 -------------------------------------+------------------------------------- Changes (by int-index): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/361 Old description: > This works: > > {{{ > Prelude> :set -XNamedWildCards -XPartialTypeSignatures -XPolyKinds > Prelude> k :: (Int :: _); k = 42 > > :2:14: warning: [-Wpartial-type-signatures] > • Found type wildcard ‘_’ standing for ‘*’ > • In the type signature: k :: (Int :: _) > }}} > > And this doesn't: > > {{{ > Prelude> k :: (Int :: _t); k = 42 > > :3:7: error: > • Expected kind ‘_t’, but ‘Int’ has kind ‘*’ > • In the type signature: k :: (Int :: _t) > }}} > > The issue, I suspect, is in `partition_nwcs`, which ignores kind > variables for some reason. I plan to fix it as part of > https://gitlab.haskell.org/ghc/ghc/merge_requests/361 New description: This works: {{{ Prelude> :set -XNamedWildCards -XPartialTypeSignatures -XPolyKinds Prelude> k :: (Int :: _); k = 42 :2:14: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘*’ • In the type signature: k :: (Int :: _) }}} And this doesn't: {{{ Prelude> k :: (Int :: _t); k = 42 :3:7: error: • Expected kind ‘_t’, but ‘Int’ has kind ‘*’ • In the type signature: k :: (Int :: _t) }}} The issue, I suspect, is in `partition_nwcs`, which ignores kind variables for some reason. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 16:47:45 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 16:47:45 -0000 Subject: [GHC] #16335: Make CPR Analysis more aggressive for inductive cases Message-ID: <044.4dff670ac464d2846cf2d5d1f6d68e05@haskell.org> #16335: Make CPR Analysis more aggressive for inductive cases -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Keywords: CPRAnalysis | 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 investigating the generated Core for a simple toy benchmark, I came up with the following minimal example: {{{#!hs data Expr = Lit Int | Plus Expr Expr eval :: Expr -> Int eval (Lit n) = n eval (Plus a b) = eval a + eval b }}} resulting in the following Core: {{{ eval = \ (ds_d112 :: Expr) -> case ds_d112 of { Lit n_aXf -> n_aXf; Plus a_aXg b_aXh -> case eval a_aXg of { GHC.Types.I# x_a1bK -> case eval b_aXh of { GHC.Types.I# y_a1bO -> GHC.Types.I# (GHC.Prim.+# x_a1bK y_a1bO) } } } }}} Note that this needlessly unboxes and boxes primitive Ints. Lifting this is precisely the job of CPR, but `eval` doesn't exactly have the CPR property: the `Lit` case doesn't return a product. But we're punishing ourselves for the base case when ''even the function itself'' recurses multiple times! The code resulting from WWing here wouldn't even look bad in the `Lit` case: {{{ Foo.$weval = \ (w_s1cn :: Expr) -> case w_s1cn of { Lit dt_d11b -> case dt_d11b { I# ds_abcd -> ds_abcd }; Plus a_aXf b_aXg -> case Foo.$weval a_aXf of ww_s1cq { __DEFAULT -> case Foo.$weval b_aXg of ww1_X1dh { __DEFAULT -> GHC.Prim.+# ww_s1cq ww1_X1dh } } } eval = \ (w_s1cn :: Expr) -> case Foo.$weval w_s1cn of ww_s1cq { __DEFAULT -> GHC.Types.I# ww_s1cq } }}} Granted, this is bad for the case where there is no recursion happening and we need the result of `eval` boxed, but that's a small price to pay IMO. I begin to think of CPR more of as the "dual" to SpecConstr than to Strictness Analysis. Return pattern specialisation, so to speak. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 17:04:42 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 17:04:42 -0000 Subject: [GHC] #16335: Make CPR Analysis more aggressive for inductive cases In-Reply-To: <044.4dff670ac464d2846cf2d5d1f6d68e05@haskell.org> References: <044.4dff670ac464d2846cf2d5d1f6d68e05@haskell.org> Message-ID: <059.b9abc7baa40b9ebfc7f7b06c5b6b9a7b@haskell.org> #16335: Make CPR Analysis more aggressive for inductive cases -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Resolution: | Keywords: CPRAnalysis Operating System: 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): Nicely characterised. CPR (to one level) is always sound; it may just do some unnecessary reboxing. So we could just try saying that a function has the CPR property if ''any'' of its case branches do, rather than (as now) if 'all' do. That would, I assume, be a rather easy experiment to try. (It'd be lovely to know what are the hot branches!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 17:14:11 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 17:14:11 -0000 Subject: [GHC] #16335: Make CPR Analysis more aggressive for inductive cases In-Reply-To: <044.4dff670ac464d2846cf2d5d1f6d68e05@haskell.org> References: <044.4dff670ac464d2846cf2d5d1f6d68e05@haskell.org> Message-ID: <059.76517b06b5b3427d9aa3dfb65eaf488d@haskell.org> #16335: Make CPR Analysis more aggressive for inductive cases -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.6.3 Resolution: | Keywords: CPRAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): To expand on the "Return pattern specialisation" thing: ||=SpecConstr=||= CPR+WW =|| ||Multiple specialisations||One specialisation|| ||Looks at how much the definition scrutinises its arguments in ''any'' of its case expressions||Looks at how deep the constructed products are in ''all'' its return branches (mostly since we only do one specialisation)|| ||Compares that to how the function is called and only allows matching specialisations (unless `-fspec-constr-keen`||Doesn't look at calls, but only provides the most conservative specialisation anyway|| Put another way: If we allowed multiple specialisations, we could have the following two specialisations, no reboxing happening (no promises made on correctness): {{{ Foo.$weval = \ (w_s1cn :: Expr) -> case w_s1cn of { Lit dt_d11b -> case dt_d11b { I# ds_abcd -> ds_abcd }; Plus a_aXf b_aXg -> case Foo.$weval a_aXf of ww_s1cq { __DEFAULT -> case Foo.$weval b_aXg of ww1_X1dh { __DEFAULT -> GHC.Prim.+# ww_s1cq ww1_X1dh } } } eval = \ (ds_d112 :: Expr) -> case ds_d112 of { Lit n_aXf -> n_aXf; Plus a_aXg b_aXh -> case $weval a_aXg of { __DEFAULT -> case $weval b_aXh of { __DEFAULT -> GHC.Types.I# (GHC.Prim.+# a_aXg b_aXh) } } } }}} Note that we were able to rewrite both inductive calls in terms of `$weval`, but still have the vanilla version around if we ever need the boxed result of `eval`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 20:55:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 20:55:01 -0000 Subject: [GHC] #16336: Build and deploy docker images on gitlab CI Message-ID: <049.e7fd557e3be3ded731bd011083e17288@haskell.org> #16336: Build and deploy docker images on gitlab CI -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The docker files we use for CI are in the `.circleci` folder at the moment. There should be a CI job which can be triggered to build and upload these images to docker hub. This would mean that anyone can update the builders rather than being block on one person. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 20:57:41 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 20:57:41 -0000 Subject: [GHC] #16337: Investigate using Gitlab "Review Apps" to review documentation Message-ID: <049.adcf767234831d62256295fc15f367be@haskell.org> #16337: Investigate using Gitlab "Review Apps" to review documentation -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- There are these things called "Review Apps" which are meant for reviewing things like websites/documentation. It might be good to set this up for reviewing documentation changes which can be hard to get right. https://docs.gitlab.com/ee/ci/review_apps/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 20:58:41 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 20:58:41 -0000 Subject: [GHC] #16338: Update CI images to 8.6.* and cabal-2.4.* Message-ID: <049.49dd0857c0abaccb7987eb91835269d2@haskell.org> #16338: Update CI images to 8.6.* and cabal-2.4.* -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The docker images need updating to a more recent GHC release. Probably best to do this after 8.6.4 is released. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 18 21:18:26 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Feb 2019 21:18:26 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.cad2eaad5934935d583a4b3bc0e3562f@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 14119 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The trick from comment:17 can be further generalized to a pseudo-algorithm that (I think) would work for any closed type family that suffers from this problem. Here is what you have to do: 1. Identity any "problematic" type families that cause the `Illegal type synonym family application in instance` error. In the original example, the only problematic type family is `Len`. 2. Encode each problematic type families as an inductive proposition. In the particular case of `Len`, this would look this like: {{{#!hs data LenProp :: forall a. [a] -> N -> Type where LenNil :: LenProp '[] Z LenCons :: LenProp xs n -> LenProp (x:xs) (S n) }}} The type family's argument kinds (e.g., `[a]`) as well as the return kind (e.g., `N`) become part of the proposition's kind. Each constructor encodes a single equation of the type family. The `LenNil` constructor encodes the `Len '[] = Z` equation, and its return type of `LenProp '[] Z` encodes the fact that this equation takes `'[]` as an argument and returns `Z`. Similarly, the `LenCons` constructor encodes the `Len (_ ': xs) = S (Len xs)` equation, and the field of type `LenProp xs n` encodes the recursive call to `Len` on the right-hand side of the equation. Notice that we "bind" the result of this recursive call to `n` and use `S n` in the return type, since the equation applies `S` to the recursive `Len` call. 3. Take all type families that were rejected previously due to occurrences of problematic type families and define "internal" versions of them using the newly defined proposition types. In the particular case of `At`, this would look this: {{{#!hs type family At' (xs :: [a]) (lp :: LenProp xs r) (i :: Fin r) :: a where At' (x:_) (LenCons _) FZ = x At' (_:xs) (LenCons lp) (FS i) = At' xs lp i }}} Note that `Len` does not appear anywhere in this definition. Where we previously had `Fin (Len xs)` we now have `Fin r`, where the `r` is bound by a new argument of kind `LenProp xs r`. In general, you'll need to introduce as many new arguments with proposition kinds as is necessary to replace all occurrences of problematic type families. 4. For each proposition-encoded type family, define another type family that translates the arguments of the original type family to the corresponding proposition. For example, the following type family translates a list to a `LenProp`: {{{#!hs type family EncodeLenProp (xs :: [a]) :: LenProp xs (Len xs) where EncodeLenProp '[] = LenNil EncodeLenProp (_:xs) = LenCons (EncodeLenProp xs) }}} Note the return kind of `LenProp xs (Len xs)`. This is important, since this is how we are going to "sneak in" a use of `Len` into `At` in the next step. Note that `Len` is not problematic in `EncodeLenProp` itself since `Len` never worms its way into a left-hand-side argument. 5. Finally, redefine type families in terms of the "internal" ones created in step (3). In the particular case of `At`, it would become: {{{#!hs type family At (xs :: [a]) (i :: Fin (Len xs)) :: a where At xs i = At' xs (EncodeLenProp xs) i }}} This uses `EncodeLenProp` to sneak a use of `Len` into `At'`. Critically, this definition avoids pattern-matching on `i` (since that would trigger the `Illegal type synonym family application in instance` error). All that `At` does now is pass its arguments along to `At'`, which does the real work on the proposition created by `EncodeLenProp`. In this version of `At`, the only place where `Len` occurs on the left-hand side is in the kind of `i`, which GHC deems acceptable. My program in comment:17 essentially follows the algorithm above, except it uses a slightly more complicated type, `Vec`, instead of `LenProp`. ----- This seems to work for all of the closed type families that I've encountered that suffer from this issue. That being said, this trick doesn't really work well in the setting of //open// type families, as it's not always possible to know //a priori// which kind arguments in an open type family might end up being instantiated with type families. If you figure out a general workaround for that, let me know :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 01:13:37 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 01:13:37 -0000 Subject: [GHC] #16168: Prelude docs for Integer mention J# In-Reply-To: <046.910a4bfcf428436f923f4f369d2e5583@haskell.org> References: <046.910a4bfcf428436f923f4f369d2e5583@haskell.org> Message-ID: <061.fd8d5156dcf0cd4c26af0c69ac40df0b@haskell.org> #16168: Prelude docs for Integer mention J# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: rockbmb Type: bug | Status: patch Priority: low | Milestone: Component: Core Libraries | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/308 -------------------------------------+------------------------------------- Changes (by rockbmb): * owner: (none) => rockbmb -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 01:13:51 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 01:13:51 -0000 Subject: [GHC] #16168: Prelude docs for Integer mention J# In-Reply-To: <046.910a4bfcf428436f923f4f369d2e5583@haskell.org> References: <046.910a4bfcf428436f923f4f369d2e5583@haskell.org> Message-ID: <061.bb47f77b40f8e02263e7b0583c742f89@haskell.org> #16168: Prelude docs for Integer mention J# -------------------------------------+------------------------------------- Reporter: nomeata | Owner: rockbmb Type: bug | Status: closed Priority: low | Milestone: Component: Core Libraries | Version: 8.6.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/308 -------------------------------------+------------------------------------- Changes (by rockbmb): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 09:36:52 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 09:36:52 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.25027d8153de9ddedd2d3f3d5f41968b@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * keywords: CPRAnalysis, DemandAnalysis => DemandAnalysis Comment: Looking at https://ghc.haskell.org/trac/ghc/attachment/ticket/10069/Blah .dump-simpl#L1668, I don't think this is related to CPR analysis but to the worker/wrapper transformation having issues with NOINLINE functions. What happens here is that `f1` to `f4` can't be inlined (so we don't see the case on the `A`), but `fa` still gets a strictness signature saying that all but arguments 2 to 5 are dead. WW will now split `fa` into a wrapper function that scrutinises the `A` to just project out the 4 arguments that aren't dead and pass it on to the worker `$wfa` unboxed. So far so good. Now, WW arranges it so that the worker `$wfa` builds up a new `A` with dummy values for absent fields (0# for Int#). Normally, this new `A` binding would cancel out with case matches in `$wfa`, because the strictness signature must ultimately come from some case expression. These however are hidden in `NOINLINE` functions, so no cancelling is happening. As a result, we allocate the dummy `A` for nothing, we could have just passed along the old `A`. Here's an example demonstrating this in the small: {{{#!hs data C = C !Int !Int {-# NOINLINE c1 #-} c1 :: C -> Int c1 (C _ c) = c {-# NOINLINE fc #-} fc :: C -> Int fc c = c1 c + c1 c }}} Relevant Core: {{{#!hs c1_rP = \ (ds_d3af :: C) -> case ds_d3af of { C dt_d3PA dt1_d3PB -> GHC.Types.I# dt1_d3PB } Main.$wfc = \ (ww_s7DJ :: GHC.Prim.Int#) -> case c1_rP (Main.C 0# ww_s7DJ) of { GHC.Types.I# x_a4kS -> GHC.Prim.*# 2# x_a4kS } fc = \ (w_s7DF :: C) -> case w_s7DF of { C ww1_s7DI ww2_s7DJ -> case Main.$wfc ww2_s7DJ of ww3_s7DN { __DEFAULT -> GHC.Types.I# ww3_s7DN } } }}} The problem I see here is that we don't WW `c1`, or that we don't inline the resulting wrapper into `fc` before the hypothetical worker `$wc1` of `c1` gets inlined back into `c1` because it's so small. If we inlined `$wc1` into `$wfc`, the case on `C` would cancel out with the dummy `C` and everything would be well. So: If we WW `fc`, we should also WW `c1`, otherwise we end up with bad code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 09:54:51 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 09:54:51 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.cb2f383c27d39185fd729630c3d4565b@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | DemandAnalysis 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): > So: If we WW fc, we should also WW c1, otherwise we end up with bad code. Quite right. Why does that not happen? It's because of {{{ tryWW dflags fam_envs is_rec fn_id rhs -- See Note [Worker-wrapper for NOINLINE functions] | Just stable_unf <- certainlyWillInline dflags fn_info = return [ (fn_id `setIdUnfolding` stable_unf, rhs) ] -- See Note [Don't w/w INLINE things] -- See Note [Don't w/w inline small non-loop-breaker things] }}} The Notes are informative. What happens here is that * `certainlyWillInline` returns True for `c1`, despite the NOINLINE pragma * We set a stable unfolding, for reasons described in `Note [Don't w/w inline small non-loop-breaker things]` * But alas the NOINLINE stays there and prevents `c1` inlining. I think we should always create a wrapper for NOINLINE things, just as if they were big. We already have technology for transferring the NOINLINE pragma to the worker; see * `Note [Worker-wrapper for INLINABLE functions]` * `Note [Worker activation]`, which even talks about NOINLINE specifically. So the bottom line is, I think, that the `certainlyWillInline` test should return False for NOINLINE functions. This call in `WorkWrap` is its only call site, so the change should be easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 11:25:31 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 11:25:31 -0000 Subject: [GHC] #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> References: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> Message-ID: <062.b5e6067b982ea1a397115c14da461973@haskell.org> #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Simplifier Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: 15840 Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/325 -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 11:26:01 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 11:26:01 -0000 Subject: [GHC] #15840: Inline data constructor wrappers very late In-Reply-To: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> References: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> Message-ID: <062.15a116d06874ead469d6bfa283285b03@haskell.org> #15840: Inline data constructor wrappers very late -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 16288 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/325/ -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * differential: Phab:D5400 => https://gitlab.haskell.org/ghc/ghc/merge_requests/325/ * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 11:26:22 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 11:26:22 -0000 Subject: [GHC] #16254: INLINABLE pragma and newtype wrappers prevent inlining In-Reply-To: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> References: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> Message-ID: <062.6382820e23f2a45d87b9ef29ddf3ccb5@haskell.org> #16254: INLINABLE pragma and newtype wrappers prevent inlining -------------------------------------+------------------------------------- Reporter: monoidal | Owner: monoidal Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5327 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/325/ -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * differential: https://gitlab.haskell.org/ghc/ghc/merge_requests/247 => https://gitlab.haskell.org/ghc/ghc/merge_requests/325/ * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 11:44:52 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 11:44:52 -0000 Subject: [GHC] #16254: INLINABLE pragma and newtype wrappers prevent inlining In-Reply-To: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> References: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> Message-ID: <062.013752b9e1cb4d958b8edb6fd99c4183@haskell.org> #16254: INLINABLE pragma and newtype wrappers prevent inlining -------------------------------------+------------------------------------- Reporter: monoidal | Owner: monoidal Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5327 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/325/ -------------------------------------+------------------------------------- Comment (by simonpj): What about a regression test for this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 11:45:40 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 11:45:40 -0000 Subject: [GHC] #15840: Inline data constructor wrappers very late In-Reply-To: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> References: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> Message-ID: <062.6c37450171d65799c7bf8b1d12d0e930@haskell.org> #15840: Inline data constructor wrappers very late -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 16288 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/325/ -------------------------------------+------------------------------------- Comment (by simonpj): Are there any regression tests? Eg RULEs that match on data constructors that have interesting wrappers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 11:47:29 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 11:47:29 -0000 Subject: [GHC] #16254: INLINABLE pragma and newtype wrappers prevent inlining In-Reply-To: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> References: <047.1cce3f34e3d0bb600fb5da967fc16c73@haskell.org> Message-ID: <062.08450073ac94be3d5630f82c02049c31@haskell.org> #16254: INLINABLE pragma and newtype wrappers prevent inlining -------------------------------------+------------------------------------- Reporter: monoidal | Owner: monoidal Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T16254 Blocked By: | Blocking: Related Tickets: #5327 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/325/ -------------------------------------+------------------------------------- Changes (by monoidal): * testcase: => simplCore/should_compile/T16254 Comment: It was pushed, I've set it here now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 11:49:23 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 11:49:23 -0000 Subject: [GHC] #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> References: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> Message-ID: <062.333a81fabb434773f631762ec44893d6@haskell.org> #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Simplifier Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: 15840 Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/325 -------------------------------------+------------------------------------- Comment (by simonpj): Did you add a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 11:51:30 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 11:51:30 -0000 Subject: [GHC] #15840: Inline data constructor wrappers very late In-Reply-To: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> References: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> Message-ID: <062.22d6cc01d0d4ae468cafe5b43ee12fb1@haskell.org> #15840: Inline data constructor wrappers very late -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_run/{T15840,T15840a} Blocked By: 16288 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/325/ -------------------------------------+------------------------------------- Changes (by monoidal): * testcase: => simplCore/should_run/{T15840,T15840a} Comment: There are two tests that use `data T = MkT !Bool`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 11:53:29 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 11:53:29 -0000 Subject: [GHC] #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> References: <047.3be7ab5e8eec110aceddbbd801423e99@haskell.org> Message-ID: <062.71ed9c8f516cb4f84babf4138a5f5bbe@haskell.org> #16288: Core Lint error: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Simplifier Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: T16288 Blocked By: | Blocking: 15840 Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/325 -------------------------------------+------------------------------------- Changes (by monoidal): * testcase: => T16288 Comment: Yes, T16288 uses the three files from the description of the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 12:34:28 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 12:34:28 -0000 Subject: [GHC] #13971: Misleading "Kind mis-match on LHS of default declaration" error In-Reply-To: <050.d40bc20f28df73e49993d6ba5839a725@haskell.org> References: <050.d40bc20f28df73e49993d6ba5839a725@haskell.org> Message-ID: <065.232d4743f49d11821b2d6fb690040b30@haskell.org> #13971: Misleading "Kind mis-match on LHS of default declaration" error -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeFamilies 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): What's curious is that in other situations, the error message you get for mismatched kinds in type family defaults is much clearer. For instance: {{{ λ> class C a where { type T a; type T a = 4 } :1:40: error: • Expected a type, but ‘4’ has kind ‘GHC.Types.Nat’ • In the type ‘4’ In the default type instance declaration for ‘T’ In the class declaration for ‘C’ }}} That is much, much better than the vague "Kind mis-match on LHS of default declaration" message we get in the original program. I wonder if GHC can arrange for this "Expected a type, but `foo` has kind `Bar`" error message to trigger for the original program as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 13:40:47 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 13:40:47 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.231f6944c780cbde573fd1a6954aa0f5@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T10069 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): !401 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => patch * testcase: => T10069 * differential: => !401 Comment: I prepared a fix in https://gitlab.haskell.org/ghc/ghc/merge_requests/401. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 14:28:48 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 14:28:48 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.fffe8d87587abc23f84c69628ce0a612@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T10069 Blocked By: | Blocking: Related Tickets: #13143 | Differential Rev(s): !401 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #13143 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 14:56:15 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 14:56:15 -0000 Subject: [GHC] #16339: Cannot put (.) or (!) into an export list Message-ID: <050.512bf1bda3242ed4564080d5f3cf14ba@haskell.org> #16339: Cannot put (.) or (!) into an export list -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Parser) | 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: -------------------------------------+------------------------------------- Thanks to recent work in GHC HEAD, it is now possible to define type operators named `(.)` and `(!)`: {{{#!hs type (f . g) x = f (g x) type x ! f = f x }}} However, I was surprised to discover that it's not possible to put them in an export list! That is to say, this program doesn't parse: {{{ {-# LANGUAGE TypeOperators #-} module Bug (type (.), type (!)) where type (f . g) x = f (g x) type x ! f = f x }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.7.20190219: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci Bug.hs:2:19: error: parse error on input ‘.’ | 2 | module Bug (type (.), type (!)) where | ^ }}} This problem appears to be specific to the `(.)` and `(!)` type operators, since any other type operator will work in its place: {{{#!hs {-# LANGUAGE TypeOperators #-} module Works (type (&)) where type (f & g) x = f (g x) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 14:56:47 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 14:56:47 -0000 Subject: [GHC] #16339: Cannot put (.) or (!) type operators into an export list (was: Cannot put (.) or (!) into an export list) In-Reply-To: <050.512bf1bda3242ed4564080d5f3cf14ba@haskell.org> References: <050.512bf1bda3242ed4564080d5f3cf14ba@haskell.org> Message-ID: <065.411ead6da40b92b5ed9a6055dff2ba76@haskell.org> #16339: Cannot put (.) or (!) type operators into an export list -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Parser) | 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 15:00:15 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 15:00:15 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.11f33aedf47028f8979e628587147730@haskell.org> #10069: CPR related performance issue -------------------------------------+------------------------------------- Reporter: pacak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T10069 Blocked By: | Blocking: Related Tickets: #13143 | Differential Rev(s): !401 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * milestone: => 8.8.1 Comment: I think this would be nice to have in 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 15:20:32 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 15:20:32 -0000 Subject: [GHC] #16339: Cannot put (.) or (!) type operators into an export list In-Reply-To: <050.512bf1bda3242ed4564080d5f3cf14ba@haskell.org> References: <050.512bf1bda3242ed4564080d5f3cf14ba@haskell.org> Message-ID: <065.30d39924a40fe727962e0e783a4ddc60@haskell.org> #16339: Cannot put (.) or (!) type operators into an export list -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Parser) | 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 int-index): Bummer. Fix coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 15:33:01 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 15:33:01 -0000 Subject: [GHC] #16339: Cannot put (.) or (!) type operators into an export list In-Reply-To: <050.512bf1bda3242ed4564080d5f3cf14ba@haskell.org> References: <050.512bf1bda3242ed4564080d5f3cf14ba@haskell.org> Message-ID: <065.9275a7f478b7487222244a1f7009ed9d@haskell.org> #16339: Cannot put (.) or (!) type operators into an export list -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 (Parser) | 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: | https://gitlab.haskell.org/ghc/ghc/merge_requests/403 -------------------------------------+------------------------------------- Changes (by int-index): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/403 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 15:34:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 15:34:16 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.24296edca8038f2844ecf64ec19535f1@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.6.4 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 | (reverted), Phab:D5165, Phab:D5178, Wiki Page: | MR:103, MR:146 -------------------------------------+------------------------------------- Comment (by osa1): bgamari, I think we want to merge !146 for the next release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 15:38:06 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 15:38:06 -0000 Subject: [GHC] #16297: Access violation and hang with template haskell In-Reply-To: <044.d7d75b5965ee2cd38679152111ba5ed0@haskell.org> References: <044.d7d75b5965ee2cd38679152111ba5ed0@haskell.org> Message-ID: <059.0bce518fffb039226f9476504122def1@haskell.org> #16297: Access violation and hang with template haskell -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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: | -------------------------------------+------------------------------------- Description changed by jeiea: Old description: > I found this while building the haskell-ide-engine on windows. During > that build I was stuck on two packages(fclabels, haskell-lsp-types). > > {{{ > D:\test>stack install --resolver lts-13.6 fclabels > fclabels-2.0.3.3: configure > fclabels-2.0.3.3: build > > -- While building package fclabels-2.0.3.3 using: > C:\sr\setup-exe-cache\x86_64-windows\Cabal- > simple_Z6RU0evB_2.4.0.1_ghc-8.6.3.exe --builddir=.stack- > work\dist\e626a42b build --ghc-options " -ddump-hi -ddump-to-file > -fdiagnostics-color=always" > Process exited with code: ExitFailure 1 > Logs have been written to: C:\sr\global-project\.stack- > work\logs\fclabels-2.0.3.3.log > > Configuring fclabels-2.0.3.3... > Preprocessing library for fclabels-2.0.3.3.. > Building library for fclabels-2.0.3.3.. > [ 1 of 10] Compiling Data.Label.Point ( src\Data\Label\Point.hs, > .stack-work\dist\e626a42b\build\Data\Label\Point.o ) > [ 2 of 10] Compiling Data.Label.Poly ( src\Data\Label\Poly.hs, > .stack-work\dist\e626a42b\build\Data\Label\Poly.o ) > [ 3 of 10] Compiling Data.Label.Partial ( src\Data\Label\Partial.hs, > .stack-work\dist\e626a42b\build\Data\Label\Partial.o ) > [ 4 of 10] Compiling Data.Label.Mono ( src\Data\Label\Mono.hs, > .stack-work\dist\e626a42b\build\Data\Label\Mono.o ) > [ 5 of 10] Compiling Data.Label.Failing ( src\Data\Label\Failing.hs, > .stack-work\dist\e626a42b\build\Data\Label\Failing.o ) > [ 6 of 10] Compiling Data.Label.Derive ( src\Data\Label\Derive.hs, > .stack-work\dist\e626a42b\build\Data\Label\Derive.o ) > [ 7 of 10] Compiling Data.Label ( src\Data\Label.hs, .stack- > work\dist\e626a42b\build\Data\Label.o ) > [ 8 of 10] Compiling Data.Label.Base ( src\Data\Label\Base.hs, > .stack-work\dist\e626a42b\build\Data\Label\Base.o ) > -- doesn't terminate > }}} > > {{{ > D:\test>stack install --resolver lts-13.6 haskell-lsp-types > haskell-lsp-types-0.8.0.1: configure > haskell-lsp-types-0.8.0.1: build > > -- While building package haskell-lsp-types-0.8.0.1 using: > C:\sr\setup-exe-cache\x86_64-windows\Cabal- > simple_Z6RU0evB_2.4.0.1_ghc-8.6.3.exe --builddir=.stack- > work\dist\e626a42b build --ghc-options " -ddump-hi -ddump-to-file > -fdiagnostics-color=always" > Process exited with code: ExitFailure 11 > Logs have been written to: D:\Hoj\Desktop\fclabels-2.0.3.3\.stack- > work\logs\haskell-lsp-types-0.8.0.1.log > > Configuring haskell-lsp-types-0.8.0.1... > Preprocessing library for haskell-lsp-types-0.8.0.1.. > Building library for haskell-lsp-types-0.8.0.1.. > [ 1 of 24] Compiling Language.Haskell.LSP.Types.Constants ( > src\Language\Haskell\LSP\Types\Constants.hs, .stack- > work\dist\e626a42b\build\Language\Haskell\LSP\Types\Constants.o ) > [ 2 of 24] Compiling Language.Haskell.LSP.Types.List ( > src\Language\Haskell\LSP\Types\List.hs, .stack- > work\dist\e626a42b\build\Language\Haskell\LSP\Types\List.o ) > [ 3 of 24] Compiling Language.Haskell.LSP.Types.DocumentFilter ( > src\Language\Haskell\LSP\Types\DocumentFilter.hs, .stack- > work\dist\e626a42b\build\Language\Haskell\LSP\Types\DocumentFilter.o ) > > Access violation in generated code when reading 0x1017895900 > > Attempting to reconstruct a stack trace... > > Frame Code address > * 0x4ffd920 0x17c3f148 C:\sr\snapshots\3233b5e2\lib\x86_64 > -windows- > ghc-8.6.3\aeson-1.4.2.0-nGorlomFPWK9VTcoGhjmV\HSaeson-1.4.2.0-nGorlomFPWK9VTcoGhjmV.o+0x2f040 > (aesonzm1zi4zi2zi0zmnGorlomFPWK9VTcoGhjmV_DataziAesonziTH_consToValue_info+0x688) > }}} > > I don't know if those two issues are same. > > I tried simplifying the former. > > {{{ > -- A.hs > {-# LANGUAGE NoMonomorphismRestriction #-} > {-# LANGUAGE TemplateHaskell #-} > > module A > ( head > , tail > ) where > > -- import Prelude hiding (fst, snd, head, tail) > -- import Control.Arrow (arr, Kleisli(..), ArrowApply, ArrowZero, > ArrowChoice) > import B (getLabel) > > -- data Point cat g i f o = Point (cat f o) (cat (cat o i, f) g) > > -- data PLens cat f o where > -- PLens :: !(Point cat g i f o) -> PLens cat (f -> g) (o -> i) > -- Id :: ArrowApply cat => PLens cat f f > > -- type Lens cat f o = PLens cat (f -> f) (o -> o) > > -- head :: (ArrowZero arr, ArrowApply arr, ArrowChoice arr) => Lens arr > [a] a > -- tail :: (ArrowZero arr, ArrowApply arr, ArrowChoice arr) => Lens arr > [a] [a] > > (head, tail) = $(getLabel ''[]) > }}} > > {{{ > -- B.hs > {-# LANGUAGE TemplateHaskell #-} > module B (getLabel) where > import Language.Haskell.TH > > getLabel :: Name -> Q Exp > getLabel = undefined > }}} > > `stack exec ghc --resolver lts-13.6 -- A.hs B.hs` also hangs. New description: I found this while building the haskell-ide-engine on windows. During that build I was stuck in two packages(fclabels, haskell-lsp-types). {{{ D:\test>stack install --resolver lts-13.6 fclabels fclabels-2.0.3.3: configure fclabels-2.0.3.3: build -- While building package fclabels-2.0.3.3 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.4.0.1_ghc-8.6.3.exe --builddir=.stack-work\dist\e626a42b build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Logs have been written to: C:\sr\global-project\.stack- work\logs\fclabels-2.0.3.3.log Configuring fclabels-2.0.3.3... Preprocessing library for fclabels-2.0.3.3.. Building library for fclabels-2.0.3.3.. [ 1 of 10] Compiling Data.Label.Point ( src\Data\Label\Point.hs, .stack-work\dist\e626a42b\build\Data\Label\Point.o ) [ 2 of 10] Compiling Data.Label.Poly ( src\Data\Label\Poly.hs, .stack-work\dist\e626a42b\build\Data\Label\Poly.o ) [ 3 of 10] Compiling Data.Label.Partial ( src\Data\Label\Partial.hs, .stack-work\dist\e626a42b\build\Data\Label\Partial.o ) [ 4 of 10] Compiling Data.Label.Mono ( src\Data\Label\Mono.hs, .stack-work\dist\e626a42b\build\Data\Label\Mono.o ) [ 5 of 10] Compiling Data.Label.Failing ( src\Data\Label\Failing.hs, .stack-work\dist\e626a42b\build\Data\Label\Failing.o ) [ 6 of 10] Compiling Data.Label.Derive ( src\Data\Label\Derive.hs, .stack-work\dist\e626a42b\build\Data\Label\Derive.o ) [ 7 of 10] Compiling Data.Label ( src\Data\Label.hs, .stack- work\dist\e626a42b\build\Data\Label.o ) [ 8 of 10] Compiling Data.Label.Base ( src\Data\Label\Base.hs, .stack-work\dist\e626a42b\build\Data\Label\Base.o ) -- doesn't terminate }}} {{{ D:\test>stack install --resolver lts-13.6 haskell-lsp-types haskell-lsp-types-0.8.0.1: configure haskell-lsp-types-0.8.0.1: build -- While building package haskell-lsp-types-0.8.0.1 using: C:\sr\setup-exe-cache\x86_64-windows\Cabal- simple_Z6RU0evB_2.4.0.1_ghc-8.6.3.exe --builddir=.stack-work\dist\e626a42b build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 11 Logs have been written to: D:\Hoj\Desktop\fclabels-2.0.3.3\.stack- work\logs\haskell-lsp-types-0.8.0.1.log Configuring haskell-lsp-types-0.8.0.1... Preprocessing library for haskell-lsp-types-0.8.0.1.. Building library for haskell-lsp-types-0.8.0.1.. [ 1 of 24] Compiling Language.Haskell.LSP.Types.Constants ( src\Language\Haskell\LSP\Types\Constants.hs, .stack- work\dist\e626a42b\build\Language\Haskell\LSP\Types\Constants.o ) [ 2 of 24] Compiling Language.Haskell.LSP.Types.List ( src\Language\Haskell\LSP\Types\List.hs, .stack- work\dist\e626a42b\build\Language\Haskell\LSP\Types\List.o ) [ 3 of 24] Compiling Language.Haskell.LSP.Types.DocumentFilter ( src\Language\Haskell\LSP\Types\DocumentFilter.hs, .stack- work\dist\e626a42b\build\Language\Haskell\LSP\Types\DocumentFilter.o ) Access violation in generated code when reading 0x1017895900 Attempting to reconstruct a stack trace... Frame Code address * 0x4ffd920 0x17c3f148 C:\sr\snapshots\3233b5e2\lib\x86_64 -windows- ghc-8.6.3\aeson-1.4.2.0-nGorlomFPWK9VTcoGhjmV\HSaeson-1.4.2.0-nGorlomFPWK9VTcoGhjmV.o+0x2f040 (aesonzm1zi4zi2zi0zmnGorlomFPWK9VTcoGhjmV_DataziAesonziTH_consToValue_info+0x688) }}} I don't know if those two issues are same. I tried simplifying the former. {{{ -- A.hs {-# LANGUAGE NoMonomorphismRestriction #-} {-# LANGUAGE TemplateHaskell #-} module A ( head , tail ) where -- import Prelude hiding (fst, snd, head, tail) -- import Control.Arrow (arr, Kleisli(..), ArrowApply, ArrowZero, ArrowChoice) import B (getLabel) -- data Point cat g i f o = Point (cat f o) (cat (cat o i, f) g) -- data PLens cat f o where -- PLens :: !(Point cat g i f o) -> PLens cat (f -> g) (o -> i) -- Id :: ArrowApply cat => PLens cat f f -- type Lens cat f o = PLens cat (f -> f) (o -> o) -- head :: (ArrowZero arr, ArrowApply arr, ArrowChoice arr) => Lens arr [a] a -- tail :: (ArrowZero arr, ArrowApply arr, ArrowChoice arr) => Lens arr [a] [a] (head, tail) = $(getLabel ''[]) }}} {{{ -- B.hs {-# LANGUAGE TemplateHaskell #-} module B (getLabel) where import Language.Haskell.TH getLabel :: Name -> Q Exp getLabel = undefined }}} `stack exec ghc --resolver lts-13.6 -- A.hs B.hs` also hangs. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 15:48:21 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 15:48:21 -0000 Subject: [GHC] #16297: Access violation and hang with template haskell In-Reply-To: <044.d7d75b5965ee2cd38679152111ba5ed0@haskell.org> References: <044.d7d75b5965ee2cd38679152111ba5ed0@haskell.org> Message-ID: <059.ecb2728f0482b7722d609b782813ac5d@haskell.org> #16297: Access violation and hang with template haskell -------------------------------------+------------------------------------- Reporter: jeiea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #16057 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #16057 Comment: Thanks for the bug report. This was previously reported as #16057, which should be fixed in an upcoming GHC point release. I'll close this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 17:34:11 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 17:34:11 -0000 Subject: [GHC] #16195: Program with trivial polymorphism leads to out of scope dictionary In-Reply-To: <049.a0fd1d6b50ba4adcca69a2eecfff259d@haskell.org> References: <049.a0fd1d6b50ba4adcca69a2eecfff259d@haskell.org> Message-ID: <064.4e5b283b729d293bd8b2bd0106997c90@haskell.org> #16195: Program with trivial polymorphism leads to out of scope dictionary -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge Comment: I understand we'd like to merge this, since the commit causing the regression is in ghc-8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 17:48:44 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 17:48:44 -0000 Subject: [GHC] #16195: Program with trivial polymorphism leads to out of scope dictionary In-Reply-To: <049.a0fd1d6b50ba4adcca69a2eecfff259d@haskell.org> References: <049.a0fd1d6b50ba4adcca69a2eecfff259d@haskell.org> Message-ID: <064.44a05c0646087e237bbc6030f9025d1a@haskell.org> #16195: Program with trivial polymorphism leads to out of scope dictionary -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: | TypedTemplateHaskell Operating System: 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): Do we have a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 17:51:27 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 17:51:27 -0000 Subject: [GHC] #16195: Program with trivial polymorphism leads to out of scope dictionary In-Reply-To: <049.a0fd1d6b50ba4adcca69a2eecfff259d@haskell.org> References: <049.a0fd1d6b50ba4adcca69a2eecfff259d@haskell.org> Message-ID: <064.50a459baa21ceaf7cb0287e656520f9d@haskell.org> #16195: Program with trivial polymorphism leads to out of scope dictionary -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T16195 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * testcase: => th/T16195 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 19 22:06:48 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 19 Feb 2019 22:06:48 -0000 Subject: [GHC] #16340: Improve properFraction for Ratio Message-ID: <045.5c85985af44d39bc6c0c83f011217f3d@haskell.org> #16340: Improve properFraction for Ratio -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Core | Version: 8.6.3 Libraries | 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: -------------------------------------+------------------------------------- We define {{{#!hs properFraction (x:%y) = (fromInteger (toInteger q), r:%y) where (q, r) = quotRem x y }}} The first problem is that this produces a lazy pair. The second problem is that it uses `fromInteger . toInteger` rather than `fromIntegral`; the latter has rewrite rules that the former lacks. The whole thing should be written as {{{#!hs properFraction (x:%y) = (q', r:%y) where !(q, r) = quotRem x y !q' = fromIntegral q }}} or possibly {{{#!hs properFraction (x:%y) = (fromIntegral q, r:%y) where !(q, r) = quotRem x y }}} The latter is better if someone only wants the fractional part and is using `Integral` types for which `fromIntegral` is unusually expensive, but I don't know if that's really worth worrying about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 02:46:10 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 02:46:10 -0000 Subject: [GHC] #16036: expDouble## 0.0## doesn't get complied into 1.0## In-Reply-To: <047.020d4a64c20b7d77000bf2ad3648d15f@haskell.org> References: <047.020d4a64c20b7d77000bf2ad3648d15f@haskell.org> Message-ID: <062.8b552c2266d811f41e85dccf6278a297@haskell.org> #16036: expDouble## 0.0## doesn't get complied into 1.0## -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): For exp 0, on float or double, I believe the answe is always 1. Exactly. Note that this is ignoring negative zero. I believe that exp of negative infinity should always be positive zero. But I’ll need to think about it However, i believe that for any other constants the exact answer may depend on the rounding mode at the time of execution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 02:47:15 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 02:47:15 -0000 Subject: [GHC] #16036: expDouble## 0.0## doesn't get complied into 1.0## In-Reply-To: <047.020d4a64c20b7d77000bf2ad3648d15f@haskell.org> References: <047.020d4a64c20b7d77000bf2ad3648d15f@haskell.org> Message-ID: <062.3f9fbf7c998b4d7190864251d635c56c@haskell.org> #16036: expDouble## 0.0## doesn't get complied into 1.0## -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): I’ll need to do some digging to figure out how to enable us to have a nice correct / exact rounding reference for all the standard functions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 03:31:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 03:31:08 -0000 Subject: [GHC] #16341: Standalone deriving for GADTs should avoid impossible cases Message-ID: <046.a421aacba819cf41c4e63458f4be36bc@haskell.org> #16341: Standalone deriving for GADTs should avoid impossible cases -------------------------------------+------------------------------------- Reporter: mnoonan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: | https://ghc.haskell.org/trac/ghc/ticket/15398 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One solution to bringing recursion schemes to mutually-recursive types is to combine the different types into a single GADT `T`, parameterized by a tag type. To really make this ergonomic, it would be nice to be able to derive instances for individual tags. And this almost works! But not always: {{{#!hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} {-# OPTIONS_GHC -Wall -Werror -ddump-deriv #-} module M where data T = T -- no Show instance data Good a where A :: Good Int B :: T -> Good Char data Fine a where P :: Fine Int Q :: Fine Char data Bad a where X :: Bad Int Y :: T -> Bad Char instance Show (Good Int) where -- OK and warning-free show A = "A" deriving instance Show (Fine Int) -- OK, because of suppressed warnings deriving instance Show (Bad Int) -- Fails! }}} This fails with the error {{{ example.hs:25:1: error: • Could not deduce (Show T) arising from a use of ‘showsPrec’ from the context: Int ~ Char bound by a pattern with constructor: Y :: T -> Bad Char, in an equation for ‘showsPrec’ at example.hs:25:1-33 }}} The derived code is as follows: {{{ ==================== Derived instances ==================== Derived class instances: instance GHC.Show.Show (M.Bad GHC.Types.Int) where GHC.Show.showsPrec _ M.X = GHC.Show.showString "X" GHC.Show.showsPrec a_a1cf (M.Y b1_a1cg) = GHC.Show.showParen (a_a1cf GHC.Classes.>= 11) ((GHC.Base..) (GHC.Show.showString "Y ") (GHC.Show.showsPrec 11 b1_a1cg)) instance GHC.Show.Show (M.Fine GHC.Types.Int) where GHC.Show.showsPrec _ M.P = GHC.Show.showString "P" GHC.Show.showsPrec _ M.Q = GHC.Show.showString "Q" }}} Is there a way that the derived `Show` code for `Bad Int` could avoid emitting cases for `Bad Char` terms? A solution that worked even for a limited set of tags would be still be interesting; for example, restricting to situations where the GADT was indexed by a sum kind like `data K = Ix1 | Ix2 | ... | IxN`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 03:56:56 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 03:56:56 -0000 Subject: [GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower In-Reply-To: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> References: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> Message-ID: <061.e9543b9c9d7e0e62ced4ab8ca4272408@haskell.org> #15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: ⊥ Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 07:51:27 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 07:51:27 -0000 Subject: [GHC] #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable In-Reply-To: <049.9c2fa9e6abd9dac498eb7d8403e15a78@haskell.org> References: <049.9c2fa9e6abd9dac498eb7d8403e15a78@haskell.org> Message-ID: <064.302a7cbdf028dec6cbf79bf7a40df119@haskell.org> #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: | TypedTemplateHaskell Operating System: 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): My office mate ran into exactly this bug when trying to stage a non- trivial (500 line) program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 09:42:13 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 09:42:13 -0000 Subject: [GHC] #16341: Standalone deriving for GADTs should avoid impossible cases In-Reply-To: <046.a421aacba819cf41c4e63458f4be36bc@haskell.org> References: <046.a421aacba819cf41c4e63458f4be36bc@haskell.org> Message-ID: <061.94389940f49de2cea4aca3e5094a51ff@haskell.org> #16341: Standalone deriving for GADTs should avoid impossible cases -------------------------------------+------------------------------------- Reporter: mnoonan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): https://ghc.haskell.org/trac/ghc/ticket/15398| Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I suspect this would not be too hard. See `DataCon.dataConCannotMatch` and its call sites. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 09:56:39 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 09:56:39 -0000 Subject: [GHC] #16342: Kind inference crash Message-ID: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> #16342: Kind inference crash -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Here's a gnarly test case {{{ {-# LANGUAGE MultiParamTypeClasses, TypeInType, ConstrainedClassMethods, ScopedTypeVariables #-} module Foo where import Data.Proxy class C (a::ka) x where cop :: D a x => x -> Proxy a -> Proxy a cop _ x = x :: Proxy (a::ka) class D (b::kb) y where dop :: C b y => y -> Proxy b -> Proxy b dop _ x = x :: Proxy (b::kb) }}} This crashes every recent GHC with {{{ • GHC internal error: ‘kb’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [avu :-> Type variable ‘b’ = b :: ka, avv :-> Type variable ‘y’ = y :: *, avw :-> Identifier[x::Proxy b, NotLetBound], avx :-> Type variable ‘ka’ = ka :: *] • In the kind ‘kb’ In the first argument of ‘Proxy’, namely ‘(b :: kb)’ In an expression type signature: Proxy (b :: kb) | 13 | dop _ x = x :: Proxy (b::kb) | ^^ }}} Yikes. Reason: * `C` and `D` are mutually recursive * `ka` and `kb` get bound to unification variables, and then get unified in the kind-inference phase * As a result the utterly-final class for `C` and `D` end up with the same `TyVar` for `ka`/`kb`. * And then, for one of them, the tyvar is not in scope when (much, much later) we check the default declaration. Gah! In `generaliseTcTyCon` I think we may need to do a reverse-map to ensure that each of the final `tyConTyVars` has the `Name` from this declaration, rather than accidentally getting a `Name` from another decl in the mutually recursive group. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 09:57:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 09:57:03 -0000 Subject: [GHC] #16342: Kind inference crash In-Reply-To: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> References: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> Message-ID: <061.397a59ffea5a3bb3aca5f89c3a9f80c2@haskell.org> #16342: Kind inference crash -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Here's a gnarly test case > {{{ > {-# LANGUAGE MultiParamTypeClasses, TypeInType, ConstrainedClassMethods, > ScopedTypeVariables #-} > > module Foo where > > import Data.Proxy > > class C (a::ka) x where > cop :: D a x => x -> Proxy a -> Proxy a > cop _ x = x :: Proxy (a::ka) > > class D (b::kb) y where > dop :: C b y => y -> Proxy b -> Proxy b > dop _ x = x :: Proxy (b::kb) > }}} > This crashes every recent GHC with > {{{ > • GHC internal error: ‘kb’ is not in scope during type checking, but > it passed the renamer > tcl_env of environment: [avu :-> Type variable ‘b’ = b :: ka, > avv :-> Type variable ‘y’ = y :: *, > avw :-> Identifier[x::Proxy b, > NotLetBound], > avx :-> Type variable ‘ka’ = ka :: *] > • In the kind ‘kb’ > In the first argument of ‘Proxy’, namely ‘(b :: kb)’ > In an expression type signature: Proxy (b :: kb) > | > 13 | dop _ x = x :: Proxy (b::kb) > | ^^ > }}} > Yikes. > > Reason: > * `C` and `D` are mutually recursive > * `ka` and `kb` get bound to unification variables, and then get unified > in the kind-inference phase > * As a result the utterly-final class for `C` and `D` end up with the > same `TyVar` for `ka`/`kb`. > * And then, for one of them, the tyvar is not in scope when (much, much > later) we check the default declaration. > > Gah! In `generaliseTcTyCon` I think we may need to do a reverse-map to > ensure that each of the final `tyConTyVars` has the `Name` from this > declaration, rather than accidentally getting a `Name` from another decl > in the mutually recursive group. New description: Here's a gnarly test case {{{ {-# LANGUAGE MultiParamTypeClasses, TypeInType, ConstrainedClassMethods, ScopedTypeVariables #-} module Foo where import Data.Proxy class C (a::ka) x where cop :: D a x => x -> Proxy a -> Proxy a cop _ x = x :: Proxy (a::ka) class D (b::kb) y where dop :: C b y => y -> Proxy b -> Proxy b dop _ x = x :: Proxy (b::kb) }}} This crashes every recent GHC outright, with {{{ • GHC internal error: ‘kb’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [avu :-> Type variable ‘b’ = b :: ka, avv :-> Type variable ‘y’ = y :: *, avw :-> Identifier[x::Proxy b, NotLetBound], avx :-> Type variable ‘ka’ = ka :: *] • In the kind ‘kb’ In the first argument of ‘Proxy’, namely ‘(b :: kb)’ In an expression type signature: Proxy (b :: kb) | 13 | dop _ x = x :: Proxy (b::kb) | ^^ }}} Yikes. Reason: * `C` and `D` are mutually recursive * `ka` and `kb` get bound to unification variables, and then get unified in the kind-inference phase * As a result the utterly-final class for `C` and `D` end up with the same `TyVar` for `ka`/`kb`. * And then, for one of them, the tyvar is not in scope when (much, much later) we check the default declaration. Gah! In `generaliseTcTyCon` I think we may need to do a reverse-map to ensure that each of the final `tyConTyVars` has the `Name` from this declaration, rather than accidentally getting a `Name` from another decl in the mutually recursive group. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 10:20:06 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 10:20:06 -0000 Subject: [GHC] #16343: Changing an irrelevant constraint leads to inlining failure Message-ID: <049.e18b8e351fabe80a824a994893607109@haskell.org> #16343: Changing an irrelevant constraint leads to inlining failure -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is an example Andres sent me but I can't work out precisely what is going on. {{{ {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeOperators #-} module Tests where import Data.Kind import Data.Maybe (maybeToList) data Product (f :: a -> Type) (xs :: [a]) :: Type where Nil :: Product f '[] (:*) :: f x -> !(Product f xs) -> Product f (x : xs) infixr 5 :* class Top a instance Top a class (forall d . (forall x . c x => d x) => All d xs) => All (c :: a -> Constraint) (xs :: [a]) where ccataList :: f '[] -> (forall y ys . (c y, All c ys) => f ys -> f (y : ys)) -> f xs instance All c '[] where ccataList nil _cons = nil {-# INLINE ccataList #-} instance (c x, All c xs) => All c (x : xs) where ccataList nil cons = cons (ccataList @_ @c nil cons) {-# INLINE ccataList #-} newtype (f ~> g) x = Lambda { apply :: f x -> g x } cpureProduct :: forall c xs f . All c xs => (forall x . c x => f x) -> Product f xs cpureProduct p = ccataList @_ @c Nil (p :*) {-# INLINE cpureProduct #-} newtype Apply f g x = MkApply { unApply :: Product (f ~> g) x -> Product f x -> Product g x } capplyProduct :: forall c xs f g . All c xs => Product (f ~> g) xs -> Product f xs -> Product g xs capplyProduct = unApply $ ccataList @_ @c (MkApply (\ Nil Nil -> Nil)) (\ rec -> MkApply (\ (f :* fs) (x :* xs) -> apply f x :* unApply rec fs xs)) {-# INLINE capplyProduct #-} -- The addition of the constraint makes the test pass. mapProduct :: forall c xs f g . ({- All Top xs, -} All c xs) => (forall x . c x => f x -> g x) -> Product f xs -> Product g xs mapProduct p q = capplyProduct @Top (cpureProduct @c (Lambda p)) q {-# INLINE mapProduct #-} test :: Product [] [ (), (), () ] test = mapProduct @Top maybeToList (cpureProduct @Top Nothing) reference :: Product [] [ (), (), () ] reference = [] :* [] :* [] :* Nil }}} `test` should simplify to something close to `reference. There are a few ways to make it do so. 1. Uncomment the constraint in `mapProduct` 2. Change `Top` to `c` in `capplyProduct @Top`. From looking at `-ddump-inlinings`, it seems that things start to go wrong when `$cccataList` is inlined. In the good case, it looks like this. {{{ Considering inlining: $cccataList_a1Bi arg infos [ValueArg, ValueArg, ValueArg, ValueArg, NonTrivArg, NonTrivArg] interesting continuation RhsCtxt some_benefit True is exp: True is work-free: True guidance ALWAYS_IF(arity=4,unsat_ok=False,boring_ok=False) ANSWER = YES }}} In the bad case it looks like {{{ Considering inlining: $cccataList_a1Bv arg infos [ValueArg, ValueArg, ValueArg, ValueArg] interesting continuation RuleArgCtxt some_benefit True is exp: True is work-free: True guidance ALWAYS_IF(arity=4,unsat_ok=False,boring_ok=False) ANSWER = YES }}} Notice the continuation and arg infos are different for the two cases. The first case seems to be eta expanded? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 11:06:16 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 11:06:16 -0000 Subject: [GHC] #16344: GHC infers over-polymorphic kinds Message-ID: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> #16344: GHC infers over-polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider {{{ data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) }}} GHC accepts this ''even though it uses polymorphic recursion''. But it shouldn't -- we simply do not have reliable way to infer most general types in the presence of polymorphic recursion. In more detail, in `getInitialKinds`, GHC chooses this (bogus) "monomorphic" kind for T: {{{ T :: forall (ka :: kappa1) -> ak -> kappa2 -> Type }}} where `kappa1` and `kappa1` are unification variables. Then it kind- checks the data constructor declaration, given this mono-kind -- and succeeds! But this is extremely fragile. At call-sites of T we are going to instantiate T's kind. But what if `kappa2` is (somewhere, somehow) late unified wtih `ka`. Then, when instantiating T's kind with `ka := blah`we should get `blah -> blha -> Type`. So how it instantiates will vary depending on what we konw about `kappa2`. No no no. The initial monomorphic kind of T (returned by `getInitialKinds`, and used when checking the recursive RHSs) should be {{{ T :: kappa1 -> kappa2 -> kappa3 -> Type }}} Then indeed this program will be rejected, but so be it. Consider {{{ data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) }}} GHC accepts this ''even though it uses polymorphic recursion''. But it shouldn't -- we simply do not have reliable way to infer most general types in the presence of polymorphic recursion. In more detail, in `getInitialKinds`, GHC decides this "monomorphic" kind for T: {{{ T :: forall (ka :: kappa1) -> ka -> kappa2 -> Type }}} where `kappa1` and `kappa1` are unification variables. Then it kind- checks the data constructor declaration, given this mono-kind -- and succeeds! But this is extremely fragile. At call-sites of T we are going to instantiate T's kind. But what if `kappa2` is (somewhere, somehow) late unified wtih `ka`. Then, when instantiating T's kind with `ka := blah` we might get `blah -> blah -> Type` or `blah -> kappa2 -> Type`, depending on whether `kappa2 := ka` has happened yet. No no no. The initial monomorphic kind of T (returned by `getInitialKinds`, and used when checking the recursive RHSs) should be {{{ T :: kappa1 -> kappa2 -> kappa3 -> Type }}} Then indeed this program will be rejected, but so be it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 12:20:00 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 12:20:00 -0000 Subject: [GHC] #16345: Duplicated allocation Message-ID: <046.2f1108aa9e9bf61e4860878414b09c28@haskell.org> #16345: Duplicated allocation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider this {{{ x = reverse "hello" y = x `seq` Just True f p = y `seq` (p, y) }}} You'd expect that we'd end up iwth {{{ f = \p -> case y of DEFAULT -> (p, y) }}} or just possibly {{{ f = \p -> case x of DEFAULT -> (p, y) }}} But we don't. We get {{{ Foo3.f = \ (@ a_a13D) (p_a13b [Occ=Once] :: a_a13D) -> case Foo3.x of { __DEFAULT -> (p_a13b, Just @ Bool True) } }}} Yikes. Look at that completely-wasted `Just True` allocation, which will happen in every call to `f`. There's nothing special about the top level here; this could happen for nested bindings too. The culprit is this code in `Simplify`: {{{ rebuildCase env scrut case_bndr alts cont | Just (wfloats, con, ty_args, other_args) <- exprIsConApp_maybe (getUnfoldingInRuleMatch env) scrut = do { case findAlt (DataAlt con) alts of Nothing -> missingAlt env case_bndr alts cont Just (DEFAULT, bs, rhs) -> let con_app = Var (dataConWorkId con) `mkTyApps` ty_args `mkApps` other_args in simple_rhs wfloats con_app bs rhs Just (_, bs, rhs) -> knownCon env scrut wfloats con ty_args other_args case_bndr bs rhs cont } }}} If we try to simplify {{{ case y of y' { DEFAULT -> (p, y') } }}} then `exprIsConApp_maybe` succeeds (with a floated case on `x`), effectively inlining `y` bodily, and we transform to {{{ case x of DEFAULT -> let y' = Just True in blah }}} Sigh. If making `exprIsConApp_maybe` to fire requires duplicating an allocation (here by inlining `y`), then perhaps we only want this `rebuildCase` transformation to fire if the case-binder `y'` is dead. What happens in the `knownCon` case? {{{ f = \p -> case y of y' Just t -> (y',p) Nothing -> (p,p) }}} Here we correctly inline `y`, cancel the `Just` and end up with {{{ f = \p -> case x of DEFAUT -> let y' = y in Just p }}} Where did that `y' = y` binding come from? Ah... the clever `bind_case_bndr` in `knownCon`. We should do something like this in the default case too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 12:20:22 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 12:20:22 -0000 Subject: [GHC] #16345: Duplicated allocation in case-of-known-constructor (was: Duplicated allocation) In-Reply-To: <046.2f1108aa9e9bf61e4860878414b09c28@haskell.org> References: <046.2f1108aa9e9bf61e4860878414b09c28@haskell.org> Message-ID: <061.3033db035b6e790e96fd2de2115b4797@haskell.org> #16345: Duplicated allocation in case-of-known-constructor -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 12:32:35 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 12:32:35 -0000 Subject: [GHC] #16344: GHC infers over-polymorphic kinds In-Reply-To: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> References: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> Message-ID: <061.79e73c20b2c62a14af3f02b338517b72@haskell.org> #16344: GHC infers over-polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by aspiwack): * cc: aspiwack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 14:00:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 14:00:03 -0000 Subject: [GHC] #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId Message-ID: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- I'm getting this Lint error when validating 'master', when compiling `PrelNames.hs` with the stage1 compiler. {{{ *** Core Lint errors : in result of Simplifier *** : warning: In the expression: Name (External modu_a3Ct) (OccName dt_X6Ya dt_X6Yc) dt2_a6Yf noSrcSpan Occurrence is GlobalId, but binding is LocalId noSrcSpan :: SrcSpan [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=True, Expandable=False, Guidance=IF_ARGS [] 10 0}] }}} How come this got past CI? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 14:10:21 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 14:10:21 -0000 Subject: [GHC] #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> References: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> Message-ID: <061.4d628b4efe80116f622861775e2e6cc1@haskell.org> #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Does the test program from #16288 work on your ghc-stage1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 14:37:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 14:37:03 -0000 Subject: [GHC] #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> References: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> Message-ID: <061.adf56e24002e56c7dc13a2e76473db22@haskell.org> #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes I think so. But the real issue is this in `SimplEnv.refineFromInScope`: {{{ refineFromInScope :: InScopeSet -> Var -> Var refineFromInScope in_scope v | isLocalId v = case lookupInScope in_scope v of Just v' -> v' Nothing -> WARN( True, ppr v ) v -- This is an error! | otherwise = v }}} Notice that we don't look `GlobalId`s up in the in-scope set. Yet that is the mechanism that ensures that in a situation like {{{ let f_2dr[LclId] = blah in ...M.f_2df[GblId]... }}} (which has a local binding for a `GlobalId`), we transform to {{{ let f_2dr[LclId] = blah in ...f_2df[LclId]... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 14:39:39 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 14:39:39 -0000 Subject: [GHC] #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> References: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> Message-ID: <061.d17c40e93fdb992654e6e74bcd71bc38@haskell.org> #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Changing the definition of `refineFromInScope` to {{{ | isLocalId v = case lookupInScope in_scope v of Just v' -> v' Nothing -> WARN( True, ppr v ) v -- This is an error! | otherwise = case lookupInScope in_scope v of Just v' -> v' Nothing -> v }}} fixes the panic. (Although in a very unsatisfactory way, because we thereby look up ''every'' `GlobalId`.) But we just get another panic! This time in the `cabal` library, module `Distribution.Types.ComponentRequestedSpec`: {{{ *** Core Lint errors : in result of Simplifier *** : warning: [in body of lambda with binder w5_afxc :: Success ...snipped... Out of scope: $fSumSizeM2_r14m :: Word64 [LclId] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 14:51:35 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 14:51:35 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.e36ebfc853f8b300acd257d22d002018@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 14119 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): After reading comment:13, I'm left wondering about how this idea would work in practice. I've wanted to define instances like these before: {{{#!hs type family Sing :: k -> Type type instance Sing @Type = TypeRep type instance Sing @(Sing a) = Sing }}} Currently, GHC prevents me from writing the `Sing @(Sing a)` instance since its argument mentions the `Sing` type family. If I understand the plan in comment:13, then GHC would turn this instance into something that looks roughly like this: {{{#!hs type instance (x ~ Sing a) => Sing @x = Sing }}} However, this might be a problem. We have both a `Sing @x` and a `Sing @Type` instance defined—wouldn't these instances conflict? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 14:52:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 14:52:03 -0000 Subject: [GHC] #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> References: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> Message-ID: <061.96a212c7fdfec407d720d27a8d77a89b@haskell.org> #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's why the second crash happens. We start with {{{ case M.f_2dr[GblId] of f' { W# y -> let f_2dr[LclId] = f' in case M.f_2dr[GblId] of { W# z -> blah }}} (All this is in the body of `$s$fGBinaryGetTYPE:+:1_sfOT` in `Distribution.Types.ComponentRequestedSpec`.) Then * It turns out that `M.f_2dr` is a HNF so the first case can vanish. We extend the substitution with `f' :-> M.f_2dr[GblId]`. * We simplify the RHS of the `let` to get `M.f_2dr[GblId]` * We simplify the let-binder. It's not in scope, so we don't mess with its unique, and we extend the in-scope set with `M.f_2dr[LclId]`. * Now post-inline-unconditionally fires, so we extend the substitution with `f_2dr :-> M.f_2dr[GblId]` * Now at the occurrence of `M.f_2dr[GblId]` we find it in the substitution, mapping to, well, `M.f_2dr[GblId]`. * Then we look that up in the in-scope set, and get `M.f_2dr[LclId]` * And that is not in scope. What a mess. My conclusion: it's a total disaster to have a local binding for a `LocalId` that shares a unique with a `GlobalId`. We have multiple hacks to avoid trouble, and they don't even work. Let's stop doing it. See #16296. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 18:21:48 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 18:21:48 -0000 Subject: [GHC] #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal In-Reply-To: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> References: <050.c56090d171a7c34c5a8ca0a03b383828@haskell.org> Message-ID: <065.dbfe74a6dcce1d97648d78a20c9e6994@haskell.org> #14030: Implement the "Derive Lift instances for data types in template-haskell" proposal -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Template Haskell | Version: 8.3 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 19:12:11 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 19:12:11 -0000 Subject: [GHC] #16279: Lexer: Alternate Layout Rule injects actual not virtual braces In-Reply-To: <044.73378e875f9cb441e9847c7b1258c533@haskell.org> References: <044.73378e875f9cb441e9847c7b1258c533@haskell.org> Message-ID: <059.732356f823deb26438d0c85cbc2613b2@haskell.org> #16279: Lexer: Alternate Layout Rule injects actual not virtual braces -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: #13807 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/284 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/284 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 19:14:17 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 19:14:17 -0000 Subject: [GHC] #16236: API Annotations: AnnAt disconnected for TYPEAPP In-Reply-To: <044.6e93fb3fdb6147571aa02f22e88db26f@haskell.org> References: <044.6e93fb3fdb6147571aa02f22e88db26f@haskell.org> Message-ID: <059.1885a5a325f6dad1b868a19510038932@haskell.org> #16236: API Annotations: AnnAt disconnected for TYPEAPP -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/284 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/284 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 19:14:33 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 19:14:33 -0000 Subject: [GHC] #16230: API Annotations: more explicit foralls fixup In-Reply-To: <044.42a15601640ae89d68991169845c06ab@haskell.org> References: <044.42a15601640ae89d68991169845c06ab@haskell.org> Message-ID: <059.dadb379a1ee4d93ee90fef072ca80d18@haskell.org> #16230: API Annotations: more explicit foralls fixup -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/284 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/284 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 19:16:44 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 19:16:44 -0000 Subject: [GHC] #16347: GHC HEAD regression: piResultTys1 Message-ID: <050.5658c2f45fbb3a51a60e5b0dd63cbfb9@haskell.org> #16347: GHC HEAD regression: piResultTys1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.7 (Type checker) | 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: -------------------------------------+------------------------------------- The following program typechecks on GHC 8.0.2 through 8.6.3, but panics on HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy data T f :: f Type -> Type where MkT :: T f a }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20190219 for x86_64-unknown-linux): piResultTys1 k_a10k[tau:1] [*] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1063:5 in ghc:Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 19:22:58 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 19:22:58 -0000 Subject: [GHC] #15549: Core Lint error with EmptyCase In-Reply-To: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> References: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> Message-ID: <065.62a4f312cc9f0667a20e03c6596824cb@haskell.org> #15549: Core Lint error with EmptyCase -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T15549[ab] Blocked By: | Blocking: Related Tickets: #14729 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/208 -------------------------------------+------------------------------------- Comment (by bgamari): For what it's worth it seems to apply cleanly to `ghc-8.8`. Let's try merging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 19:30:51 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 19:30:51 -0000 Subject: [GHC] #16141: StrictData and TypeFamilies regression In-Reply-To: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> References: <050.8aa11c72012f62acf6cc71e981d87c2b@haskell.org> Message-ID: <065.94bff18ef56e359dd8c1f9cef4750de5@haskell.org> #16141: StrictData and TypeFamilies regression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T16141 Blocked By: | Blocking: Related Tickets: #16191 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/88 -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge * milestone: 8.6.4 => 8.8.1 Comment: Also needs merging for 8.8.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 19:31:58 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 19:31:58 -0000 Subject: [GHC] #16347: GHC HEAD regression: piResultTys1 In-Reply-To: <050.5658c2f45fbb3a51a60e5b0dd63cbfb9@haskell.org> References: <050.5658c2f45fbb3a51a60e5b0dd63cbfb9@haskell.org> Message-ID: <065.418d1df9f4c8f0d5ee4d9633e8e98a9a@haskell.org> #16347: GHC HEAD regression: piResultTys1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.7 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: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > The following program typechecks on GHC 8.0.2 through 8.6.3, but panics > on HEAD: > > {{{#!hs > {-# LANGUAGE GADTs #-} > {-# LANGUAGE TypeInType #-} > module Bug where > > import Data.Kind > import Data.Proxy > > data T f :: f Type -> Type where > MkT :: T f a > }}} > {{{ > $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs > [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.7.20190219 for x86_64-unknown-linux): > piResultTys1 > k_a10k[tau:1] > [*] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in > ghc:Outputable > pprPanic, called at compiler/types/Type.hs:1063:5 in ghc:Type > }}} New description: The following program typechecks on GHC 8.0.2 through 8.6.3, but panics on HEAD: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data T f :: f Type -> Type where MkT :: T f a }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20190219 for x86_64-unknown-linux): piResultTys1 k_a10k[tau:1] [*] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1063:5 in ghc:Type }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 19:54:40 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 19:54:40 -0000 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs Message-ID: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> #16348: GHC HEAD regression: tyConAppArgs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program compiles (with `-O`) on GHC 7.0.4 through 8.6.3, but panics on HEAD: {{{#!hs {-# LANGUAGE DeriveFunctor #-} module Bug where data V2 a = V2 !a !a deriving Functor (*^) :: (Functor f, Num a) => a -> f a -> f a (*^) a = fmap (a*) (*!!) :: (Functor m, Functor r, Num a) => a -> m (r a) -> m (r a) s *!! m = fmap (s *^) m type M22 a = V2 (V2 a) det22 :: Num a => M22 a -> a det22 (V2 (V2 a b) (V2 c d)) = a * d - b * c inv22 :: Fractional a => M22 a -> M22 a inv22 m@(V2 (V2 a b) (V2 c d)) = (1 / det) *!! V2 (V2 d (-b)) (V2 (-c) a) where det = det22 m }}} {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs -O [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20190219 for x86_64-unknown-linux): tyConAppArgs a_a1FK Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1183:50 in ghc:Type }}} Note that this panic does not occur if `V2` is defined without `!`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 19:55:00 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 19:55:00 -0000 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> Message-ID: <065.34d74aae867b06f0e18aa34703556c24@haskell.org> #16348: GHC HEAD regression: tyConAppArgs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 21:46:25 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 21:46:25 -0000 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> Message-ID: <065.d6a0215610b2cdb5bfc389f6d2005ee1@haskell.org> #16348: GHC HEAD regression: tyConAppArgs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.7 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 monoidal): This was introduced by my commit 7833cf407d1f6 (Look through newtype wrappers). I don't know what's going on yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 22:53:07 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 22:53:07 -0000 Subject: [GHC] #16347: GHC HEAD regression: piResultTys1 In-Reply-To: <050.5658c2f45fbb3a51a60e5b0dd63cbfb9@haskell.org> References: <050.5658c2f45fbb3a51a60e5b0dd63cbfb9@haskell.org> Message-ID: <065.2ef56be04a7a41eb8521edea96ebd8f3@haskell.org> #16347: GHC HEAD regression: piResultTys1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.7 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: This regression was introduced in commit 682783828275cca5fd8bf5be5b52054c75e0e22c (`Make a smart mkAppTyM`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 20 23:45:09 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 20 Feb 2019 23:45:09 -0000 Subject: [GHC] #16271: Building stage1:lib:text target is not robust In-Reply-To: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> References: <049.bed780ccc9c347637aa9906ad9c27576@haskell.org> Message-ID: <064.d136153f9e280f8dc26019a42488cb11@haskell.org> #16271: Building stage1:lib:text target is not robust -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * status: new => closed * resolution: => fixed Comment: Fixed by this commit: https://gitlab.haskell.org/ghc/ghc/commit/1dad4fc27ea128a11ba0077f459494c2a1ca0d5c @mpickering: Please reopen if closed incorrectly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 06:52:25 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 06:52:25 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.9d0ebf15abdb0d4c0e44e7f0e741b8e7@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Sorry if I'm talking about a different bug, but I think this may be a regression. The original reproducer is rejected by GHC 8.6.3 too, but if you build Cabal (the library) with GHC HEAD at some point you get this error: {{{ $ head.hackage.sh init-local $ cabal new-build --enable-benchmarks --enable-tests --allow-newer=base ,template-haskell,tagged ... [211 of 220] Compiling Distribution.Simple.PreProcess ( Distribution/Simple/PreProcess.hs, dist/build/Distribution/Simple/PreProcess.o ) Distribution/Simple/PreProcess.hs:697:24: error: • Illegal qualified type: GHC.Stack.Types.HasCallStack => ghc-prim-0.5.3:GHC.Types.IO [FilePath] GHC doesn't yet support impredicative polymorphism • In the expansion of type synonym ‘WithCallStack’ In the expansion of type synonym ‘IO’ In the expansion of type synonym ‘PreProcessorExtras’ | 697 | knownExtrasHandlers :: [ PreProcessorExtras ] | ^^^^^^^^^^^^^^^^^^^^^^ cabal: Failed to build Cabal-2.4.1.0 (which is required by exe:ppsh from pretty-show-1.6.16 and cabal-install-2.5.0.0). See the build log above for details. }}} This builds fine with GHC 8.6.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 10:27:58 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 10:27:58 -0000 Subject: [GHC] #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes In-Reply-To: <053.4084568d524ce1292251a51835a53ec6@haskell.org> References: <053.4084568d524ce1292251a51835a53ec6@haskell.org> Message-ID: <068.182106699aa9f1f16020e0a2ed8f5990@haskell.org> #16140: Cannot create type synonym for quantified constraint without ImpredicativeTypes -------------------------------------+------------------------------------- Reporter: Ashley Yakeley | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | QuantifiedConstraints, | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This has nothing to do with this ticket, but rather #16059. Moreover, this is expected behavior—the fix for #16059 revealed an illegal use of impredicativity in `Cabal-2.4.1.0` that previously went unnoticed (see the discussion starting at https://ghc.haskell.org/trac/ghc/ticket/16059#comment:14). The current version of `Cabal` that is bundled with GHC HEAD, `Cabal-2.5.0.0`, fixes this issue. **tl;dr** You want to use `Cabal-2.5.0.0`, not `Cabal-2.4.1.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 10:42:57 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 10:42:57 -0000 Subject: [GHC] #16339: Cannot put (.) or (!) type operators into an export list In-Reply-To: <050.512bf1bda3242ed4564080d5f3cf14ba@haskell.org> References: <050.512bf1bda3242ed4564080d5f3cf14ba@haskell.org> Message-ID: <065.4b509ebd6eab9dd8c95099c4e2405ee1@haskell.org> #16339: Cannot put (.) or (!) type operators into an export list -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | parser/should_compile/T16339 Blocked By: | Blocking: Related Tickets: #15457, #16311 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/403 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge * testcase: => parser/should_compile/T16339 * related: => #15457, #16311 * milestone: => 8.8.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/2f4af71e73ac3b59f4faba5bf1b25774b1008898 2f4af71e73ac3b59f4faba5bf1b25774b1008898] and [https://gitlab.haskell.org/ghc/ghc/commit/e204431e5a5e2fd16da52b04bda2798f16c51344 e204431e5a5e2fd16da52b04bda2798f16c51344]. These commits should be merged to GHC 8.8 alongside commit [https://gitlab.haskell.org/ghc/ghc/commit/887454d8889ca5dbba70425de41d97939cb9ac60 887454d8889ca5dbba70425de41d97939cb9ac60] from #16311. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 10:56:37 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 10:56:37 -0000 Subject: [GHC] #16349: Nondeterministic T3424 timeouts on CI Message-ID: <050.2a09de2550baf6c7c958ab823c4e0558@haskell.org> #16349: Nondeterministic T3424 timeouts on CI -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.9 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 `T3424` test suite occasionally times out on CI, forcing me to restart builds to get a green build status. Here is [https://ghc- gitlab.s3.amazonaws.com/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b/2019_02_21/31580/50071/job.log ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190221T105115Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190221 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=521f4993a8af6215a34603cb8dfb26f10e3f2a335229227e65b92aa4ced557e9 one example] from a `validate-x86_64-linux-deb9-unreg` run: {{{ Timeout happened...killed process "cd "rts/T3424.run" && "/builds/ghc/ghc/inplace/bin/ghc-stage2" -o T3424 T3424.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -optc-fno-builtin -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output "... Compile failed (exit code 99) errors were: [1 of 1] Compiling Main ( T3424.hs, T3424.o ) *** unexpected failure for T3424(normal) Unexpected results from: TEST="T3424" SUMMARY for test run started at Thu Feb 21 05:18:04 2019 UTC 1:15:50 spent to go through 6839 total tests, which gave rise to 21103 test cases, of which 13986 were skipped 38 had missing libraries 6977 expected passes 101 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: rts/T3424.run T3424 [exit code non-0] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 10:57:28 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 10:57:28 -0000 Subject: [GHC] #16349: Nondeterministic T3424 timeouts on CI In-Reply-To: <050.2a09de2550baf6c7c958ab823c4e0558@haskell.org> References: <050.2a09de2550baf6c7c958ab823c4e0558@haskell.org> Message-ID: <065.8236ca930364b175dbdf8d1ee2cf7fe0@haskell.org> #16349: Nondeterministic T3424 timeouts on CI -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: Old description: > The `T3424` test suite occasionally times out on CI, forcing me to > restart builds to get a green build status. Here is [https://ghc- > gitlab.s3.amazonaws.com/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b/2019_02_21/31580/50071/job.log > ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- > disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190221T105115Z&X-Amz- > Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190221 > /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- > Signature=521f4993a8af6215a34603cb8dfb26f10e3f2a335229227e65b92aa4ced557e9 > one example] from a `validate-x86_64-linux-deb9-unreg` run: > > {{{ > Timeout happened...killed process "cd "rts/T3424.run" && > "/builds/ghc/ghc/inplace/bin/ghc-stage2" -o T3424 T3424.hs -dcore-lint > -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -optc-fno-builtin > -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- > color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output > "... > > Compile failed (exit code 99) errors were: > [1 of 1] Compiling Main ( T3424.hs, T3424.o ) > > *** unexpected failure for T3424(normal) > > > > Unexpected results from: > TEST="T3424" > > SUMMARY for test run started at Thu Feb 21 05:18:04 2019 UTC > 1:15:50 spent to go through > 6839 total tests, which gave rise to > 21103 test cases, of which > 13986 were skipped > > 38 had missing libraries > 6977 expected passes > 101 expected failures > > 0 caused framework failures > 0 caused framework warnings > 0 unexpected passes > 1 unexpected failures > 0 unexpected stat failures > > Unexpected failures: > rts/T3424.run T3424 [exit code non-0] (normal) > }}} New description: The `T3424` test case occasionally times out on CI, forcing me to restart builds to get a green build status. Here is [https://ghc- gitlab.s3.amazonaws.com/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b/2019_02_21/31580/50071/job.log ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190221T105115Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190221 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=521f4993a8af6215a34603cb8dfb26f10e3f2a335229227e65b92aa4ced557e9 one example] from a `validate-x86_64-linux-deb9-unreg` run: {{{ Timeout happened...killed process "cd "rts/T3424.run" && "/builds/ghc/ghc/inplace/bin/ghc-stage2" -o T3424 T3424.hs -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -optc-fno-builtin -fno- warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output "... Compile failed (exit code 99) errors were: [1 of 1] Compiling Main ( T3424.hs, T3424.o ) *** unexpected failure for T3424(normal) Unexpected results from: TEST="T3424" SUMMARY for test run started at Thu Feb 21 05:18:04 2019 UTC 1:15:50 spent to go through 6839 total tests, which gave rise to 21103 test cases, of which 13986 were skipped 38 had missing libraries 6977 expected passes 101 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: rts/T3424.run T3424 [exit code non-0] (normal) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 10:59:42 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 10:59:42 -0000 Subject: [GHC] #16350: Nondeterministic T5559 failures on CI Message-ID: <050.9b58e539362fa36351f44a14284fd7e8@haskell.org> #16350: Nondeterministic T5559 failures on CI -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.9 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 `T5559` test case occasionally fails on CI, forcing me to restart builds to get a green build status. Here is [https://ghc- gitlab.s3.amazonaws.com/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b/2019_02_21/31578/49824/job.log ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190221T104600Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190221 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=4cda8d47d000a69a39765a5c141f1e33a610992f1f8ea60da83c4ec6eaca42d8 one example] from a `validate-x86_64-linux-fedora27` run: {{{ "gs" -dNODISPLAY -dBATCH -dQUIET -dNOPAUSE "profiling/should_run/T5559.run/T5559.ps" hp2ps output for T5559is not valid PostScript *** unexpected failure for T5559(profasm) SUMMARY for test run started at Thu Feb 21 00:32:08 2019 UTC 0:44:16 spent to go through 6839 total tests, which gave rise to 26523 test cases, of which 19210 were skipped 42 had missing libraries 7178 expected passes 92 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: profiling/should_run/T5559.run T5559 [bad heap profile] (profasm) }}} Aside from the nondeterministic test failure, this also reveals a minor bug: it prints `T5559is not valid PostScript`, which should probably be `T5559 is not valid PostScript` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 11:11:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 11:11:38 -0000 Subject: [GHC] #16339: Cannot put (.) or (!) type operators into an export list In-Reply-To: <050.512bf1bda3242ed4564080d5f3cf14ba@haskell.org> References: <050.512bf1bda3242ed4564080d5f3cf14ba@haskell.org> Message-ID: <065.692695c4686426988f8f1535f9691099@haskell.org> #16339: Cannot put (.) or (!) type operators into an export list -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | parser/should_compile/T16339 Blocked By: | Blocking: Related Tickets: #15457, #16311 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/403 -------------------------------------+------------------------------------- Comment (by int-index): Note that the issue is fixed by 2f4af71e73ac3b59f4faba5bf1b25774b1008898 alone, which is why I left e204431e5a5e2fd16da52b04bda2798f16c51344 as a separate commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 11:31:31 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 11:31:31 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating In-Reply-To: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> References: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> Message-ID: <065.8ee957cf81b494adec51a56bf3b05bb9@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14268 | Blocking: Related Tickets: #7873, #15474 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): https://gitlab.haskell.org/ghc/ghc/merge_requests/361 makes `reportFloatingKvs` obsolete, but we might want to restore it to fix this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 11:51:24 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 11:51:24 -0000 Subject: [GHC] #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> References: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> Message-ID: <061.d3c4c524630a861f3ce101b77c4dda35@haskell.org> #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Since this kills validate, I have a quick-fix in flight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 11:52:13 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 11:52:13 -0000 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> Message-ID: <065.b743303fadfc4ccd23ee1088016e42fb@haskell.org> #16348: GHC HEAD regression: tyConAppArgs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah. I see what is happening. Fix en route. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 11:53:22 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 11:53:22 -0000 Subject: [GHC] #16347: GHC HEAD regression: piResultTys1 In-Reply-To: <050.5658c2f45fbb3a51a60e5b0dd63cbfb9@haskell.org> References: <050.5658c2f45fbb3a51a60e5b0dd63cbfb9@haskell.org> Message-ID: <065.465f7c2b1987dd77b540d2623b74c344@haskell.org> #16347: GHC HEAD regression: piResultTys1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.7 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 simonpj): Interestingly this is a consequence of the broken-ness described in #16344. Fixing the latter fixes this ticket too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 12:10:19 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 12:10:19 -0000 Subject: [GHC] #15227: Add PrelRules for par# In-Reply-To: <045.f292885fced757ba9c18aa7457f6b1f1@haskell.org> References: <045.f292885fced757ba9c18aa7457f6b1f1@haskell.org> Message-ID: <060.7b0ed9de5a35f27396de2fbe4f5010fb@haskell.org> #15227: Add PrelRules for par# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => fixed Comment: `par#` is now deprecated, closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 13:27:21 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 13:27:21 -0000 Subject: [GHC] #16344: GHC infers over-polymorphic kinds In-Reply-To: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> References: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> Message-ID: <061.7f15308f3bfc1ee8eb2f20f7670435f6@haskell.org> #16344: GHC infers over-polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider > {{{ > data T ka (a::ka) b = MkT (T Type Int Bool) > (T (Type -> Type) Maybe Bool) > }}} > GHC accepts this ''even though it uses polymorphic recursion''. But it > shouldn't -- we simply do not have reliable way to infer most general > types in the presence of polymorphic recursion. > > In more detail, in `getInitialKinds`, GHC chooses this (bogus) > "monomorphic" kind for T: > {{{ > T :: forall (ka :: kappa1) -> ak -> kappa2 -> Type > }}} > where `kappa1` and `kappa1` are unification variables. Then it kind- > checks the data constructor declaration, given this mono-kind -- and > succeeds! > > But this is extremely fragile. At call-sites of T we are going to > instantiate T's kind. But what if `kappa2` is > (somewhere, somehow) late unified wtih `ka`. Then, when instantiating > T's kind with `ka := blah`we should get > `blah -> blha -> Type`. So how it instantiates will vary depending on > what we konw about `kappa2`. > > No no no. The initial monomorphic kind of T (returned by > `getInitialKinds`, and used when checking the recursive RHSs) > should be > {{{ > T :: kappa1 -> kappa2 -> kappa3 -> Type > }}} > Then indeed this program will be rejected, but so be it. > Consider > {{{ > data T ka (a::ka) b = MkT (T Type Int Bool) > (T (Type -> Type) Maybe Bool) > }}} > GHC accepts this ''even though it uses polymorphic recursion''. But it > shouldn't -- we simply do not have reliable way to infer most general > types in the presence of polymorphic recursion. > > In more detail, in `getInitialKinds`, GHC decides this "monomorphic" kind > for T: > {{{ > T :: forall (ka :: kappa1) -> ka -> kappa2 -> Type > }}} > where `kappa1` and `kappa1` are unification variables. Then it kind- > checks the data constructor declaration, given this mono-kind -- and > succeeds! > > But this is extremely fragile. At call-sites of T we are going to > instantiate T's kind. But what if `kappa2` is > (somewhere, somehow) late unified wtih `ka`. Then, when instantiating > T's kind with `ka := blah` we might get > `blah -> blah -> Type` or `blah -> kappa2 -> Type`, depending on whether > `kappa2 := ka` has happened yet. > > No no no. The initial monomorphic kind of T (returned by > `getInitialKinds`, and used when checking the recursive RHSs) > should be > {{{ > T :: kappa1 -> kappa2 -> kappa3 -> Type > }}} > Then indeed this program will be rejected, but so be it. New description: Consider {{{ data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) }}} GHC accepts this ''even though it uses polymorphic recursion''. But it shouldn't -- we simply do not have reliable way to infer most general types in the presence of polymorphic recursion. In more detail, in `getInitialKinds`, GHC chooses this (bogus) "monomorphic" kind for T: {{{ T :: forall (ka :: kappa1) -> ka -> kappa2 -> Type }}} where `kappa1` and `kappa1` are unification variables. Then it kind- checks the data constructor declaration, given this mono-kind -- and succeeds! But this is extremely fragile. At call-sites of T we are going to instantiate T's kind. But what if `kappa2` is (somewhere, somehow) late unified wtih `ka`. Then, when instantiating T's kind with `ka := blah`we should get `blah -> blha -> Type`. So how it instantiates will vary depending on what we konw about `kappa2`. No no no. The initial monomorphic kind of T (returned by `getInitialKinds`, and used when checking the recursive RHSs) should be {{{ T :: kappa1 -> kappa2 -> kappa3 -> Type }}} Then indeed this program will be rejected, but so be it. Consider {{{ data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) }}} GHC accepts this ''even though it uses polymorphic recursion''. But it shouldn't -- we simply do not have reliable way to infer most general types in the presence of polymorphic recursion. In more detail, in `getInitialKinds`, GHC decides this "monomorphic" kind for T: {{{ T :: forall (ka :: kappa1) -> ka -> kappa2 -> Type }}} where `kappa1` and `kappa1` are unification variables. Then it kind- checks the data constructor declaration, given this mono-kind -- and succeeds! But this is extremely fragile. At call-sites of T we are going to instantiate T's kind. But what if `kappa2` is (somewhere, somehow) late unified wtih `ka`. Then, when instantiating T's kind with `ka := blah` we might get `blah -> blah -> Type` or `blah -> kappa2 -> Type`, depending on whether `kappa2 := ka` has happened yet. No no no. The initial monomorphic kind of T (returned by `getInitialKinds`, and used when checking the recursive RHSs) should be {{{ T :: kappa1 -> kappa2 -> kappa3 -> Type }}} Then indeed this program will be rejected, but so be it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 14:14:31 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 14:14:31 -0000 Subject: [GHC] #16344: GHC infers over-polymorphic kinds In-Reply-To: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> References: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> Message-ID: <061.eb79c34bb89e8e512ad38a6a25b5a4d4@haskell.org> #16344: GHC infers over-polymorphic kinds -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon has proposed a fix: In TcHsType, we find this, under `kcLHsQTyVars_NonCusk`: {{{#!hs mk_tc_binder :: LHsTyVarBndr GhcRn -> TyVar -> TyConBinder -- See Note [Dependent LHsQTyVars] mk_tc_binder hs_tv tv | hsLTyVarName hs_tv `elemNameSet` dep_names = mkNamedTyConBinder Required tv | otherwise = mkAnonTyConBinder tv }}} Simon suggests that changing it to this fixes the bug: {{{#!hs mk_tc_binder :: LHsTyVarBndr GhcRn -> TyVar -> TyConBinder mk_tc_binder hs_tv tv = mkAnonTyConBinder tv }}} Note: just deleting code! Indeed, this change fixes the example in the ticket because it effectively forgets that the first argument to `T` and the kind of the second are related. The program above is rejected right in the `kc` pass, because GHC tries to unify `ka` (a `TyVarTv`) with `Type` when looking at `Int` (never mind the `Maybe` it will see soon). Some examples are rejected in the `tc` pass though, like this: {{{#!hs data T2 ka (a::ka) = MkT2 (T2 Type a) }}} All fine during `kc`, but then once we produce `T2 :: forall ka -> ka -> Type`, failure in `tc`. While I'm never comfortable with non-CUSK types being rejected in the `tc` pass, I suppose it's OK. More problematically, this is never rejected at all: {{{#!hs data T3 ka (a::ka) = forall b. MkT3 (T3 Type b) }}} This is accepted outright. The `kc` pass assigns kind `ka` to `b` (fine) and then the `tc` pass instantiates `ka` to be `Type` and assigns kind `Type` to `b`. Also fine (it's type-correct), but `T3` is polymorphically recursive, and should be rejected. So, I claim that Simon's fix makes these examples (erroneously accepted polymorphic recursion) harder to find, but doesn't get rid of them all. Instead, a more involved fix would be to, for example, require that all of these types are immediately followed by `ka` at recursive occurrences -- anything other than a first argument of `ka` is rejected. I'm not sure how to achieve this elegantly (haven't thought about it), but that should stamp out the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 14:53:29 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 14:53:29 -0000 Subject: [GHC] #16221: Core Lint error with a data type In-Reply-To: <047.621c532512c5ecf6cb731ace319b51aa@haskell.org> References: <047.621c532512c5ecf6cb731ace319b51aa@haskell.org> Message-ID: <062.a844bd222a13136b2ae0f3f98c991a56@haskell.org> #16221: Core Lint error with a data type -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Turns out that #16342 is closely related -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 14:53:55 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 14:53:55 -0000 Subject: [GHC] #16342: Kind inference crash In-Reply-To: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> References: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> Message-ID: <061.f9e552669df21c75750f06bd364ece23@haskell.org> #16342: Kind inference crash -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by aspiwack): * cc: aspiwack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 18:20:03 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 18:20:03 -0000 Subject: [GHC] #16342: Kind inference crash In-Reply-To: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> References: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> Message-ID: <061.190b73ada55a82a2d2b9b716bd1d5cd8@haskell.org> #16342: Kind inference crash -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If we type-checked `HsDecl GhcRn` into `HsDecl GhcTc`, this would be much easier. Of course, classes get type-checked in pieces, so we would need multiple phase parameters there... In any case, I agree that reverse-mapping may be the cheap and cheerful solution here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 18:26:22 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 18:26:22 -0000 Subject: [GHC] #16347: GHC HEAD regression: piResultTys1 In-Reply-To: <050.5658c2f45fbb3a51a60e5b0dd63cbfb9@haskell.org> References: <050.5658c2f45fbb3a51a60e5b0dd63cbfb9@haskell.org> Message-ID: <065.abdbdd6e8029795100f1516612390521@haskell.org> #16347: GHC HEAD regression: piResultTys1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.7 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 goldfire): In conversation, Simon and I uncovered an unstated invariant: the `tyVarKind` of occurrences of a bound tyvar must share the `tyVarKind` of the binding site. In this example, that is not the case, because the kind of the tyvar contains a metavariable; it is zonked at an occurrence but not at the binding site. The fix is easy: do an extra zonk in `kcLHsQTyVars_NonCusk`, but fixing #16344 will also make this problem melt away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 21 18:31:54 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Feb 2019 18:31:54 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating In-Reply-To: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> References: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> Message-ID: <065.881d599ee8c77f081100fadce1475232@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14268 | Blocking: Related Tickets: #7873, #15474 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think this is subtly a different problem than `reportFloatingKvs`: that's all about user-written kind variables; this ticket is about overactive generalization. We ''could'' just say that `a` has kind `Any`. But I prefer rejecting the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 03:51:03 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 03:51:03 -0000 Subject: [GHC] #16351: Extend constant folding operations to bit manipulations Message-ID: <047.bc2e6dc04793dc8f16ec75e14049c559@haskell.org> #16351: Extend constant folding operations to bit manipulations -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- In #9136 GHC has greatly improved how it folds expressions for Int/Word when the basic arithmetic operations {{{+, -, *}}} are involved. I think that somewhat analogously this extend should be extended to binary manipulation operations. For example, consider the below snippet: {{{#!hs {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file -ddump-asm #-} module G (bar, baz) where import Data.Bits ((.|.)) import Data.Word (Word16) bar :: Word16 -> Int bar w = -9223372036854775808 .|. (281474976710656 .|. fromIntegral w) baz :: Word16 -> Int baz w = -9223372036854775808 + (281474976710656 + fromIntegral w) }}} Let's peek into the Core: {{{#!hs bar = \ (w_a1hX :: Word16) -> case w_a1hX of { GHC.Word.W16# x#_a1Lu -> GHC.Types.I# (GHC.Prim.orI# -9223372036854775808# (GHC.Prim.orI# 281474976710656# (GHC.Prim.word2Int# x#_a1Lu))) } baz = \ (w_a1sr :: Word16) -> case w_a1sr of { GHC.Word.W16# x#_a1Lu -> GHC.Types.I# (GHC.Prim.+# -9223090561878065152# (GHC.Prim.word2Int# x#_a1Lu)) } }}} Due to #9136, {{{bar}}} gets nicely folded away into a single addition. {{{baz}}} however is still in its "naive" form. The above example was extracted from an actual program where there may be long such chains of {{{orI#}}} and similar operations. I think it's worth pointing out that if we peek in the ASM, {{{baz}}} seems to get folded away eventually but I don't trust it to always happen properly at that level and I don't particularly fancy trawling through the ASM output every time. https://stackoverflow.com/a/45909278 has some laws we could use. I'm sure we could pick in LLVM source &c. too if we want to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 03:52:49 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 03:52:49 -0000 Subject: [GHC] #16351: Extend constant folding operations to bit manipulations In-Reply-To: <047.bc2e6dc04793dc8f16ec75e14049c559@haskell.org> References: <047.bc2e6dc04793dc8f16ec75e14049c559@haskell.org> Message-ID: <062.d7d75c8324bd249eea76765f04b9068c@haskell.org> #16351: Extend constant folding operations to bit manipulations -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Fuuzetsu: Old description: > In #9136 GHC has greatly improved how it folds expressions for Int/Word > when the basic arithmetic operations {{{+, -, *}}} are involved. > > I think that somewhat analogously this extend should be extended to > binary manipulation operations. For example, consider the below snippet: > > {{{#!hs > {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file -ddump-asm #-} > module G (bar, baz) where > > import Data.Bits ((.|.)) > import Data.Word (Word16) > > bar :: Word16 -> Int > bar w = -9223372036854775808 .|. (281474976710656 .|. fromIntegral w) > > baz :: Word16 -> Int > baz w = -9223372036854775808 + (281474976710656 + fromIntegral w) > }}} > > Let's peek into the Core: > {{{#!hs > bar > = \ (w_a1hX :: Word16) -> > case w_a1hX of { GHC.Word.W16# x#_a1Lu -> > GHC.Types.I# > (GHC.Prim.orI# > -9223372036854775808# > (GHC.Prim.orI# 281474976710656# (GHC.Prim.word2Int# x#_a1Lu))) > } > > baz > = \ (w_a1sr :: Word16) -> > case w_a1sr of { GHC.Word.W16# x#_a1Lu -> > GHC.Types.I# > (GHC.Prim.+# -9223090561878065152# (GHC.Prim.word2Int# x#_a1Lu)) > } > }}} > > Due to #9136, {{{bar}}} gets nicely folded away into a single addition. > {{{baz}}} however is still in its "naive" form. The above example was > extracted from an actual program where there may be long such chains of > {{{orI#}}} and similar operations. > > I think it's worth pointing out that if we peek in the ASM, {{{baz}}} > seems to get folded away eventually but I don't trust it to always happen > properly at that level and I don't particularly fancy trawling through > the ASM output every time. > > https://stackoverflow.com/a/45909278 has some laws we could use. I'm sure > we could pick in LLVM source &c. too if we want to. New description: In #9136 GHC has greatly improved how it folds expressions for Int/Word when the basic arithmetic operations {{{+, -, *}}} are involved. I think that somewhat analogously this should be extended to binary manipulation operations. For example, consider the below snippet: {{{#!hs {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file -ddump-asm #-} module G (bar, baz) where import Data.Bits ((.|.)) import Data.Word (Word16) bar :: Word16 -> Int bar w = -9223372036854775808 .|. (281474976710656 .|. fromIntegral w) baz :: Word16 -> Int baz w = -9223372036854775808 + (281474976710656 + fromIntegral w) }}} Let's peek into the Core: {{{#!hs bar = \ (w_a1hX :: Word16) -> case w_a1hX of { GHC.Word.W16# x#_a1Lu -> GHC.Types.I# (GHC.Prim.orI# -9223372036854775808# (GHC.Prim.orI# 281474976710656# (GHC.Prim.word2Int# x#_a1Lu))) } baz = \ (w_a1sr :: Word16) -> case w_a1sr of { GHC.Word.W16# x#_a1Lu -> GHC.Types.I# (GHC.Prim.+# -9223090561878065152# (GHC.Prim.word2Int# x#_a1Lu)) } }}} Due to #9136, {{{bar}}} gets nicely folded away into a single addition. {{{baz}}} however is still in its "naive" form. The above example was extracted from an actual program where there may be long such chains of {{{orI#}}} and similar operations. I think it's worth pointing out that if we peek in the ASM, {{{baz}}} seems to get folded away eventually but I don't trust it to always happen properly at that level and I don't particularly fancy trawling through the ASM output every time. https://stackoverflow.com/a/45909278 has some laws we could use. I'm sure we could pick in LLVM source &c. too if we want to. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 03:54:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 03:54:56 -0000 Subject: [GHC] #16351: Extend constant folding operations to bit manipulations In-Reply-To: <047.bc2e6dc04793dc8f16ec75e14049c559@haskell.org> References: <047.bc2e6dc04793dc8f16ec75e14049c559@haskell.org> Message-ID: <062.f3675f3ac65a5a21b0dae0c879170bc3@haskell.org> #16351: Extend constant folding operations to bit manipulations -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Fuuzetsu: Old description: > In #9136 GHC has greatly improved how it folds expressions for Int/Word > when the basic arithmetic operations {{{+, -, *}}} are involved. > > I think that somewhat analogously this should be extended to binary > manipulation operations. For example, consider the below snippet: > > {{{#!hs > {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file -ddump-asm #-} > module G (bar, baz) where > > import Data.Bits ((.|.)) > import Data.Word (Word16) > > bar :: Word16 -> Int > bar w = -9223372036854775808 .|. (281474976710656 .|. fromIntegral w) > > baz :: Word16 -> Int > baz w = -9223372036854775808 + (281474976710656 + fromIntegral w) > }}} > > Let's peek into the Core: > {{{#!hs > bar > = \ (w_a1hX :: Word16) -> > case w_a1hX of { GHC.Word.W16# x#_a1Lu -> > GHC.Types.I# > (GHC.Prim.orI# > -9223372036854775808# > (GHC.Prim.orI# 281474976710656# (GHC.Prim.word2Int# x#_a1Lu))) > } > > baz > = \ (w_a1sr :: Word16) -> > case w_a1sr of { GHC.Word.W16# x#_a1Lu -> > GHC.Types.I# > (GHC.Prim.+# -9223090561878065152# (GHC.Prim.word2Int# x#_a1Lu)) > } > }}} > > Due to #9136, {{{bar}}} gets nicely folded away into a single addition. > {{{baz}}} however is still in its "naive" form. The above example was > extracted from an actual program where there may be long such chains of > {{{orI#}}} and similar operations. > > I think it's worth pointing out that if we peek in the ASM, {{{baz}}} > seems to get folded away eventually but I don't trust it to always happen > properly at that level and I don't particularly fancy trawling through > the ASM output every time. > > https://stackoverflow.com/a/45909278 has some laws we could use. I'm sure > we could pick in LLVM source &c. too if we want to. New description: In #9136 GHC has greatly improved how it folds expressions for Int/Word when the basic arithmetic operations {{{+, -, *}}} are involved. I think that somewhat analogously this should be extended to binary manipulation operations. For example, consider the below snippet: {{{#!hs {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file -ddump-asm #-} module G (bar, baz) where import Data.Bits ((.|.)) import Data.Word (Word16) bar :: Word16 -> Int bar w = -9223372036854775808 .|. (281474976710656 .|. fromIntegral w) baz :: Word16 -> Int baz w = -9223372036854775808 + (281474976710656 + fromIntegral w) }}} Let's peek into the Core: {{{#!hs bar = \ (w_a1hX :: Word16) -> case w_a1hX of { GHC.Word.W16# x#_a1Lu -> GHC.Types.I# (GHC.Prim.orI# -9223372036854775808# (GHC.Prim.orI# 281474976710656# (GHC.Prim.word2Int# x#_a1Lu))) } baz = \ (w_a1sr :: Word16) -> case w_a1sr of { GHC.Word.W16# x#_a1Lu -> GHC.Types.I# (GHC.Prim.+# -9223090561878065152# (GHC.Prim.word2Int# x#_a1Lu)) } }}} Due to #9136, {{{bar}}} gets nicely folded away into a single addition. {{{baz}}} however is still in its "naive" form. The above example was extracted from an actual program where there may be long such chains of {{{orI#}}} and similar operations. I think it's worth pointing out that if we peek in the ASM, {{{baz}}} seems to get folded away eventually but I don't trust it to always happen properly at that level and I don't particularly fancy trawling through the ASM output every time. https://stackoverflow.com/a/45909278 has some laws we could use. I'm sure we could peek in LLVM source &c. too if we want to. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 05:57:50 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 05:57:50 -0000 Subject: [GHC] #16351: Extend constant folding operations to bit manipulations In-Reply-To: <047.bc2e6dc04793dc8f16ec75e14049c559@haskell.org> References: <047.bc2e6dc04793dc8f16ec75e14049c559@haskell.org> Message-ID: <062.8bbda1d9a7079dc0e4aceff1ea115a54@haskell.org> #16351: Extend constant folding operations to bit manipulations -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Fuuzetsu: Old description: > In #9136 GHC has greatly improved how it folds expressions for Int/Word > when the basic arithmetic operations {{{+, -, *}}} are involved. > > I think that somewhat analogously this should be extended to binary > manipulation operations. For example, consider the below snippet: > > {{{#!hs > {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file -ddump-asm #-} > module G (bar, baz) where > > import Data.Bits ((.|.)) > import Data.Word (Word16) > > bar :: Word16 -> Int > bar w = -9223372036854775808 .|. (281474976710656 .|. fromIntegral w) > > baz :: Word16 -> Int > baz w = -9223372036854775808 + (281474976710656 + fromIntegral w) > }}} > > Let's peek into the Core: > {{{#!hs > bar > = \ (w_a1hX :: Word16) -> > case w_a1hX of { GHC.Word.W16# x#_a1Lu -> > GHC.Types.I# > (GHC.Prim.orI# > -9223372036854775808# > (GHC.Prim.orI# 281474976710656# (GHC.Prim.word2Int# x#_a1Lu))) > } > > baz > = \ (w_a1sr :: Word16) -> > case w_a1sr of { GHC.Word.W16# x#_a1Lu -> > GHC.Types.I# > (GHC.Prim.+# -9223090561878065152# (GHC.Prim.word2Int# x#_a1Lu)) > } > }}} > > Due to #9136, {{{bar}}} gets nicely folded away into a single addition. > {{{baz}}} however is still in its "naive" form. The above example was > extracted from an actual program where there may be long such chains of > {{{orI#}}} and similar operations. > > I think it's worth pointing out that if we peek in the ASM, {{{baz}}} > seems to get folded away eventually but I don't trust it to always happen > properly at that level and I don't particularly fancy trawling through > the ASM output every time. > > https://stackoverflow.com/a/45909278 has some laws we could use. I'm sure > we could peek in LLVM source &c. too if we want to. New description: In #9136 GHC has greatly improved how it folds expressions for Int/Word when the basic arithmetic operations {{{+, -, *}}} are involved. I think that somewhat analogously this should be extended to binary manipulation operations. For example, consider the below snippet: {{{#!hs {-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file -ddump-asm #-} module G (bar, baz) where import Data.Bits ((.|.)) import Data.Word (Word16) bar :: Word16 -> Int bar w = -9223372036854775808 .|. (281474976710656 .|. fromIntegral w) baz :: Word16 -> Int baz w = -9223372036854775808 + (281474976710656 + fromIntegral w) }}} Let's peek into the Core: {{{#!hs bar = \ (w_a1hX :: Word16) -> case w_a1hX of { GHC.Word.W16# x#_a1Lu -> GHC.Types.I# (GHC.Prim.orI# -9223372036854775808# (GHC.Prim.orI# 281474976710656# (GHC.Prim.word2Int# x#_a1Lu))) } baz = \ (w_a1sr :: Word16) -> case w_a1sr of { GHC.Word.W16# x#_a1Lu -> GHC.Types.I# (GHC.Prim.+# -9223090561878065152# (GHC.Prim.word2Int# x#_a1Lu)) } }}} Due to #9136, {{{baz}}} gets nicely folded away into a single addition. {{{bar}}} however is still in its "naive" form. The above example was extracted from an actual program where there may be long such chains of {{{orI#}}} and similar operations. I think it's worth pointing out that if we peek in the ASM, {{{bar}}} seems to get folded away eventually but I don't trust it to always happen properly at that level and I don't particularly fancy trawling through the ASM output every time. https://stackoverflow.com/a/45909278 has some laws we could use. I'm sure we could peek in LLVM source &c. too if we want to. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 08:31:50 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 08:31:50 -0000 Subject: [GHC] #16218: T16180 is broken on Darwin In-Reply-To: <046.aa96ca3ae65b0b9e6401b05f1cbb2a7d@haskell.org> References: <046.aa96ca3ae65b0b9e6401b05f1cbb2a7d@haskell.org> Message-ID: <061.e30ba232a8933802e473a3b6c5515805@haskell.org> #16218: T16180 is broken on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/195 -------------------------------------+------------------------------------- Changes (by hsyl20): * status: patch => closed * resolution: => fixed Comment: Merged in master as d97f0db8fa6c5d9a4c90c6096b01a76da07cfb2b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 11:06:30 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 11:06:30 -0000 Subject: [GHC] #16352: Hadrian: generation of PDF documents doesn't work Message-ID: <048.20cff9e01209548d8d56b3de2acce22c@haskell.org> #16352: Hadrian: generation of PDF documents doesn't work -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: Linux Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- 1) With [https://github.com/alpmestan/ghc.nix ghc.nix] While trying to produce `_build/docs/pdfs/Haddock.pdf`: {{{ kpathsea: Running mktexmf pcrr8t ! I can't find file `pcrr8t'. <*> ...:=ljfour; mag:=1; nonstopmode; input pcrr8t Please type another input file name ! Emergency stop. <*> ...:=ljfour; mag:=1; nonstopmode; input pcrr8t Transcript written on mfput.log. grep: pcrr8t.log: No such file or directory }}} 2) With the CI docker images (e.g [https://gitlab.haskell.org/ghc/ghc/blob/master/.circleci/images/x86_64 -linux-deb8/Dockerfile this x86_64 debian8 one]) Agian, while trying to product the PDF version of the haddock manual: {{{ | Run Xelatex: Haddock.tex => /tmp/extra-dir-87721391039866 This is XeTeX, Version 3.14159265-2.6-0.99992 (TeX Live 2015/dev/Debian) (preloaded format=xelatex) restricted \write18 enabled. entering extended mode (./Haddock.tex LaTeX2e <2014/05/01> Babel <3.9l> and hyphenation patterns for 2 languages loaded. (./sphinxmanual.cls Document Class: sphinxmanual 2009/06/02 Document class (Sphinx manual) (/usr/share/texlive/texmf-dist/tex/latex/base/report.cls Document Class: report 2014/09/29 v1.4h Standard LaTeX document class (/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))) (/usr/share/texlive/texmf-dist/tex/latex/base/inputenc.sty Package inputenc Warning: inputenc package ignored with utf8 based engines. ) ! Undefined control sequence. \DeclareUnicodeCharacter l.5 \DeclareUnicodeCharacter {00A0}{\nobreakspace} No pages of output. Transcript written on Haddock.log. }}} [https://tex.stackexchange.com/a/378643 This StackExchange post] that Matthew pointed me to gives a clue as to as why this happens. --- I am going to comment out the `need`s that make us produce these files in Hadrian when we ask for the docs, for now, leaving a comment pointing to this ticket. Then as we figure out solutions to these issues (especially 2), since that's GHC's CI system), we can put those PDFs back in and mark this ticket as solved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 11:09:54 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 11:09:54 -0000 Subject: [GHC] #16190: Speed up handling of large String literals In-Reply-To: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> References: <045.07adb1225bf3fc80b49538614d4e6843@haskell.org> Message-ID: <060.e6657ccc9035ef153262cfb465ed7bdc@haskell.org> #16190: Speed up handling of large String literals -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/143 -------------------------------------+------------------------------------- Changes (by hsyl20): * status: patch => closed * resolution: => fixed Comment: Merged in master with 1d9a1d9fb8fe0a1fea2c44c4246f102ff3e1f3a3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 11:27:12 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 11:27:12 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.a41d917c7bfbf795dc44cd12de99b7b3@haskell.org> #14741: High-memory usage during compilation using Template Haskell -------------------------------------+------------------------------------- Reporter: donatello | Owner: sighingnow Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #16190 | Differential Rev(s): Phab:D4384, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/141 -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: Phab:D4384 => Phab:D4384, https://gitlab.haskell.org/ghc/ghc/merge_requests/141 Comment: MR: https://gitlab.haskell.org/ghc/ghc/merge_requests/141 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 12:15:41 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 12:15:41 -0000 Subject: [GHC] #16343: Changing an irrelevant constraint leads to inlining failure In-Reply-To: <049.e18b8e351fabe80a824a994893607109@haskell.org> References: <049.e18b8e351fabe80a824a994893607109@haskell.org> Message-ID: <064.79b7b071007ad07552fd606b4d942ab5@haskell.org> #16343: Changing an irrelevant constraint leads to inlining failure -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 12:38:51 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 12:38:51 -0000 Subject: [GHC] #16353: ./validate --hadrian doesn't quite work on Windows Message-ID: <048.f7417c88af8b73478ebffabdce6bb6a6@haskell.org> #16353: ./validate --hadrian doesn't quite work on Windows -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: Windows Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On my Windows machine, using an msys2 shell as advised by the Windows- specific pages of GHC's trac, I managed to get `./validate --hadrian` (from [https://gitlab.haskell.org/ghc/ghc/merge_requests/326 this MR]) to go pretty far. I did manage to make it produce a binary distribution after some serious wrangling, to have it installed somewhere nearby and it ends up choking on [https://gitlab.haskell.org/alp/ghc/blob/wip/alp/hadrian- validate/validate#L258 this command] which tries to configure an `xhtml` build using `Setup.hs` scripts. When I looked at the verbose output, I ended up seeing that Cabal calls `findProgramVersion` for the ghc that I pass using `--with-ghc=...`, with `--numeric-version` as the only argument. And this ends up returning `""` -- which is what's returned when exceptions are thrown apparently, judging from [https://github.com/haskell/cabal/blob/c2cf30cc50109f2ffa30fd7affe9c22e1adf922c/Cabal/Distribution/Simple/Utils.hs#L921 findProgramVersion's implementation]. Now, where this gets "interesting" is that I've tried to run `./Setup configure --with-ghc=X` for different values of `X`... - (1) `./Setup configure --with- ghc=/path/to/ghc/tree/_validatebuild/stage1/bin/ghc` works - (2) `./Setup configure --with- ghc=/path/to/ghc/tree/_validatebuild/bindist/ghc-8.6.20190220/bin/ghc` works - (3) `./Setup configure --with-ghc=/path/to/ghc/tree/bindisttest/install dir/bin/ghc` **doesn't work** (3 spaces between `install` and `dir`) - (4) `./Setup configure --with-ghc=/path/to/ghc/tree/a/b/bin/ghc` **doesn't work** (1) is our stage 2 GHC executable, the real one, produced right at this path. (2) is a copy of (1) that we put under this `bindist/ghc-X.Y.Z/` dir, which we end up putting wholesale in an archive. (3) is where `./validate` (whether with `--hadrian` or not) installs binary distributions. The install process goes fine, I can even use the GHC in question and evaluate `.../bin/ghc -e 'Data.Text.IO.putStrLn (Data.Text.pack "hello")'` without any problem, or get the expected output with `.../bin/ghc --numeric-version`. But the `configure` step just won't have it. I initially thought this was due to the directory with a space in it, one way or another, so I decided to try and install the bindist manually in a place with no spaces in the directory names, (4). (4) doesn't work either though. The main difference between 1) 2) on one hand, and 3) 4) on the other, is that in the first two cases I'm passing the path to an actual stage 2 GHC executable, while in the case of 3) and 4) I'm pointing to wrapper scripts, with the actual executables being under `$topdir/lib/bin/`. I'm however not sure of what's going on, it seems to be like this should work, any help is appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 13:26:05 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 13:26:05 -0000 Subject: [GHC] #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces In-Reply-To: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> References: <050.95a24e87fd8922848e40ad1642976e14@haskell.org> Message-ID: <065.b1acf21ff4e1181242d1f5018396ff95@haskell.org> #16202: Hadrian install script doesn't update location of haddockHTMLs and haddockInterfaces -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: harpocrates Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/147 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: patch => closed * resolution: => fixed Comment: Fixed in d26869ac83935432e0dcea1ff591268232daef32. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 13:41:29 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 13:41:29 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. Message-ID: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.9 (LLVM) | Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ #!haskell module Main where import System.Random import qualified Data.Vector as V g1 = mkStdGen 0 :: StdGen v2 = take 10000 $ randoms g1 :: [Int] main :: IO () main = do undefined }}} {{{ $ /e/ghc_regSpill/inplace/bin/ghc-stage2.exe Repro.hs -O2 -fllvm -O2 Loaded package environment from C:\ghc\msys64\home\Andi\tmp\minmax\unpred\.ghc.environment.x86_64-mingw32-8.7.20190215 [1 of 1] Compiling Main ( Repro.hs, Repro.o ) C:\\ghc\\msys64\\tmp\\ghc385768_0\\ghc_6.s: Assembler messages: C:\\ghc\\msys64\\tmp\\ghc385768_0\\ghc_6.s:354: Error: junk at end of line, first unrecognized character is `,' `gcc.exe' failed in phase `Assembler'. (Exit code: 1) }}} I've reproduced this with ghc 8.4/8.6 and HEAD using llvm 7.0.1 on windows. It only occurs with -O2. The issues arise from these directives: {{{ .section .rdata,"dr",discard,__xmm at 000000000000004e0000000000000000 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 14:10:07 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 14:10:07 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.fc12d2704215144a52b83885d225a42e@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): As far as I can tell the issue is that the format used is only supported for ELF. See https://sourceware.org/binutils/docs/as/Section.html Assuming that is the reason hopefully we just need to pass an appropriate flag to llvm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 14:33:28 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 14:33:28 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.f793812e534c6a765282c6723adcb8d8@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 15:22:54 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 15:22:54 -0000 Subject: [GHC] #16355: Save CI performance metrics on windows jobs Message-ID: <045.1794e27115c4a9992691995dd1b87764@haskell.org> #16355: Save CI performance metrics on windows jobs -------------------------------------+------------------------------------- Reporter: davide | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | Keywords: git notes ci | Operating System: Windows performance test | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- MR !294 enabled saving and pushing of CI performance metrics for all osx and linux CI jobs. Now do the same for the windows jobs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 18:17:27 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 18:17:27 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.786b41e4b95b021343ef3132a5e8bd8e@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * Attachment "Repro.ll" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 18:18:05 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 18:18:05 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.9485216a1256e4cb47bff3c67edd3cf7@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Steps to reproduce. {{{ Andi at Horzube MINGW64 ~/tmp/minmax/llvm $ opt -O3 Repro.ll > opt.bc Andi at Horzube MINGW64 ~/tmp/minmax/llvm $ llc opt.bc -o llc.s -O3 Andi at Horzube MINGW64 ~/tmp/minmax/llvm $ as llc.s llc.s: Assembler messages: llc.s:367: Error: junk at end of line, first unrecognized character is `,' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 18:25:47 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 18:25:47 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.c895d5345857630ba5b71d26bfa28842@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): The issue here is that the target "x86_64-unknown-windows" generates .section directives which are not supported for pe output by the assembler. As far as I can tell however "x86_64-unknown-windows" (or one of the synonyms) IS the proper target. So this seems to be an issue with llvm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 18:31:10 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 18:31:10 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.32ebe3242c17218c11abd2c3d6c21da4@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): {{{ $ llc --version LLVM (http://llvm.org/): LLVM version 7.0.1 Optimized build. Default target: x86_64-w64-mingw32 Host CPU: skylake Registered Targets: aarch64 - AArch64 (little endian) aarch64_be - AArch64 (big endian) amdgcn - AMD GCN GPUs arm - ARM arm64 - ARM64 (little endian) armeb - ARM (big endian) bpf - BPF (host endian) bpfeb - BPF (big endian) bpfel - BPF (little endian) hexagon - Hexagon lanai - Lanai mips - Mips mips64 - Mips64 [experimental] mips64el - Mips64el [experimental] mipsel - Mipsel msp430 - MSP430 [experimental] nvptx - NVIDIA PTX 32-bit nvptx64 - NVIDIA PTX 64-bit ppc32 - PowerPC 32 ppc64 - PowerPC 64 ppc64le - PowerPC 64 LE r600 - AMD GPUs HD2XXX-HD6XXX sparc - Sparc sparcel - Sparc LE sparcv9 - Sparc V9 systemz - SystemZ thumb - Thumb thumbeb - Thumb (big endian) x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 xcore - XCore }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 18:35:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 18:35:56 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.0bfe3b8e580fd0012991b600e17418da@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => upstream Comment: Report upstream as [[https://bugs.llvm.org/show_bug.cgi?id=40824 #40824]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 18:48:46 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 18:48:46 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.c4a631a1608e9c8edc1dca299859e49f@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): {{{ $ as --version GNU assembler (GNU Binutils) 2.30 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-w64-mingw32'. }}} Windows 10 Pro - Build 17763 (64 Bit) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 22 23:02:43 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 22 Feb 2019 23:02:43 -0000 Subject: [GHC] #16356: Unexpected type application in default declaration Message-ID: <048.490e0ffbb02cb85e19f1ed70f4403000@haskell.org> #16356: Unexpected type application in default declaration -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- All of these work: {{{#!hs {-# LANGUAGE PolyKinds, TypeApplications, TypeFamilies, FlexibleInstances #-} import Data.Kind (Type) data B (a :: k) type family FClosed :: k -> Type where FClosed @k = B @k type family FOpen :: k -> Type type instance FOpen @k = B @k class FAssocClass k where type FAssoc :: k -> Type instance FAssocClass k where type FAssoc @k = B @k }}} This one doesn't: {{{#!hs class FAssocDefaultClass k where type FAssocDefault :: k -> Type type FAssocDefault @k = B @k }}} {{{ A.hs:21:23: error: Unexpected type application @k In the default declaration for ‘FAssocDefault’ | 21 | type FAssocDefault @k = B @k | }}} So, what are the rules of the game? Let's fix this and document in the User's Guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 03:34:17 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 03:34:17 -0000 Subject: [GHC] #16357: Add `oneShot` to the implementation of foldlM Message-ID: <048.e18fd2e9be565d436cf133f0e08651aa@haskell.org> #16357: Add `oneShot` to the implementation of foldlM -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.9 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The current (473632d7671619ee08a2a0025aa22bd4f79eca2d) implementation of `Data.Foldable.foldlM` is the like this {{{#!hs foldlM :: (Foldable t, Monad m) => (b -> a -> m b) -> b -> t a -> m b foldlM f z0 xs = foldr c return xs z0 -- See Note [List fusion and continuations in 'c'] where c x k z = f z x >>= k {-# INLINE c #-} }}} It generates an inefficient core for the following example. {{{#!hs f :: Int -> IO Int f = foldlM (\a b -> pure $! (a + b)) 0 (filter even [1..n]) }}} Generated core: {{{#!hs -- RHS size: {terms: 48, types: 22, coercions: 12, joins: 0/1} Main.$wf [InlPrag=NOUSERINLINE[2]] :: GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0] 216 30}] Main.$wf = \ (ww_s6TZ :: GHC.Prim.Int#) (w_s6TW :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.># 1# ww_s6TZ of { __DEFAULT -> letrec { go_a5un [Occ=LoopBreaker] :: GHC.Prim.Int# -> Int -> IO Int [LclId, Arity=1, Str=, Unf=OtherCon []] go_a5un = \ (x_a5uo :: GHC.Prim.Int#) -> case GHC.Prim.remInt# x_a5uo 2# of { __DEFAULT -> case GHC.Prim.==# x_a5uo ww_s6TZ of { __DEFAULT -> go_a5un (GHC.Prim.+# x_a5uo 1#); 1# -> (GHC.Base.$fApplicativeIO4 @ Int) `cast` (_R ->_R Sym (GHC.Types.N:IO[0] _R) :: (Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #)) ~R# (Int -> IO Int)) }; 0# -> Main.main_c @ Int (GHC.Types.I# x_a5uo) (case GHC.Prim.==# x_a5uo ww_s6TZ of { __DEFAULT -> go_a5un (GHC.Prim.+# x_a5uo 1#); 1# -> (GHC.Base.$fApplicativeIO4 @ Int) `cast` (_R ->_R Sym (GHC.Types.N:IO[0] _R) :: (Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #)) ~R# (Int -> IO Int)) }) }; } in ((go_a5un 1# Main.main4) `cast` (GHC.Types.N:IO[0] _R :: IO Int ~R# (GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #)))) w_s6TW; 1# -> (# w_s6TW, Main.main4 #) } }}} It seems that the main loop `go_a5un` is not eta-expanded. I think problem is that `oneShot` is missing in the definition of `foldlM`. When I changed the definition of `foldlM` as follows, {{{#!hs import GHC.Exts(oneShot) foldlM :: (Foldable t, Monad m) => (b -> a -> m b) -> b -> t a -> m b foldlM f z0 xs = foldr c return xs z0 -- See Note [List fusion and continuations in 'c'] where c x k = oneShot (\z -> f z x >>= k) {-# INLINE c #-} }}} Then, the main loop of the `wf` is eta-expaned as expected. {{{#!hs -- RHS size: {terms: 64, types: 46, coercions: 0, joins: 1/1} Main.$wf [InlPrag=NOUSERINLINE[2]] :: GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0] 136 30}] Main.$wf = \ (ww_s6Xc :: GHC.Prim.Int#) (w_s6X9 :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.># 1# ww_s6Xc of { __DEFAULT -> joinrec { go_s6WG [Occ=LoopBreaker] :: GHC.Prim.Int# -> Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) [LclId[JoinId(3)], Arity=3, Str=, Unf=OtherCon []] go_s6WG (x_a5xy :: GHC.Prim.Int#) (eta_B2 :: Int) (eta1_Xz :: GHC.Prim.State# GHC.Prim.RealWorld) = case GHC.Prim.remInt# x_a5xy 2# of { __DEFAULT -> case GHC.Prim.==# x_a5xy ww_s6Xc of { __DEFAULT -> jump go_s6WG (GHC.Prim.+# x_a5xy 1#) eta_B2 eta1_Xz; 1# -> (# eta1_Xz, eta_B2 #) }; 0# -> case eta_B2 of { GHC.Types.I# x1_a5t8 -> case GHC.Prim.==# x_a5xy ww_s6Xc of { __DEFAULT -> jump go_s6WG (GHC.Prim.+# x_a5xy 1#) (GHC.Types.I# (GHC.Prim.+# x1_a5t8 x_a5xy)) eta1_Xz; 1# -> (# eta1_Xz, GHC.Types.I# (GHC.Prim.+# x1_a5t8 x_a5xy) #) } } }; } in jump go_s6WG 1# Main.main4 w_s6X9; 1# -> (# w_s6X9, Main.main4 #) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 04:04:03 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 04:04:03 -0000 Subject: [GHC] #16357: Add `oneShot` to the implementation of foldlM In-Reply-To: <048.e18fd2e9be565d436cf133f0e08651aa@haskell.org> References: <048.e18fd2e9be565d436cf133f0e08651aa@haskell.org> Message-ID: <063.2e73abc83375d3502ed4d96aff19b848@haskell.org> #16357: Add `oneShot` to the implementation of foldlM -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by autotaker: Old description: > The current (473632d7671619ee08a2a0025aa22bd4f79eca2d) implementation of > `Data.Foldable.foldlM` is the like this > {{{#!hs > foldlM :: (Foldable t, Monad m) => (b -> a -> m b) -> b -> t a -> m b > foldlM f z0 xs = foldr c return xs z0 > -- See Note [List fusion and continuations in 'c'] > where c x k z = f z x >>= k > {-# INLINE c #-} > }}} > > It generates an inefficient core for the following example. > {{{#!hs > f :: Int -> IO Int > f = foldlM (\a b -> pure $! (a + b)) 0 (filter even [1..n]) > }}} > > Generated core: > {{{#!hs > -- RHS size: {terms: 48, types: 22, coercions: 12, joins: 0/1} > Main.$wf [InlPrag=NOUSERINLINE[2]] > :: GHC.Prim.Int# > -> GHC.Prim.State# GHC.Prim.RealWorld > -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0] 216 30}] > Main.$wf > = \ (ww_s6TZ :: GHC.Prim.Int#) > (w_s6TW :: GHC.Prim.State# GHC.Prim.RealWorld) -> > case GHC.Prim.># 1# ww_s6TZ of { > __DEFAULT -> > letrec { > go_a5un [Occ=LoopBreaker] :: GHC.Prim.Int# -> Int -> IO Int > [LclId, Arity=1, Str=, Unf=OtherCon []] > go_a5un > = \ (x_a5uo :: GHC.Prim.Int#) -> > case GHC.Prim.remInt# x_a5uo 2# of { > __DEFAULT -> > case GHC.Prim.==# x_a5uo ww_s6TZ of { > __DEFAULT -> go_a5un (GHC.Prim.+# x_a5uo 1#); > 1# -> > (GHC.Base.$fApplicativeIO4 @ Int) > `cast` (_R ->_R Sym (GHC.Types.N:IO[0] > _R) > :: (Int > -> GHC.Prim.State# > GHC.Prim.RealWorld > -> (# GHC.Prim.State# > GHC.Prim.RealWorld, Int #)) > ~R# (Int -> IO Int)) > }; > 0# -> > Main.main_c > @ Int > (GHC.Types.I# x_a5uo) > (case GHC.Prim.==# x_a5uo ww_s6TZ of { > __DEFAULT -> go_a5un (GHC.Prim.+# x_a5uo 1#); > 1# -> > (GHC.Base.$fApplicativeIO4 @ Int) > `cast` (_R ->_R Sym (GHC.Types.N:IO[0] > _R) > :: (Int > -> GHC.Prim.State# > GHC.Prim.RealWorld > -> (# GHC.Prim.State# > GHC.Prim.RealWorld, Int #)) > ~R# (Int -> IO Int)) > }) > }; } in > ((go_a5un 1# Main.main4) > `cast` (GHC.Types.N:IO[0] _R > :: IO Int > ~R# (GHC.Prim.State# GHC.Prim.RealWorld > -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int > #)))) > w_s6TW; > 1# -> (# w_s6TW, Main.main4 #) > } > }}} > It seems that the main loop `go_a5un` is not eta-expanded. > > I think problem is that `oneShot` is missing in the definition of > `foldlM`. > > When I changed the definition of `foldlM` as follows, > {{{#!hs > import GHC.Exts(oneShot) > foldlM :: (Foldable t, Monad m) => (b -> a -> m b) -> b -> t a -> m b > foldlM f z0 xs = foldr c return xs z0 > -- See Note [List fusion and continuations in 'c'] > where c x k = oneShot (\z -> f z x >>= k) > {-# INLINE c #-} > }}} > > Then, the main loop of the `wf` is eta-expaned as expected. > {{{#!hs > -- RHS size: {terms: 64, types: 46, coercions: 0, joins: 1/1} > Main.$wf [InlPrag=NOUSERINLINE[2]] > :: GHC.Prim.Int# > -> GHC.Prim.State# GHC.Prim.RealWorld > -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) > [GblId, > Arity=2, > Caf=NoCafRefs, > Str=, > Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0] 136 30}] > Main.$wf > = \ (ww_s6Xc :: GHC.Prim.Int#) > (w_s6X9 :: GHC.Prim.State# GHC.Prim.RealWorld) -> > case GHC.Prim.># 1# ww_s6Xc of { > __DEFAULT -> > joinrec { > go_s6WG [Occ=LoopBreaker] > :: GHC.Prim.Int# > -> Int > -> GHC.Prim.State# GHC.Prim.RealWorld > -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) > [LclId[JoinId(3)], > Arity=3, > Str=, > Unf=OtherCon []] > go_s6WG (x_a5xy :: GHC.Prim.Int#) > (eta_B2 :: Int) > (eta1_Xz :: GHC.Prim.State# GHC.Prim.RealWorld) > = case GHC.Prim.remInt# x_a5xy 2# of { > __DEFAULT -> > case GHC.Prim.==# x_a5xy ww_s6Xc of { > __DEFAULT -> jump go_s6WG (GHC.Prim.+# x_a5xy 1#) > eta_B2 eta1_Xz; > 1# -> (# eta1_Xz, eta_B2 #) > }; > 0# -> > case eta_B2 of { GHC.Types.I# x1_a5t8 -> > case GHC.Prim.==# x_a5xy ww_s6Xc of { > __DEFAULT -> > jump go_s6WG > (GHC.Prim.+# x_a5xy 1#) > (GHC.Types.I# (GHC.Prim.+# x1_a5t8 x_a5xy)) > eta1_Xz; > 1# -> (# eta1_Xz, GHC.Types.I# (GHC.Prim.+# x1_a5t8 > x_a5xy) #) > } > } > }; } in > jump go_s6WG 1# Main.main4 w_s6X9; > 1# -> (# w_s6X9, Main.main4 #) > } > }}} New description: The current (473632d7671619ee08a2a0025aa22bd4f79eca2d) implementation of `Data.Foldable.foldlM` is the like this {{{#!hs foldlM :: (Foldable t, Monad m) => (b -> a -> m b) -> b -> t a -> m b foldlM f z0 xs = foldr c return xs z0 -- See Note [List fusion and continuations in 'c'] where c x k z = f z x >>= k {-# INLINE c #-} }}} It generates an inefficient core for the following example. {{{#!hs f :: Int -> IO Int f n = foldlM (\a b -> pure $! (a + b)) 0 (filter even [1..n]) }}} Generated core: {{{#!hs -- RHS size: {terms: 48, types: 22, coercions: 12, joins: 0/1} Main.$wf [InlPrag=NOUSERINLINE[2]] :: GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0] 216 30}] Main.$wf = \ (ww_s6TZ :: GHC.Prim.Int#) (w_s6TW :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.># 1# ww_s6TZ of { __DEFAULT -> letrec { go_a5un [Occ=LoopBreaker] :: GHC.Prim.Int# -> Int -> IO Int [LclId, Arity=1, Str=, Unf=OtherCon []] go_a5un = \ (x_a5uo :: GHC.Prim.Int#) -> case GHC.Prim.remInt# x_a5uo 2# of { __DEFAULT -> case GHC.Prim.==# x_a5uo ww_s6TZ of { __DEFAULT -> go_a5un (GHC.Prim.+# x_a5uo 1#); 1# -> (GHC.Base.$fApplicativeIO4 @ Int) `cast` (_R ->_R Sym (GHC.Types.N:IO[0] _R) :: (Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #)) ~R# (Int -> IO Int)) }; 0# -> Main.main_c @ Int (GHC.Types.I# x_a5uo) (case GHC.Prim.==# x_a5uo ww_s6TZ of { __DEFAULT -> go_a5un (GHC.Prim.+# x_a5uo 1#); 1# -> (GHC.Base.$fApplicativeIO4 @ Int) `cast` (_R ->_R Sym (GHC.Types.N:IO[0] _R) :: (Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #)) ~R# (Int -> IO Int)) }) }; } in ((go_a5un 1# Main.main4) `cast` (GHC.Types.N:IO[0] _R :: IO Int ~R# (GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #)))) w_s6TW; 1# -> (# w_s6TW, Main.main4 #) } }}} It seems that the main loop `go_a5un` is not eta-expanded. I think problem is that `oneShot` is missing in the definition of `foldlM`. When I changed the definition of `foldlM` as follows, {{{#!hs import GHC.Exts(oneShot) foldlM :: (Foldable t, Monad m) => (b -> a -> m b) -> b -> t a -> m b foldlM f z0 xs = foldr c return xs z0 -- See Note [List fusion and continuations in 'c'] where c x k = oneShot (\z -> f z x >>= k) {-# INLINE c #-} }}} Then, the main loop of the `wf` is eta-expaned as expected. {{{#!hs -- RHS size: {terms: 64, types: 46, coercions: 0, joins: 1/1} Main.$wf [InlPrag=NOUSERINLINE[2]] :: GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 0] 136 30}] Main.$wf = \ (ww_s6Xc :: GHC.Prim.Int#) (w_s6X9 :: GHC.Prim.State# GHC.Prim.RealWorld) -> case GHC.Prim.># 1# ww_s6Xc of { __DEFAULT -> joinrec { go_s6WG [Occ=LoopBreaker] :: GHC.Prim.Int# -> Int -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Int #) [LclId[JoinId(3)], Arity=3, Str=, Unf=OtherCon []] go_s6WG (x_a5xy :: GHC.Prim.Int#) (eta_B2 :: Int) (eta1_Xz :: GHC.Prim.State# GHC.Prim.RealWorld) = case GHC.Prim.remInt# x_a5xy 2# of { __DEFAULT -> case GHC.Prim.==# x_a5xy ww_s6Xc of { __DEFAULT -> jump go_s6WG (GHC.Prim.+# x_a5xy 1#) eta_B2 eta1_Xz; 1# -> (# eta1_Xz, eta_B2 #) }; 0# -> case eta_B2 of { GHC.Types.I# x1_a5t8 -> case GHC.Prim.==# x_a5xy ww_s6Xc of { __DEFAULT -> jump go_s6WG (GHC.Prim.+# x_a5xy 1#) (GHC.Types.I# (GHC.Prim.+# x1_a5t8 x_a5xy)) eta1_Xz; 1# -> (# eta1_Xz, GHC.Types.I# (GHC.Prim.+# x1_a5t8 x_a5xy) #) } } }; } in jump go_s6WG 1# Main.main4 w_s6X9; 1# -> (# w_s6X9, Main.main4 #) } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 07:33:46 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 07:33:46 -0000 Subject: [GHC] #16357: Add `oneShot` to the implementation of foldlM In-Reply-To: <048.e18fd2e9be565d436cf133f0e08651aa@haskell.org> References: <048.e18fd2e9be565d436cf133f0e08651aa@haskell.org> Message-ID: <063.20ccb120d8f9a534a51aed64114ad434@haskell.org> #16357: Add `oneShot` to the implementation of foldlM -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by autotaker): * Attachment "T16357.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 08:01:18 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 08:01:18 -0000 Subject: [GHC] #16358: Confusing ghci error message Message-ID: <045.90a0c2a2713934e0ed4f4457696e24e9@haskell.org> #16358: Confusing ghci error message -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{ $ ghci GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Prelude> import qualified Data.Set as S Prelude S> S.foo :2:1: error: Not in scope: ‘S.foo’ No module named ‘S’ is imported. }}} I'm curious why `ghci` says `No module named 'S' is imported`. I found it very confusing. I'd have expected it to say one of three things: 1. `Module Data.Set referenced via S does not export foo` 2. `Constructor S not in scope` 3. `Variable foo not in scope` The first one would be the most informative, but I can see that the second and the third messages might be quite reasonable as well due to the interpretation of dot as composition. But the message `No module S is imported` is quite confusing given I just issued `import qualified Data.Set as S`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 08:06:09 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 08:06:09 -0000 Subject: [GHC] #16358: Confusing ghci error message In-Reply-To: <045.90a0c2a2713934e0ed4f4457696e24e9@haskell.org> References: <045.90a0c2a2713934e0ed4f4457696e24e9@haskell.org> Message-ID: <060.c7feaa53c3d526bcc903ebeb50e3e225@haskell.org> #16358: Confusing ghci error message -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > {{{ > $ ghci > GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help > Prelude> import qualified Data.Set as S > Prelude S> S.foo > > :2:1: error: > Not in scope: ‘S.foo’ > No module named ‘S’ is imported. > }}} > > I'm curious why `ghci` says `No module named 'S' is imported`. I found it > very confusing. > > I'd have expected it to say one of three things: > > 1. `Module Data.Set referenced via S does not export foo` > 2. `Constructor S not in scope` > 3. `Variable foo not in scope` > > The first one would be the most informative, but I can see that the > second and the third messages might be quite reasonable as well due to > the interpretation of dot as composition. But the message `No module S is > imported` is quite confusing given I just issued `import qualified > Data.Set as S`. New description: {{{ $ ghci GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Prelude> import qualified Data.Set as S Prelude S> S.foo :2:1: error: Not in scope: ‘S.foo’ No module named ‘S’ is imported. }}} I'm curious why `ghci` says `No module named 'S' is imported`. I found it very confusing. I'd have expected it to say one of three things: 1. `Module Data.Set referenced via S does not export foo` 2. `Constructor S not in scope` 3. `Variable foo not in scope` The first one would be the most informative, but I can see that the second and the third messages might be quite reasonable as well due to the interpretation of dot as composition. But the message `No module S is imported` is quite confusing given I just issued `import qualified Data.Set as S`. Indeed, if I put this in a file, the error message is crystal clear: {{{#!hs $ cat a.hs import qualified Data.Set as S bar = S.foo $ ghci a.hs GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( a.hs, interpreted ) a.hs:3:7: error: Not in scope: ‘S.foo’ Module ‘Data.Set’ does not export ‘foo’. | 3 | bar = S.foo | ^^^^^ Failed, no modules loaded. }}} I'm curious why there's a difference between these two scenarios. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 11:37:44 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 11:37:44 -0000 Subject: [GHC] #16263: Rework GHC's treatment of constraints in kinds In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.688752f8da39a561d94b02e104a2d071@haskell.org> #16263: Rework GHC's treatment of constraints in kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | 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: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Comment (by mpickering): The test files weren't included in the patch for #16185 so this test still needs to be added separately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 12:11:00 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 12:11:00 -0000 Subject: [GHC] #16358: Confusing ghci error message In-Reply-To: <045.90a0c2a2713934e0ed4f4457696e24e9@haskell.org> References: <045.90a0c2a2713934e0ed4f4457696e24e9@haskell.org> Message-ID: <060.258d83c50e587d97dc8b313a75b2bebc@haskell.org> #16358: Confusing ghci error message -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15611 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #15611 Comment: Thanks for the bug report. This is a duplicate of #15611, which will be fixed in GHC 8.8: {{{ λ> import qualified Data.Set as S λ> S.foo :2:1: error: Not in scope: ‘S.foo’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 12:13:37 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 12:13:37 -0000 Subject: [GHC] #13208: Do two-phase inlining in simpleOptPgm In-Reply-To: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> References: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> Message-ID: <064.48a7ae95594a7da432e8acfc6f98b965@haskell.org> #13208: Do two-phase inlining in simpleOptPgm -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_compile/T13208 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/394 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => deSugar/should_compile/T13208 * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/394 Comment: simonpj, what is the status of this ticket post-[https://gitlab.haskell.org/ghc/ghc/commit/5eeefe4c1e007ea2098f241634b48a4dada785a5 5eeefe4c1e007ea2098f241634b48a4dada785a5]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 12:15:08 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 12:15:08 -0000 Subject: [GHC] #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> References: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> Message-ID: <061.5c77bc8540b0399b3bd9b0b449bb2eac@haskell.org> #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16296 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/416 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/416 * related: => #16296 Comment: simonpj, what is the status of this ticket post-[https://gitlab.haskell.org/ghc/ghc/commit/0eb7cf03da3783ca887d5de44d312cf6f3a4113c 0eb7cf03da3783ca887d5de44d312cf6f3a4113c]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 12:16:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 12:16:32 -0000 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> Message-ID: <065.7be110ef92791156d970af1a44f29023@haskell.org> #16348: GHC HEAD regression: tyConAppArgs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T16348 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/416 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => simplCore/should_compile/T16348 * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/416 Comment: simonpj, what is the status of this ticket post-[https://gitlab.haskell.org/ghc/ghc/commit/c25b135ff5b9c69a90df0ccf51b04952c2dc6ee1 c25b135ff5b9c69a90df0ccf51b04952c2dc6ee1]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 12:38:00 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 12:38:00 -0000 Subject: [GHC] #16356: Unexpected type application in default declaration In-Reply-To: <048.490e0ffbb02cb85e19f1ed70f4403000@haskell.org> References: <048.490e0ffbb02cb85e19f1ed70f4403000@haskell.org> Message-ID: <063.fcee770f6880808c650b2a3df550f31e@haskell.org> #16356: Unexpected type application in default declaration -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 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 RyanGlScott): The [https://downloads.haskell.org/~ghc/8.6.3/docs/html/users_guide/glasgow_exts.html #associated-type-synonym-defaults users' guide section] on associated type family defaults is probably the closest thing to a specification of how they must be structured: > Note the following points: > > * The `instance` keyword is optional. > * There can be at most one default declaration for an associated type synonym. > * A default declaration is not permitted for an associated //data// type. > * The default declaration must mention only type //variables// on the left hand side, and the right hand side must mention only type variables that are explicitly bound on the left hand side. This restriction is relaxed for //kind variables//, however, as the right hand side is allowed to mention kind variables that are implicitly bound on the left hand side. > * Unlike the associated type family declaration itself, the type variables of the default instance are independent of those of the parent class. > > Here are some examples: > > {{{ > class C (a :: Type) where > type F1 a :: Type > type instance F1 a = [a] -- OK > type instance F1 a = a->a -- BAD; only one default instance is allowed > > type F2 b a -- OK; note the family has more type > -- variables than the class > type instance F2 c d = c->d -- OK; you don't have to use 'a' in the type instance > > type F3 a > type F3 [b] = b -- BAD; only type variables allowed on the LHS > > type F4 a > type F4 b = a -- BAD; 'a' is not in scope in the RHS > > type F5 a :: [k] > type F5 a = ('[] :: [x]) -- OK; the kind variable x is implicitly > bound by an invisible kind pattern > on the LHS > > type F6 a > type F6 a = > Proxy ('[] :: [x]) -- BAD; the kind variable x is not bound, > even by an invisible kind pattern > > type F7 (x :: a) :: [a] > type F7 x = ('[] :: [a]) -- OK; the kind variable a is implicitly > bound by the kind signature of the > LHS type pattern > }}} Unless I'm missing something, I don't see anything in here which would explicitly forbid `type FAssocDefault @k = B @k`. I'm inclined to support allowing it. In fact, the only reason GHC disallows it at the moment it due to a [https://gitlab.haskell.org/ghc/ghc/blob/04b7f4c1c6ea910ab378f27c5f9efd6c88f65425/compiler/parser/RdrHsSyn.hs#L836-841 validity check] in in `RdrHsSyn.checkTyVars`. It might be interesting to see what happens if you remove that validity check. Well, to be more precise, if you remove that validity check for associated type family defaults—we can't just remove the check entirely, since `checkTyVars` is also used to check the type variable binders for classes, data types, type synonyms, and type family declarations, where we currently disallow visible kind applications (#15782). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 12:42:50 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 12:42:50 -0000 Subject: [GHC] #15029: haddock parsing fails with valid input In-Reply-To: <045.21dff08a6f5f54f4b5d46444a13b9eee@haskell.org> References: <045.21dff08a6f5f54f4b5d46444a13b9eee@haskell.org> Message-ID: <060.421b0cdb7e45dd960b0e5a0e53c35f30@haskell.org> #15029: haddock parsing fails with valid input -------------------------------------+------------------------------------- Reporter: lerkok | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): This bug makes using doctest painful as it gives parse errors for programs that ghc accepts. See also https://github.com/haskell/haddock/issues/798 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 16:41:39 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 16:41:39 -0000 Subject: [GHC] #16359: Test runner warns of missing basline for performance tests with expected changes Message-ID: <045.4f071e01d4b88ffb73dd52669a2afd78@haskell.org> #16359: Test runner warns of missing basline for performance tests with expected changes -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.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: -------------------------------------+------------------------------------- When the commit message documents expected performance tests changes, the test runner warns of missing baselines for those tests, but a baseline is not needed, so the warning should ignore such cases. an example: https://gitlab.haskell.org/ghc/ghc/-/jobs/34315 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 21:10:35 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 21:10:35 -0000 Subject: [GHC] #15072: Teach the testsuite driver about response files In-Reply-To: <046.77942c6e24b9dfca972cf55cbeb07713@haskell.org> References: <046.77942c6e24b9dfca972cf55cbeb07713@haskell.org> Message-ID: <061.40dc66a122fbe1ce0c8003e9f3cb8008@haskell.org> #15072: Teach the testsuite driver about response files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ckoparkar Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15732 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): The same issue plagues Darwin, see https://gitlab.haskell.org/ghc/ghc/-/jobs/34485 and https://github.com/alpmestan/ghc.nix/issues/22#issuecomment-463354397 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 23:46:41 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 23:46:41 -0000 Subject: [GHC] #16360: GHC fails when GHC_PACKAGE_PATH contains trailing slash Message-ID: <042.6e14d18ad449a291c09cc7864ab28259@haskell.org> #16360: GHC fails when GHC_PACKAGE_PATH contains trailing slash -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC doesn't work Unknown/Multiple | at all Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When the directory given in `GHC_PACKAGE_PATH` contains a trailing slash, GHC stops working completely. For example, this works: {{{ env GHC_PACKAGE_PATH=/raid/src/ghc/ghc-atomic- writes/_build/stage1/lib/package.conf.d /raid/src/ghc/ghc-atomic- writes/_build/stage1/bin/ghc "--make" "-outputdir" "example-programs- build/" "example-programs/Hello.hs" "-o" "example-programs-build/haskell- hello" }}} but adding a trailing `/` like `GHC_PACKAGE_PATH=/path/to/package.conf.d/` fails: {{{ env GHC_PACKAGE_PATH=/raid/src/ghc/ghc-atomic- writes/_build/stage1/lib/package.conf.d/ /raid/src/ghc/ghc-atomic- writes/_build/stage1/bin/ghc "--make" "-outputdir" "example-programs- build/" "example-programs/Hello.hs" "-o" "example-programs-build/haskell- hello" }}} {{{ [1 of 1] Compiling Main ( example-programs/Hello.hs, example- programs-build/Main.o ) [Prelude changed] example-programs/Hello.hs:1:1: error: Could not find module ‘Prelude’ There are files missing in the ‘base-4.12.0.0’ package, try running 'ghc-pkg check'. Use -v (or `:set -v` in ghci) to see a list of the files searched for. | 1 | main :: IO () | ^ }}} This is surprising; most programs accept trailing slashes where directories are expected, and shells ofthen TAB-complete directories this way. It wastes developer time when they don't notice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 23:47:25 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 23:47:25 -0000 Subject: [GHC] #16360: GHC fails when GHC_PACKAGE_PATH contains trailing slash In-Reply-To: <042.6e14d18ad449a291c09cc7864ab28259@haskell.org> References: <042.6e14d18ad449a291c09cc7864ab28259@haskell.org> Message-ID: <057.ef669e5bc7d92649b61ab18ab4177df5@haskell.org> #16360: GHC fails when GHC_PACKAGE_PATH contains trailing slash -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 23 23:48:51 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 23 Feb 2019 23:48:51 -0000 Subject: [GHC] #16360: GHC fails when GHC_PACKAGE_PATH contains trailing slash In-Reply-To: <042.6e14d18ad449a291c09cc7864ab28259@haskell.org> References: <042.6e14d18ad449a291c09cc7864ab28259@haskell.org> Message-ID: <057.2c2e26505cae8e6e4e67ebdf138fa15e@haskell.org> #16360: GHC fails when GHC_PACKAGE_PATH contains trailing slash -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 08:28:18 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 08:28:18 -0000 Subject: [GHC] #16361: Non-deterministic hs_try_putmvar00 failure on CI Message-ID: <048.bec7bb8b335cc2642d0c3af70b85903c@haskell.org> #16361: Non-deterministic hs_try_putmvar00 failure on CI -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.9 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: -------------------------------------+------------------------------------- {{{ Wrong exit code for hs_try_putmvar003(threaded1)(expected 0 , actual 139 ) *** unexpected failure for hs_try_putmvar003(threaded1) }}} A quick search suggests that 139 might mean a segfault (SIGSEGV). This is a non-deterministic CI failure that happened to me at least two times (Feb 12 and Feb 24), and forced me to restart the build job to get a green build status. Both times it was the `validate-x86_64-linux-fedora27` job, but on different runners (`ghc-ci-gce-x86_64-1` and `maurer.smart- cactus.org`). Note that another failure that seems to happen only on Fedora is #16350 – could it be a problem with the Fedora image? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 10:57:59 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 10:57:59 -0000 Subject: [GHC] #16201: ghci063 failing on Darwin In-Reply-To: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> References: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> Message-ID: <061.c736596998013c5b82907011e4e4744e@haskell.org> #16201: ghci063 failing on Darwin ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.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 RyanGlScott): Ironically, `ghci063` is now breaking the CI build on `validate- x86_64-darwin` because it is unexpectedly passing (nondeterministically, of course). Here is an example from a [https://ghc- gitlab.s3.amazonaws.com/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b/2019_02_24/34776/53677/job.log ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190224T105625Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190224 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=4f88ddb6c4ecf5cb462c3b70b16a2e4e3f5d8a25a107a97621d1e942d51f7a48 recent run]: {{{ =====> ghci063(ghci) 1644 of 6844 [0, 0, 0] cd "ghci/scripts/ghci063.run" && HC="/Users/builder/builds/b4bc6410/0/ghc/ghc/inplace/bin/ghc-stage2" HC_OPTS="-dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output " "/Users/builder/builds/b4bc6410/0/ghc/ghc/inplace/bin/ghc-stage2" --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check -dcore-lint -dstg-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno- debug-output < ghci063.script *** unexpected pass for ghci063(ghci) SUMMARY for test run started at Sat Feb 23 21:45:56 2019 PST 0:27:56 spent to go through 6844 total tests, which gave rise to 26554 test cases, of which 19254 were skipped 42 had missing libraries 7156 expected passes 101 expected failures 0 caused framework failures 0 caused framework warnings 1 unexpected passes 0 unexpected failures 0 unexpected stat failures Unexpected passes: ghci/scripts/ghci063.run ghci063 [unexpected] (ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:01:06 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:01:06 -0000 Subject: [GHC] #16350: Nondeterministic T5559 failures on CI In-Reply-To: <050.9b58e539362fa36351f44a14284fd7e8@haskell.org> References: <050.9b58e539362fa36351f44a14284fd7e8@haskell.org> Message-ID: <065.3a71321f55aaf75125a9fc77343c49dc@haskell.org> #16350: Nondeterministic T5559 failures on CI -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/432 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/432 Comment: Commit [https://gitlab.haskell.org/ghc/ghc/commit/6ba3421efd1caf469e30ce53fef8c5406adde357 6ba3421efd1caf469e30ce53fef8c5406adde357] fixes the lack of spacing in the error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:04:03 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:04:03 -0000 Subject: [GHC] #16350: Nondeterministic T5559 failures on CI In-Reply-To: <050.9b58e539362fa36351f44a14284fd7e8@haskell.org> References: <050.9b58e539362fa36351f44a14284fd7e8@haskell.org> Message-ID: <065.f81b0ecd1ca68475176915f787637727@haskell.org> #16350: Nondeterministic T5559 failures on CI -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): | https://gitlab.haskell.org/ghc/ghc/merge_requests/432, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/438 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: https://gitlab.haskell.org/ghc/ghc/merge_requests/432 => https://gitlab.haskell.org/ghc/ghc/merge_requests/432, https://gitlab.haskell.org/ghc/ghc/merge_requests/438 Comment: [https://gitlab.haskell.org/ghc/ghc/merge_requests/438 !438] proposes to skip this test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:04:33 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:04:33 -0000 Subject: [GHC] #16349: Nondeterministic T3424 timeouts on CI In-Reply-To: <050.2a09de2550baf6c7c958ab823c4e0558@haskell.org> References: <050.2a09de2550baf6c7c958ab823c4e0558@haskell.org> Message-ID: <065.3820c769adb29daf5212bdf5e33b665b@haskell.org> #16349: Nondeterministic T3424 timeouts on CI -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/438 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/438 Comment: [https://gitlab.haskell.org/ghc/ghc/merge_requests/438 !438] proposes to skip this test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:05:07 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:05:07 -0000 Subject: [GHC] #16361: Non-deterministic hs_try_putmvar00 failure on CI In-Reply-To: <048.bec7bb8b335cc2642d0c3af70b85903c@haskell.org> References: <048.bec7bb8b335cc2642d0c3af70b85903c@haskell.org> Message-ID: <063.b673231d9c230dcbbb089a7086403dce@haskell.org> #16361: Non-deterministic hs_try_putmvar00 failure on CI -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/438 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/438 Comment: [https://gitlab.haskell.org/ghc/ghc/merge_requests/438 !438] proposes to skip this test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:06:49 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:06:49 -0000 Subject: [GHC] #16361: Non-deterministic hs_try_putmvar00 failure on CI In-Reply-To: <048.bec7bb8b335cc2642d0c3af70b85903c@haskell.org> References: <048.bec7bb8b335cc2642d0c3af70b85903c@haskell.org> Message-ID: <063.517d32f0b89c5517560c498211ebc595@haskell.org> #16361: Non-deterministic hs_try_putmvar00 failure on CI -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: https://gitlab.haskell.org/ghc/ghc/merge_requests/438 => Comment: Oops, I intended to make comment:1 in a different ticket. Sorry about the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:08:13 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:08:13 -0000 Subject: [GHC] #16350: Nondeterministic T5559 failures on CI In-Reply-To: <050.9b58e539362fa36351f44a14284fd7e8@haskell.org> References: <050.9b58e539362fa36351f44a14284fd7e8@haskell.org> Message-ID: <065.981ad235822d4810e2444cf15ec73753@haskell.org> #16350: Nondeterministic T5559 failures on CI -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.9 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): | https://gitlab.haskell.org/ghc/ghc/merge_requests/432, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/438 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:08:29 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:08:29 -0000 Subject: [GHC] #16349: Nondeterministic T3424 timeouts on CI In-Reply-To: <050.2a09de2550baf6c7c958ab823c4e0558@haskell.org> References: <050.2a09de2550baf6c7c958ab823c4e0558@haskell.org> Message-ID: <065.c1ad57b90da26785dc111caf84794704@haskell.org> #16349: Nondeterministic T3424 timeouts on CI -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.9 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/438 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:08:41 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:08:41 -0000 Subject: [GHC] #16361: Non-deterministic hs_try_putmvar00 failure on CI In-Reply-To: <048.bec7bb8b335cc2642d0c3af70b85903c@haskell.org> References: <048.bec7bb8b335cc2642d0c3af70b85903c@haskell.org> Message-ID: <063.b1dde20c81eb27a05ab34d27a1314d27@haskell.org> #16361: Non-deterministic hs_try_putmvar00 failure on CI -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.9 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:09:11 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:09:11 -0000 Subject: [GHC] #16193: Nondeterministic T15897 timeout failures In-Reply-To: <050.6b50375f06c0c1355a5fdb64d26cefc5@haskell.org> References: <050.6b50375f06c0c1355a5fdb64d26cefc5@haskell.org> Message-ID: <065.1a3fd64e4b5bbcfbab8a98423f3c691c@haskell.org> #16193: Nondeterministic T15897 timeout failures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.7 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/319 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:09:51 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:09:51 -0000 Subject: [GHC] #16100: T11627a fails sometimes on CI In-Reply-To: <049.e33977a8da6d3efb347066a1a3474487@haskell.org> References: <049.e33977a8da6d3efb347066a1a3474487@haskell.org> Message-ID: <064.f8201b39ab2812a254170653f3e17ba3@haskell.org> #16100: T11627a fails sometimes on CI -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:10:49 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:10:49 -0000 Subject: [GHC] #15382: heapprof001 segfaults in prof_hc_hb way on i386 In-Reply-To: <046.129cecd292baf096415325165f8ceabf@haskell.org> References: <046.129cecd292baf096415325165f8ceabf@haskell.org> Message-ID: <061.9b9e16a31e8e4df6b0d1d4cbc292c24d@haskell.org> #15382: heapprof001 segfaults in prof_hc_hb way on i386 -------------------------------------+----------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15463 | Differential Rev(s): Wiki Page: | -------------------------------------+----------------------------------- Changes (by RyanGlScott): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:15:04 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:15:04 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.ffe9bb75548502b698ec1c0777bf1e86@haskell.org> #16085: ffi018_ghci fails when unregisterised -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15467 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:19:48 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:19:48 -0000 Subject: [GHC] #16201: ghci063 failing on Darwin In-Reply-To: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> References: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> Message-ID: <061.301aec845ffd5a8a85a750268cce81b2@haskell.org> #16201: ghci063 failing on Darwin ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: ci-breakage 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 RyanGlScott): * keywords: => ci-breakage -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:23:55 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:23:55 -0000 Subject: [GHC] #16112: T11334b fails in the devel2 way In-Reply-To: <046.ea19986dfc00aa88f0411fa5f6afc91c@haskell.org> References: <046.ea19986dfc00aa88f0411fa5f6afc91c@haskell.org> Message-ID: <061.882e21dadf7e81d9c938254635eb1d20@haskell.org> #16112: T11334b fails in the devel2 way -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T11334b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => dependent/should_fail/T11334b * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/128 * resolution: => fixed * milestone: 8.8.1 => 8.10.1 Comment: A fix landed in [https://gitlab.haskell.org/ghc/ghc/commit/ac34e784775a0fa8b7284d42ff89571907afdc36 ac34e784775a0fa8b7284d42ff89571907afdc36]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:27:41 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:27:41 -0000 Subject: [GHC] #16185: Add an AnonArgFlag to FunTy In-Reply-To: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> References: <046.f619331ab1ab078ee0299facd6717b19@haskell.org> Message-ID: <061.48eeb442dcbdee1d6821ad3d9387a5c2@haskell.org> #16185: Add an AnonArgFlag to FunTy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.10.1 Comment: Implemented in [https://gitlab.haskell.org/ghc/ghc/commit/6cce36f83aec33d33545e0ef2135894d22dff5ca 6cce36f83aec33d33545e0ef2135894d22dff5ca]. There was no test case checked in for #15799 (re: comment:7), so it is still unclear what the status of that ticket is after this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:29:00 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:29:00 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.2f47cec4aee6f4e585b9f9d08b17f73d@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T15799 Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): #16185 was fixed in [https://gitlab.haskell.org/ghc/ghc/commit/6cce36f83aec33d33545e0ef2135894d22dff5ca 6cce36f83aec33d33545e0ef2135894d22dff5ca] (re: comment:8). Did that commit fix this ticket? Someone should check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:29:53 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:29:53 -0000 Subject: [GHC] #16263: Rework GHC's treatment of constraints in kinds In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.29f0e8effaff105d14a3af582aeee066@haskell.org> #16263: Rework GHC's treatment of constraints in kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | 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: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => simonpj Comment: Assigning to simonpj to take care of the remaining work in comment:10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 11:32:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 11:32:32 -0000 Subject: [GHC] #16331: REGRESSION: --supported-languages lies about supported languages, again In-Reply-To: <042.409c6663f2535c65d9d4fe82ed573178@haskell.org> References: <042.409c6663f2535c65d9d4fe82ed573178@haskell.org> Message-ID: <057.fee82a2bf00f4948fbffce5b4102ba61@haskell.org> #16331: REGRESSION: --supported-languages lies about supported languages, again -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/383 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => merge * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/383 * milestone: => 8.8.1 Comment: Fixed in [https://gitlab.haskell.org/ghc/ghc/commit/ee284b854e514685036dc21a1ee61241c76d14b5 ee284b854e514685036dc21a1ee61241c76d14b5]. Marking as a merge candidate for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 12:41:21 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 12:41:21 -0000 Subject: [GHC] #15072: Teach the testsuite driver about response files In-Reply-To: <046.77942c6e24b9dfca972cf55cbeb07713@haskell.org> References: <046.77942c6e24b9dfca972cf55cbeb07713@haskell.org> Message-ID: <061.9567abf6600a60639811b2aa09355a09@haskell.org> #15072: Teach the testsuite driver about response files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ckoparkar Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Test Suite | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 15732 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/438 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/438 Comment: It's interesting that `T14697` only seems to fail nondeterministically on Darwin. I wonder why this list of CLI arguments is too long on some runs but not on others? In any case, [https://gitlab.haskell.org/ghc/ghc/merge_requests/438 !438] disables `T14697` on Darwin (in addition to Windows). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 12:47:18 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 12:47:18 -0000 Subject: [GHC] #13633: testwsdeque failure on POWER8 In-Reply-To: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> References: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> Message-ID: <062.493d9266b3a337af0f191609c35c8a1f@haskell.org> #13633: testwsdeque failure on POWER8 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: SMP, ci- | breakage Operating System: Linux | Architecture: powerpc64 Type of failure: Runtime crash | Test Case: | rts/testwsdeque Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: SMP => SMP, ci-breakage Comment: I'm experiencing nondeterministic CI failures on `validate-x86_64-linux- deb9-unreg` due to `testwsdeque` unexpectedly //passing//, such as in [https://ghc- gitlab.s3.amazonaws.com/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b/2019_02_24/34837/53901/job.log ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190224T124346Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190224 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=71a51fa4b45493ac04249e2217478068a6cb4580a6367c6080d63c262bb3c9f1 this run]: {{{ *** unexpected pass for testwsdeque(threaded1) Unexpected results from: TEST="testwsdeque" SUMMARY for test run started at Sun Feb 24 09:28:06 2019 UTC 0:42:51 spent to go through 6844 total tests, which gave rise to 21127 test cases, of which 14004 were skipped 38 had missing libraries 6984 expected passes 100 expected failures 0 caused framework failures 0 caused framework warnings 1 unexpected passes 0 unexpected failures 0 unexpected stat failures Unexpected passes: rts/testwsdeque.run testwsdeque [unexpected] (threaded1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 12:51:05 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 12:51:05 -0000 Subject: [GHC] #16100: T11627a fails sometimes on CI In-Reply-To: <049.e33977a8da6d3efb347066a1a3474487@haskell.org> References: <049.e33977a8da6d3efb347066a1a3474487@haskell.org> Message-ID: <064.521c6511fa5a6aa9b315097e614e8a80@haskell.org> #16100: T11627a fails sometimes on CI -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: ci-breakage Operating System: 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): `T949` also occasionally fails on CI with the same panic ([https://ghc- gitlab.s3.amazonaws.com/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b/2019_02_24/34877/53941/job.log ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190224T124746Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190224 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=0d3ff67589490a67b80abbc045c7de427519f6f05ce24bc2685f70fa41a258c2 example] from a `validate-x86_64-linux-deb9-llvm` configuration): {{{ Wrong exit code for T949(prof_hc_hb)(expected 0 , actual 134 ) Stderr ( T949 ): T949: internal error: LDV_recordDead: Failed to find counter for closure 0x4200105000 (GHC version 8.9.20190224 for x86_64_unknown_linux) Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug Aborted (core dumped) *** unexpected failure for T949(prof_hc_hb) Unexpected results from: TEST="T949" SUMMARY for test run started at Sun Feb 24 10:46:01 2019 UTC 0:24:09 spent to go through 6844 total tests, which gave rise to 26554 test cases, of which 19235 were skipped 42 had missing libraries 7137 expected passes 139 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: profiling/should_run/T949.run T949 [bad exit code] (prof_hc_hb) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 13:27:35 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 13:27:35 -0000 Subject: [GHC] #16233: HIE file generation is inefficient In-Reply-To: <050.9a8af98be708c8bc79f0ecd2c361995e@haskell.org> References: <050.9a8af98be708c8bc79f0ecd2c361995e@haskell.org> Message-ID: <065.d12b022f5e13cdd083cd99e6615589a7@haskell.org> #16233: HIE file generation is inefficient -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15320 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): It seems like a great motivation to do something along the lines of the design in Phab:D5047 Simon, what do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 18:37:34 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 18:37:34 -0000 Subject: [GHC] #13633: testwsdeque failure on POWER8 In-Reply-To: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> References: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> Message-ID: <062.ddc9d3e874e6eec553bd1bd2af664393@haskell.org> #13633: testwsdeque failure on POWER8 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: SMP, ci- | breakage Operating System: Linux | Architecture: powerpc64 Type of failure: Runtime crash | Test Case: | rts/testwsdeque Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: (none) => trommler Comment: I have a patch on gitlab at https://gitlab.haskell.org/ghc/ghc/commits/wip/T13633. It seems to fix POWER9. I ran the testsuite twice and did not see it fail again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 21:05:22 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 21:05:22 -0000 Subject: [GHC] #16201: ghci063 failing on Darwin In-Reply-To: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> References: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> Message-ID: <061.834d168fbf4daaa5fa3115421d83691e@haskell.org> #16201: ghci063 failing on Darwin ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: ci-breakage 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 int-index): I have confirmed the non-deterministic nature of this locally. Out of 6 repeated runs there was 1 unexpected pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 21:52:09 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 21:52:09 -0000 Subject: [GHC] #14037: Fix fusion for GHC's utility functions In-Reply-To: <047.af3aa20f0a3e0012611cde731288958b@haskell.org> References: <047.af3aa20f0a3e0012611cde731288958b@haskell.org> Message-ID: <062.e88933fbd4ce42039a622afefedfd76b@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15263 | Differential Rev(s): Phab:D5249 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rockbmb): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 21:53:00 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 21:53:00 -0000 Subject: [GHC] #14037: Fix fusion for GHC's utility functions In-Reply-To: <047.af3aa20f0a3e0012611cde731288958b@haskell.org> References: <047.af3aa20f0a3e0012611cde731288958b@haskell.org> Message-ID: <062.4f81c0a3f21987a4d412a1483701f27c@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15263 | Differential Rev(s): Phab:D5249 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rockbmb): Closed after [this MR](https://gitlab.haskell.org/ghc/ghc/merge_requests/421). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 22:21:59 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 22:21:59 -0000 Subject: [GHC] #16201: ghci063 failing on Darwin In-Reply-To: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> References: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> Message-ID: <061.5782aa74e9144d46d1e6b0530ae15683@haskell.org> #16201: ghci063 failing on Darwin ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: ci-breakage 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 int-index): I figured it out, `touch -r` leads to precision loss: {{{ ghc(master)*$ echo "" > file ghc(master)*$ /nix/store/acnfbicd84bnya2l2dq868b5l482qihw- coreutils-8.30/bin/stat file File: file Size: 1 Blocks: 8 IO Block: 4096 regular file Device: 1000004h/16777220d Inode: 14905419 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 501/int-index) Gid: ( 20/ staff) Access: 2019-02-25 01:11:23.807505116 +0300 Modify: 2019-02-25 01:11:23.807627350 +0300 Change: 2019-02-25 01:11:23.807627350 +0300 Birth: 2019-02-25 01:11:23.807505116 +0300 ghc(master)*$ touch -r file file ghc(master)*$ /nix/store/acnfbicd84bnya2l2dq868b5l482qihw- coreutils-8.30/bin/stat file File: file Size: 1 Blocks: 8 IO Block: 4096 regular file Device: 1000004h/16777220d Inode: 14905419 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 501/int-index) Gid: ( 20/ staff) Access: 2019-02-25 01:11:23.807505000 +0300 Modify: 2019-02-25 01:11:23.807627000 +0300 Change: 2019-02-25 01:11:39.159813166 +0300 Birth: 2019-02-25 01:11:23.807505116 +0300 }}} The test passes nondeterministically when the last three digits are zero even before `touch`, I think. I was lucky to observe this locally after only a few runs, otherwise I would probably not even attempt to debug this! The solution is to do `touch -r B.hs B.hs` to nullify the digits before we run other `touch -r` commands. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 22:22:53 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 22:22:53 -0000 Subject: [GHC] #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. Message-ID: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. -------------------------------------+------------------------------------- Reporter: j9794 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This bug occurs if I define an instance for a typeclass adding a TypeError constraint on the instance, and then I try to derive that instance using Deriving Via in combination with StandaloneDeriving. This is the shortest example I was able to come up with: {{{ {-# Language DataKinds, UndecidableInstances, StandaloneDeriving, DerivingVia #-} import GHC.TypeLits newtype NotNum a = NotNum a instance (TypeError (Text "Not a num")) => Num (NotNum a) where data Foo = Foo deriving via (NotNum Foo) instance Num Foo }}} In this case, it'll fail in compilation with 'Not a Num'. This only seems to happen when combining deriving via with standalone deriving, because if I derive the class like: {{{ data Foo = Foo deriving Num via (NotNum Foo) }}} It works as expected (doesn't fail with my custom error until I actually try to use a Foo where I should use a Num) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 22:23:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 22:23:32 -0000 Subject: [GHC] #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. In-Reply-To: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> References: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> Message-ID: <059.831478be2ca3a65daee0882ba9cf4422@haskell.org> #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. -------------------------------------+------------------------------------- Reporter: j9794 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 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 j9794): * failure: None/Unknown => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 22:28:49 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 22:28:49 -0000 Subject: [GHC] #16201: ghci063 failing on Darwin In-Reply-To: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> References: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> Message-ID: <061.c3b1269da03721d716926482ab217a8f@haskell.org> #16201: ghci063 failing on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: ci-breakage Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/440 -------------------------------------+------------------------------------- Changes (by int-index): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/440 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 22:32:20 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 22:32:20 -0000 Subject: [GHC] #16201: ghci063 failing on Darwin In-Reply-To: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> References: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> Message-ID: <061.df75c02cc09186b7015aad294e8b5ac4@haskell.org> #16201: ghci063 failing on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: ci-breakage Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/440 -------------------------------------+------------------------------------- Changes (by int-index): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 23:20:28 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 23:20:28 -0000 Subject: [GHC] #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. In-Reply-To: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> References: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> Message-ID: <059.5cc82247f40162c49fcd4873c1d812b3@haskell.org> #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. -------------------------------------+------------------------------------- Reporter: j9794 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeErrors Comment: `data Foo = Foo deriving Num via (NotNum Foo)` is generating a slightly different instance than you think it is: {{{ $ /opt/ghc/8.6.3/bin/ghci Bug.hs -ddump-deriv GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) ==================== Derived instances ==================== Derived class instances: instance (TypeError ...) => GHC.Num.Num Main.Foo where }}} GHC treats `TypeError` constraints as insoluble, so they're inferred to be a part of the instance context. A standalone `deriving via (NotNum Foo) instance Num Foo` declaration, on the other hand, asserts that there is no instance context, so GHC tries to solve for the residual `TypeError` constraint that is inferred during typechecking. This leads to the compile-time exception you see in the original program. Note that if you write this: {{{#!hs deriving via (NotNum Foo) instance TypeError (Text "Not a num") => Num Foo }}} Or even this: {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} deriving via (NotNum Foo) instance _ => Num Foo }}} Then you won't get an exception during compile-time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 24 23:57:14 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 24 Feb 2019 23:57:14 -0000 Subject: [GHC] #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. In-Reply-To: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> References: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> Message-ID: <059.312243dfd89f1a7db6f819890f0ea29f@haskell.org> #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. -------------------------------------+------------------------------------- Reporter: j9794 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeErrors 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 j9794): Thanks for the prompt response and for the explanation!. So, is it expected behavior or an unintended consequence of how TypeError is treated? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 00:01:41 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 00:01:41 -0000 Subject: [GHC] #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. In-Reply-To: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> References: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> Message-ID: <059.da96abf7cc1cd4b5104b7d07a1c12bd3@haskell.org> #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. -------------------------------------+------------------------------------- Reporter: j9794 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't think I'm qualified to say. I've never been clear on what exactly the semantics of `TypeError` actually //intended// to be, so it's anyone's guess as to whether this is a bug or a feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 00:15:22 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 00:15:22 -0000 Subject: [GHC] #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" In-Reply-To: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> References: <049.33e94dfe2128632fd06d2ae9e3262e55@haskell.org> Message-ID: <064.1e24834e6550c562a3b580dac1a89537@haskell.org> #16130: GHC Panic on OS X: Data.Binary.Get.runGet: Invalid magic number "INPUT(-l" ---------------------------------+---------------------------------------- Reporter: basvandijk | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.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 basvandijk): I can confirm that [https://github.com/basvandijk/ghc/commit/b2b92dde16275339293cedaa94d6745e69e904dc this patch] fixes this issue. Both [https://github.com/basvandijk/macos- ghc863-panic macos-ghc863-panic], `bytestring-conversion` and `opencv- extra` build successfully with this patch and fail to build without it. Next up is adding a test for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 07:18:26 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 07:18:26 -0000 Subject: [GHC] #16357: Add `oneShot` to the implementation of foldlM In-Reply-To: <048.e18fd2e9be565d436cf133f0e08651aa@haskell.org> References: <048.e18fd2e9be565d436cf133f0e08651aa@haskell.org> Message-ID: <063.27a4394e7c9b94bc0b27f649941bdde7@haskell.org> #16357: Add `oneShot` to the implementation of foldlM -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by autotaker): This bug is caused by INLINE annotation for `c` which is introduced while fixing #8763. After list fusion, the example program would be: {{{#!hs f (I# n) = letrec go i = case i `remInt#` 2 of 1# -> case i ==# n of 0# -> go (i +# 1) 1# -> pure 0# -> c (I# i) (case i ==# n of 0# -> go (i +# 1) 1# -> pure) in go 0# (I# 0) c x k z = k $! (z + x) {-# INLINE c #-} }}} We can see function `c` is lifted to the **top-level definition**. Besides, the continuation `case i ==# n of { 0# -> go (i +# 1); 1# -> pure }` is passed as a **higher-order** argument of `c`. Therefore, CallArity analyzer cannot find the correct call-arity of function `go`. Without INLINE pragma for `c`, we have: {{{#!hs f (I# n) = letrec go i = case i `remInt#` 2 of 1# -> case i ==# n of 0# -> go (i +# 1) 1# -> pure 0# -> let k = case i ==# n of 0# -> go (i +# 1) 1# -> pure in \z -> k $! I# (z + (I# i)) in go 0# (I# 0) }}} We can see the continuation `k` is defined inside `go`. In this case, CallArity works good and finds the call-arity of `go` as 3 (not 2 because it includes `State# Realworld`). If we define `c x k = \z -> f z x >>= k` (instead of `c x k z = f z x >>= k`) and add an INLINE pragma for `c`, CallArity works good because the continuation is defined inside `go`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 09:04:31 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 09:04:31 -0000 Subject: [GHC] #16329: Simplifier ticks exhausted when fusing list literals In-Reply-To: <048.79eac52d9113bdb7b73038e1697ff24d@haskell.org> References: <048.79eac52d9113bdb7b73038e1697ff24d@haskell.org> Message-ID: <063.12890bb2cf11a28ac729a674a5ccf753@haskell.org> #16329: Simplifier ticks exhausted when fusing list literals -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11707 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by autotaker): * related: => #11707 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 09:19:06 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 09:19:06 -0000 Subject: [GHC] #13208: Do two-phase inlining in simpleOptPgm In-Reply-To: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> References: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> Message-ID: <064.c40db3be9e9d6540e3a8cf57909212ad@haskell.org> #13208: Do two-phase inlining in simpleOptPgm -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_compile/T13208 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/394 -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: It's fixed! Thanks for reporting the infelicity in comment:2, @bjmprice. The commit mentioned in comment:4 fixes your problem. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 09:22:32 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 09:22:32 -0000 Subject: [GHC] #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> References: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> Message-ID: <061.e52a22af422f28f44081e8b8bd514bb3@haskell.org> #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16296 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/416 -------------------------------------+------------------------------------- Comment (by simonpj): This ticket is fixed by the patch in comment:6. This is a quick-fix, not the proper solution. But we have #16296 for the proper solution, so I'll close this. We don't need a test case because all CI runs would (now, I hope) fail if this patch wasn't working. Matthew made some other change that makes CI catch these failures, whereas previously they were sneaking through. Matthew, perhaps you can just add a link to the CI-fix, and then close this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 09:25:06 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 09:25:06 -0000 Subject: [GHC] #16296: OccurAnal should not break the linter assumptions In-Reply-To: <047.644681ea1af3bb09669b9aa1303ac010@haskell.org> References: <047.644681ea1af3bb09669b9aa1303ac010@haskell.org> Message-ID: <062.fb06943394601123686696a4bc0e6db8@haskell.org> #16296: OccurAnal should not break the linter assumptions -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Simplifier Operating System: 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 wrote a quick fix, which has now landed as https://gitlab.haskell.org/ghc/ghc/commit/0eb7cf03da3783ca887d5de44d312cf6f3a4113c] But it's not the Right Solution; it's messy, and it loses some useful optimisations, namely {{{ case Imported.x of True -> .....(case Imported.x of { True -> e1; False -> e2 })...... False -> ... }}} We'd like the inner case to disappear, but now it won't. I think the right solution is as outlined in the Description. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 09:27:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 09:27:34 -0000 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> Message-ID: <065.2b628bb8304db08bd511f3236f00a2f3@haskell.org> #16348: GHC HEAD regression: tyConAppArgs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T16348 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/416 -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 10:10:16 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 10:10:16 -0000 Subject: [GHC] #13208: Do two-phase inlining in simpleOptPgm In-Reply-To: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> References: <049.5fc198138a0fbe18d71b2d09a1b0f368@haskell.org> Message-ID: <064.5a9d0a96c13d5f28073f93c91d2889e7@haskell.org> #13208: Do two-phase inlining in simpleOptPgm -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_compile/T13208 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/394 -------------------------------------+------------------------------------- Comment (by monoidal): I agree that [comment:2 comment:2] was addressed, but what about [comment:1 comment:1]? It seems to me that this was not addressed and was the original reason for leaving the ticket open. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 10:16:12 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 10:16:12 -0000 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> Message-ID: <065.1020742aca54202fe6897aa608d16aa6@haskell.org> #16348: GHC HEAD regression: tyConAppArgs -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T16348 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/416 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 10:23:39 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 10:23:39 -0000 Subject: [GHC] #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> References: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> Message-ID: <061.18df7c3bb7b154e0b352033050ba7c3e@haskell.org> #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16296 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/416 -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => fixed Comment: CI was fixed in {{{ commit 44ad7215a11cb49651233646c30ced9eb72eaad2 Author: Matthew Pickering Date: Wed Feb 20 20:42:13 2019 +0000 Use validate flavour rather than devel2 for DEBUG CI job This also builds stage2 with optimisations and -dcore-lint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 10:25:29 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 10:25:29 -0000 Subject: [GHC] #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId In-Reply-To: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> References: <046.665f969dc467b764fdc54e2f681c7367@haskell.org> Message-ID: <061.e7c3e25f4cb72e2b07982a8a4d5ee349@haskell.org> #16346: Lint error on master: Occurrence is GlobalId, but binding is LocalId -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16296 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/416 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 10:38:49 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 10:38:49 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.bb823210495b7227996dd34fede50e24@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Going by the answers upstream our options are: * Switch to the llvm assembler llvm-mc for the llvm backend. * Hope binutils implements the llvm extensions eventually. * Go back to LLVM 6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 11:47:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 11:47:34 -0000 Subject: [GHC] #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM In-Reply-To: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> References: <046.c33db136bf3c856ac62c74e888ef9992@haskell.org> Message-ID: <061.03532d3d2a7346dc27f09679e6904e86@haskell.org> #16087: TH tests fail in ext-interp way when ghc-stage2 is built using LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler (LLVM) | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm still experiencing `th`-related `ext-interp` failures on `validate- x86_64-linux-deb9-llvm`. See https://gitlab.haskell.org/ghc/ghc/merge_requests/378#note_8185. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 11:51:57 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 11:51:57 -0000 Subject: [GHC] #16329: Simplifier ticks exhausted when fusing list literals In-Reply-To: <048.79eac52d9113bdb7b73038e1697ff24d@haskell.org> References: <048.79eac52d9113bdb7b73038e1697ff24d@haskell.org> Message-ID: <063.40453a2372a707533ec4f56feb6f643a@haskell.org> #16329: Simplifier ticks exhausted when fusing list literals -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11707 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by autotaker): A workaround found. Adding `{-# INLINE [0] step #-}` avoids the code explosion problem, although I'm not sure why it works. I think desugaring `[1,2,..,10]` to `build (\c n -> c 1 (c 2 (...(c 10 n))))` is the cause of the problem. Since `c` is duplicated, code inlininng often generates a very complicated program. How about desugaring an explicit list literal `[v1, v2, v3, ... ,vn]` using an indexing function? That is: {{{#!hs [v1, v2, ..., vn ] = map f [1..n ::Int] where f i = case i of 1 -> v1 2 -> v2 ... n -> vn }}} Then it is fused to the following code: {{{#!hs build (\c n -> go 1# where go i# | i# == n# = n | otherwise = let-join j v = v `c` go (i# +# 1) in case i# of 1# -> j v1 2# -> j v2 ... n# -> j vn) }}} In this version, inlining does not cause code explosion problems because `c` occurs at once. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 12:19:39 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 12:19:39 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.1631586741b717a58f05d68d8bc5fc22@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/69 -------------------------------------+------------------------------------- Changes (by sgraf): * cc: mpickering (added) Comment: I just wanted to point out that this makes for different behavior when doing `./configure` and `hadrian/build.cabal.sh -c`. Specifically, when opening a `nix-shell --pure https://github.com/alpmestan/ghc.nix/archive/master.tar.gz`, this pollutes the configured $PATH variable with cabal-specific paths in my user home. Doing just `./configure` doesn't do that. I don't see why we always want to use the happy and alex versions that were used to build Hadrian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 12:31:28 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 12:31:28 -0000 Subject: [GHC] #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. In-Reply-To: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> References: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> Message-ID: <059.a9d87ce3d395c5793f0f9cd2ecf4b13d@haskell.org> #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. -------------------------------------+------------------------------------- Reporter: j9794 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: TypeErrors => CustomTypeErrors * cc: diatchki (added) Comment: Adding Iavor who is the key person on `TypeError`. See also [wiki:Proposal/CustomTypeErrors] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 12:41:42 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 12:41:42 -0000 Subject: [GHC] #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary In-Reply-To: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> References: <045.af83bd89f6fc347ca1166cf45220922d@haskell.org> Message-ID: <060.416cd58f5e21fcf1a660b5e4bdc2f722@haskell.org> #16120: Hadrian should use cabal build-tools installed Alex and Happy if necessary -------------------------------------+------------------------------------- Reporter: adamse | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/69 -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 13:37:39 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 13:37:39 -0000 Subject: [GHC] #13633: testwsdeque failure on POWER8 In-Reply-To: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> References: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> Message-ID: <062.ae50649b8f14e7d8f8eaeb7bfa8efa91@haskell.org> #13633: testwsdeque failure on POWER8 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: SMP, ci- | breakage Operating System: Linux | Architecture: powerpc64 Type of failure: Runtime crash | Test Case: | rts/testwsdeque Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ghc/ghc!445 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => ghc/ghc!445 Comment: I ran the test about a dozen times on a POWER9 and did not see any more failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 13:38:09 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 13:38:09 -0000 Subject: [GHC] #13633: testwsdeque failure on POWER8 In-Reply-To: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> References: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> Message-ID: <062.0c94a56b47a03e964e05f853c4da7c6d@haskell.org> #13633: testwsdeque failure on POWER8 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: SMP, ci- | breakage Operating System: Linux | Architecture: powerpc64 Type of failure: Runtime crash | Test Case: | rts/testwsdeque Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ghc/ghc!445 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: trommler => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 13:56:15 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 13:56:15 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMjEwMjog4oCcQ29uc3RyYWludHMgaW4ga2lu?= =?utf-8?q?ds=E2=80=9D_illegal_family_application_in_instance_=28?= =?utf-8?q?+_documentation_issues=3F=29?= In-Reply-To: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> References: <051.c1413ffcad4dfaf42160b6c05930b934@haskell.org> Message-ID: <066.4033334415599b6dada02e9d080791eb@haskell.org> #12102: “Constraints in kinds” illegal family application in instance (+ documentation issues?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T12102 Blocked By: | Blocking: Related Tickets: #13780, #15872 | Differential Rev(s): Phab:D5397 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * resolution: fixed => * milestone: 8.8.1 => Comment: Commit [https://gitlab.haskell.org/ghc/ghc/commit/6cce36f83aec33d33545e0ef2135894d22dff5ca 6cce36f83aec33d33545e0ef2135894d22dff5ca] (`Add AnonArgFlag to FunTy`) added back the ability to have equality constraints in kinds. Unfortunately, the issues in the original description persist. Here's one example of the bizarre things that equality constraints in kinds cause: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} module T12102 where import Data.Kind import GHC.TypeLits type family IsTypeLit a where IsTypeLit Nat = 'True IsTypeLit Symbol = 'True IsTypeLit a = 'False data T :: forall a. (IsTypeLit a ~ 'True) => a -> Type where MkNat :: T 42 MkSymbol :: T "Don't panic!" deriving instance Show (T a) }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling T12102 ( Bug.hs, Bug.o ) Bug.hs:21:25: error: • Expecting one more argument to ‘T a’ Expected a type, but ‘T a’ has kind ‘a0 -> *’ • In the first argument of ‘Show’, namely ‘(T a)’ In the stand-alone deriving instance for ‘Show (T a)’ | 21 | deriving instance Show (T a) | ^^^ Bug.hs:21:27: error: • Couldn't match kind ‘*’ with ‘Constraint’ When matching kinds k0 :: * IsTypeLit a0 ~ 'True :: Constraint Expected kind ‘IsTypeLit a0 ~ 'True’, but ‘a’ has kind ‘k0’ • In the first argument of ‘T’, namely ‘a’ In the first argument of ‘Show’, namely ‘(T a)’ In the stand-alone deriving instance for ‘Show (T a)’ | 21 | deriving instance Show (T a) | ^ }}} Huh? Why is GHC claiming that `T a` has kind `a0 -> *`? Well, if you ask GHCi: {{{ λ> :k T T :: (IsTypeLit a ~ 'True) -> a -> * }}} Yikes. Something is clearly wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 13:58:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 13:58:01 -0000 Subject: [GHC] #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) In-Reply-To: <051.a307612084bbe4f5b88300af043b1425@haskell.org> References: <051.a307612084bbe4f5b88300af043b1425@haskell.org> Message-ID: <066.042f95ac7dd6834d3fc7f26b43c21138@haskell.org> #15872: Odd pretty printing of equality constraint in kind ('GHC.Types.Eq# <>) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: error message | typecheck/should_fail/T12102 Blocked By: | Blocking: Related Tickets: #12102, #13933 | Differential Rev(s): Phab:D5397 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * resolution: fixed => * milestone: 8.8.1 => Comment: Commit [https://gitlab.haskell.org/ghc/ghc/commit/6cce36f83aec33d33545e0ef2135894d22dff5ca 6cce36f83aec33d33545e0ef2135894d22dff5ca] (`Add AnonArgFlag to FunTy`) added back the ability to have equality constraints in kinds. Unfortunately, the issues in the original description persist: {{{ GHCi, version 8.9.20190224: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Ok, one module loaded. λ> :i MkFun type role Fun nominal representational representational data Fun (a1 :: a ~ 'OP) b c where MkFun :: b -> c -> Fun 'GHC.Types.Eq# <> b c -- Defined at Bug.hs:11:3 λ> :k Fun Fun :: (a ~ 'OP) -> * -> * -> * }}} In fact, the situation is arguably //worse// now, since `:k Fun` reports the entirely bogus kind `Fun :: (a ~ 'OP) -> * -> * -> *`. (See also #12102.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 13:59:16 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 13:59:16 -0000 Subject: [GHC] #16263: Rework GHC's treatment of constraints in kinds In-Reply-To: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> References: <047.ec498a14d55e52e4eebc7b08ff245fe0@haskell.org> Message-ID: <062.d248cfc222cbf23f84c6fd89e409a2c6@haskell.org> #16263: Rework GHC's treatment of constraints in kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: TypeInType, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12102, #15872 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/128 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12102, #15872 Comment: Equality constraints in kinds are quite broken currently, as demonstrated in #12102 and #15872. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 15:28:52 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 15:28:52 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.12b91019fd4fb9918f02ec2f61216635@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I don't think it would be wise to let this issue hold us back on an old llvm release. However, the other options aren't much better. Ideally we would just use llvm-mc but this is easier said than done since we use invoke the assembler through gcc. Using as directly is complicated by the fact that we would then be responsible for running cpp ourselves. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 16:29:51 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 16:29:51 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.b5f6b54c2ec2a6d74d392a4b6e489009@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D745 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jberryman): Hi, this seems to have regressed. Should I open a new ticket? I'd like for ghc to look for versioned llvm executables in the PATH and prefer those over the unversioned names (if they exist). If #10074 is stalled this change seems sufficient to me. As it stands using multiple ghc versions with fllvm side by side is pretty inconvenient (or else I haven't figured out the trick). {{{ $ echo $PATH /home/me/Code/NOT_MY_CODE/spack/bin:/usr/lib/llvm-6.0/bin:/home/me/.cargo/bin:/usr/local/go/bin:/home/me/.rbenv/shims:/home/me/.rbenv/bin:/home/me/.play-2.2.2:/home/me/.node/bin:/usr/local/node/bin:/home/me/.local/bin:/home/me/.cabal/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/go/bin:/home/me/.gem/ruby/2.2.0/bin:/home/me/.go/bin $ which opt /usr/lib/llvm-6.0/bin/opt $ ghc --make -fforce-recomp -fllvm hello.hs -o hello_llvm [1 of 1] Compiling Main ( hello.hs, hello.o ) Linking hello_llvm ... $ export PATH=/home/me/.cargo/bin:/usr/local/go/bin:/home/me/.rbenv/shims:/home/me/.rbenv/bin:/home/me/.play-2.2.2:/home/me/.node/bin:/usr/local/node/bin:/home/me/.local/bin:/home/me/.cabal/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/go/bin:/home/me/.gem/ruby/2.2.0/bin:/home/me/.go/bin $ which opt opt not found $ which opt-6.0 1 ↵ /usr/bin/opt-6.0 $ ghc --make -fforce-recomp -fllvm hello.hs -o hello_llvm [1 of 1] Compiling Main ( hello.hs, hello.o ) : error: Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM 6.0 ghc: could not execute: opt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 16:38:42 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 16:38:42 -0000 Subject: [GHC] #10170: Find versioned versions of LLVM tools In-Reply-To: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> References: <044.8c0182698fda7c7bdc8df735a2e8660b@haskell.org> Message-ID: <059.26fd913343f4695ca69e824bdbb236ec@haskell.org> #10170: Find versioned versions of LLVM tools -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (LLVM) | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D745 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jberryman): Oh hm, it's not clear if this ticket was also (like #7661) supposed to be about the ghc build system. I care about this as a user of ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 16:45:38 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 16:45:38 -0000 Subject: [GHC] #15936: Rethink Choice of Baseline Commit for Performance Tests In-Reply-To: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> References: <045.b61e799b34d6a28f8727a59661eba7c0@haskell.org> Message-ID: <060.5727cb3822ba16b865232445cc25ce4d@haskell.org> #15936: Rethink Choice of Baseline Commit for Performance Tests -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: task | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.6.2 Resolution: fixed | Keywords: performance | tests git notes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * status: new => closed * resolution: => fixed Comment: Fixed in https://gitlab.haskell.org/ghc/ghc/merge_requests/294 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 16:46:37 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 16:46:37 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.4fe3b6bd0d680cebdc257b2d7b80cc6a@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5385 Wiki Page: | Phab:D5327 Phab:D5423 -------------------------------------+------------------------------------- Comment (by davide): This is mostly resolved in https://gitlab.haskell.org/ghc/ghc/merge_requests/174 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 17:14:05 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 17:14:05 -0000 Subject: [GHC] #16363: Modular constant folding Message-ID: <045.a4a4cac9ce41785be0aa7ca965d6a043@haskell.org> #16363: Modular constant folding -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- The following code (taken from #16329): {{{#!hs func :: Int -> IO Int func n = foldM step 0 xs where xs = map (n+) [1,2,3] step acc x = case x `mod` 3 of 0 -> pure acc 1 -> pure $ acc + 1 2 -> pure $ acc + 2 func' n = foldl step 0 xs where xs = map (n+) [1,2,3] step acc x = case x `mod` 3 of 0 -> acc 1 -> acc + 1 2 -> acc + 2 }}} is simplified to the following core code: {{{#!hs func n = case n + 1 `mod` 3 of 0 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 0 1 -> pure 1 2 -> pure 2 1 -> case n + 3 `mod` 3 of 0 -> pure 1 1 -> pure 2 2 -> pure 3 2 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 1 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 1 1 -> pure 2 2 -> pure 3 1 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 2 -> case n + 3 `mod` 3 of 0 -> pure 3 1 -> pure 4 2 -> pure 5 2 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 1 -> case n + 3 `mod` 3 of 0 -> pure 3 1 -> pure 4 2 -> pure 5 2 -> case n + 3 `mod` 3 of 0 -> pure 4 1 -> pure 5 2 -> pure 6 func' n = join j2 w2 = join j1 w1 = case n + 3 `mod` 3 of 0 -> w1 1 -> w1 + 1 2 -> w1 + 2 in case n + 2 `mod` 3 of 0 -> jump j1 w2 1 -> jump j1 (w2 + 1) 2 -> jump j1 (w2 + 2) in case n + 1 `mod` 3 of 0 -> jump j2 0 1 -> jump j2 1 2 -> jump j2 2 }}} Case-folding with modular arithmetic should remove the nesting. (patch coming) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 17:14:18 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 17:14:18 -0000 Subject: [GHC] #16363: Modular constant folding In-Reply-To: <045.a4a4cac9ce41785be0aa7ca965d6a043@haskell.org> References: <045.a4a4cac9ce41785be0aa7ca965d6a043@haskell.org> Message-ID: <060.bf9dbe955d28144a1c85e6fd230b6cd7@haskell.org> #16363: Modular constant folding -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * owner: (none) => hsyl20 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 18:51:07 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 18:51:07 -0000 Subject: [GHC] #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. In-Reply-To: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> References: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> Message-ID: <059.48fb2a277ab48ffb497f701a6d40585a@haskell.org> #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. -------------------------------------+------------------------------------- Reporter: j9794 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: | CustomTypeErrors 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 diatchki): If I understand what's going on here, the custom type errors work as intended. I think of using `TypeError` in the context of an instance declaration as saying "this instance does not exist". I think it would be nicer to have an actual language construct to say that, but for the time being `TypeError` is convenient "hack" that achieves a similar result. So, the standalone instance in the original example has to derive and instance for `Num Foo` by using the non-existing instance for `NotNum Foo`. As a result GHC reports that it can't do that, using the custom type error provided. I think that this makes sense. OTOH, if you write the alternative that Ryan wrote: {{{ deriving via (NotNum Foo) instance TypeError (Text "Not a num") => Num Foo }}} you are really saying that there is no instance for `Num Foo` and for the exact same reason that there is no instance for `NotNum Foo`. Deriving a non-existing instance seems like a bit of an odd thing to do though, as there is nothing to derive... I guess it makes sense if you are trying to report a class of errors in the same way, but you could get the same by just writing the instance without deriving: {{{ instance Num (NotNum Foo) => Num Foo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 25 23:04:16 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 25 Feb 2019 23:04:16 -0000 Subject: [GHC] #16356: Unexpected type application in default declaration In-Reply-To: <048.490e0ffbb02cb85e19f1ed70f4403000@haskell.org> References: <048.490e0ffbb02cb85e19f1ed70f4403000@haskell.org> Message-ID: <063.690f83475c53d22800a821046490a844@haskell.org> #16356: Unexpected type application in default declaration -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 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 goldfire): I agree that this should work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 01:18:59 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 01:18:59 -0000 Subject: [GHC] #13633: testwsdeque failure on POWER8 In-Reply-To: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> References: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> Message-ID: <062.54d91b879e3521686f03e07348cb635a@haskell.org> #13633: testwsdeque failure on POWER8 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: SMP, ci- | breakage Operating System: Linux | Architecture: powerpc64 Type of failure: Runtime crash | Test Case: | rts/testwsdeque Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ghc/ghc!445 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:4 RyanGlScott]: > I'm experiencing nondeterministic CI failures on `validate-x86_64-linux- deb9-unreg` due to `testwsdeque` unexpectedly //passing//, such as in [https://ghc- gitlab.s3.amazonaws.com/6b/86/6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b/2019_02_24/34837/53901/job.log ?response-content-type=text/plain%3B%20charset%3Dutf-8&response-content- disposition=inline&X-Amz-Expires=600&X-Amz-Date=20190224T124346Z&X-Amz- Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAI3NPPHETCY4XXTOA/20190224 /us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz- Signature=71a51fa4b45493ac04249e2217478068a6cb4580a6367c6080d63c262bb3c9f1 this run]: > I'm rather puzzled by this. This test isn't marked as `expect_broken` as far as I can tell. Why is the testsuite driver expecting it to fail? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 05:07:45 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 05:07:45 -0000 Subject: [GHC] #16364: Derived Enum for small number of constructors seems suboptimal Message-ID: <047.1387e67db3c967e70a4ee555b04e6af5@haskell.org> #16364: Derived Enum for small number of constructors seems suboptimal -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE MagicHash #-} module En (toEnum', toEnum'', toEnum''', toEnum'''') where import GHC.Int import GHC.Prim import GHC.Word data Q' = Foo' | Bar' deriving Enum toEnum' :: Int -> Q' toEnum' 0 = Foo' toEnum' 1 = Bar' toEnum' x = error $ "out of range " <> show x toEnum'' :: Int -> Q' toEnum'' x@(I# n) | x >= 0 && x <= 1 = tagToEnum# n toEnum'' x = error $ "out of range " <> show x toEnum''' :: Int -> Q' toEnum''' x@(I# n) | x == 0 || x == 1 = tagToEnum# n toEnum''' x = error $ "out of range " <> show x toEnum'''' :: Int -> Q' toEnum'''' x@(I# n) = case int2Word# n `leWord#` 1## of 0# -> error $ "out of range " <> show x _ -> tagToEnum# n }}} For the derived {{{toEnum}}}, we get something as {{{#!hs -- RHS size: {terms: 19, types: 4, coercions: 0, joins: 0/0} En.$w$ctoEnum [InlPrag=NOUSERINLINE[2]] :: Int# -> Q' [GblId, Arity=1, Str=, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 83 0}] En.$w$ctoEnum = \ (ww_s3Kl :: Int#) -> case >=# ww_s3Kl 0# of { __DEFAULT -> En.$wlvl ww_s3Kl; 1# -> case <=# ww_s3Kl 1# of { __DEFAULT -> En.$wlvl ww_s3Kl; 1# -> tagToEnum# @ Q' ww_s3Kl } } -- RHS size: {terms: 6, types: 3, coercions: 0, joins: 0/0} En.$fEnumQ'_$ctoEnum [InlPrag=NOUSERINLINE[2]] :: Int -> Q' [GblId, Arity=1, Str=, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (w_s3Ki [Occ=Once!] :: Int) -> case w_s3Ki of { I# ww1_s3Kl [Occ=Once] -> En.$w$ctoEnum ww1_s3Kl }}] En.$fEnumQ'_$ctoEnum = \ (w_s3Ki :: Int) -> case w_s3Ki of { I# ww1_s3Kl -> En.$w$ctoEnum ww1_s3Kl } }}} Two comparisons to find out one thing! Contrast this with something like {{{toEnum'}}}: {{{#!hs toEnum' = \ (ds_d3dp :: Int) -> case ds_d3dp of { I# ds1_d3dr -> case ds1_d3dr of ds2_X3dR { __DEFAULT -> En.$wlvl1 ds2_X3dR; 0# -> En.Foo'; 1# -> En.Bar' } } }}} Surely this seems better? But we don't even have to write out the constructors by hand in this case. {{{toEnum'''}}} actually produces the same code as {{{toEnum'}}}. I also wrote {{{toEnum''''}}} which I had some hopes for but actually runs the slowest. I'm unsure why. Seems simple enough: {{{#!hs toEnum'''' = \ (x_a2Sd :: Int) -> case x_a2Sd of { I# n_a2Se -> case leWord# (int2Word# n_a2Se) 1## of { __DEFAULT -> tagToEnum# @ Q' n_a2Se; 0# -> En.$wlvl4 n_a2Se } } }}} The point of this ticket is to consider whether it's not better to simply expand small number of constructors in a derived enumeration into a pattern match. In microbenchmark, {{{toEnum'}}} seems faster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 10:04:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 10:04:16 -0000 Subject: [GHC] #16364: Derived Enum for small number of constructors seems suboptimal In-Reply-To: <047.1387e67db3c967e70a4ee555b04e6af5@haskell.org> References: <047.1387e67db3c967e70a4ee555b04e6af5@haskell.org> Message-ID: <062.e26869899a467d420d1d994a729f6f19@haskell.org> #16364: Derived Enum for small number of constructors seems suboptimal -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree that a straight pattern-match on the tag might be better, at least for small enumerations. Another interesting question is this: what is the behaviour of the primitive operation `tagToEnum#` when given an out-of-range tag? Does it crash somehow, return a bogus answer, or call `error`? It think it might be the former, relying on the caller to check for out-of-range cases, like array indexing. We should document this properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 10:14:02 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 10:14:02 -0000 Subject: [GHC] #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. In-Reply-To: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> References: <044.a79ea5696aa74f60bd2cb39ae3f23726@haskell.org> Message-ID: <059.07ba93edf92e593db1e388d3c23296ef@haskell.org> #16362: Deriving a class via an instance that has a TypeError constraint using standalone deriving fails during compilation. -------------------------------------+------------------------------------- Reporter: j9794 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: invalid | Keywords: | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Alright. Since Iavor seems convinced that this is expected behavior, I'm going to close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 10:23:51 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 10:23:51 -0000 Subject: [GHC] #16365: Inconsistency in quantified constraint solving Message-ID: <050.a379a836df5c0074c7f647d7d8a8a117@haskell.org> #16365: Inconsistency in quantified constraint solving -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind import Data.Proxy class C a where m :: a -> () data Dict c = c => Dict ----- type family F a :: Type -> Type class C (F a b) => CF a b instance C (F a b) => CF a b works1 :: (forall z. CF a z) => Proxy (a, b) -> Dict (CF a b) works1 _ = Dict works2 :: ( CF a b) => Proxy (a, b) -> Dict (C (F a b)) works2 _ = Dict works3, fails :: (forall z. CF a z) => Proxy (a, b) -> Dict (C (F a b)) works3 p | Dict <- works1 p = Dict fails _ = Dict }}} `fails`, as its name suggests, fails to typecheck: {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:33:11: error: • Could not deduce (C (F a b)) arising from a use of ‘Dict’ from the context: forall z. CF a z bound by the type signature for: fails :: forall a b. (forall z. CF a z) => Proxy (a, b) -> Dict (C (F a b)) at Bug.hs:31:1-71 • In the expression: Dict In an equation for ‘fails’: fails _ = Dict | 33 | fails _ = Dict | ^^^^ }}} But I see no reason why this shouldn't typecheck. After all, the fact that `works1` typechecks proves that GHC's constraint solver is perfectly capable of deducing that `(forall z. CF a z)` implies `(CF a b)`, and the fact that `works2` typechecks proves that GHC's constraint solver is perfectly capable of deducing that `(CF a b)` implies that `(C (F a b))`. Why then can GHC's constraint solver not connect the dots and deduce that `(forall z. CF a z)` implies `(C (F a b))` (in the type of `fails`)? Note that something with the type `(forall z. CF a z) => Proxy (a, b) -> Dict (C (F a b))` //can// be made to work if you explicitly guide GHC along with explicit pattern-matching on a `Dict`, as `works3` demonstrates. But I claim that this shouldn't be necessary. Moreover, in this variation of the program above: {{{#!hs -- ----- data G a :: Type -> Type class C (G a b) => CG a b instance C (G a b) => CG a b works1' :: (forall z. CG a z) => Proxy (a, b) -> Dict (CG a b) works1' _ = Dict works2' :: ( CG a b) => Proxy (a, b) -> Dict (C (G a b)) works2' _ = Dict works3' :: (forall z. CG a z) => Proxy (a, b) -> Dict (C (G a b)) works3' _ = Dict }}} `works3'` needs no explicit `Dict` pattern-matching to typecheck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 10:44:15 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 10:44:15 -0000 Subject: [GHC] #16366: Strict version of `foldlM`. Message-ID: <048.843d89679d268b8e0ed4ab412088adcf@haskell.org> #16366: Strict version of `foldlM`. -------------------------------------+------------------------------------- Reporter: autotaker | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.3 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: -------------------------------------+------------------------------------- `Data.Foldable.foldlM` is lazy on the accumulation parameter. A user can define {{{foldlM (\acc x -> acc `seq` step acc x) z xs}}}, but actually this function is NOT strict! It is simplified to the following core: {{{#!hs foldlM (\acc x -> acc `seq` step acc x) z xs == go xs z where go [] acc = pure acc go (x:xs) acc = (acc `seq` step acc x) >>= go xs }}} DemandAnalysis infers that `go` is lazy on the second argument because `pure` is lazy in general (e.g. `IO` Monad). Thus `foldlM'` is needed. Its definition would be: {{{#!hs foldlM' :: (Monad m, Foldable t) => (b -> a -> m b) -> b -> t a -> m b foldlM' f z0 xs = foldr c (\x -> x `seq` pure x) xs z0 where c x k = \z -> z `seq` (f z x >>= k) {-# INLINE c #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 14:47:56 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 14:47:56 -0000 Subject: [GHC] #16367: Panic when trying to openFile Message-ID: <044.8e2cb7e79ae10a79b9287a5e4158d759@haskell.org> #16367: Panic when trying to openFile --------------------------------------+---------------------------------- Reporter: vilem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- {{{ $ stack repl Note: No local targets specified, so a plain ghci will be started with no package hiding or package options. If you want to use package hiding and options, then you can try one of the following: * If you want to start a different project configuration than /Users/vl200/.stack/global-project/stack.yaml, then you can use stack init to create a new stack.yaml for the packages in the current directory. * If you want to use the project configuration at /Users/vl200/.stack/global-project/stack.yaml, then you can add to its 'packages' field. Configuring GHCi with the following packages: GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/vl200/.ghci Loaded GHCi configuration from /private/var/folders/km/1g5b7h891674vhv9z1g4d9cw0000gn/T/haskell-stack- ghci/2a3bbd58/ghci-script Prelude> import System.IO Prelude System.IO> openFile ".g .granule .gitignore .ghc .ghci .gitconfig Prelude System.IO> openFile ".granule" Re Read ReadMode ReadS ReadWriteMode Real RealFloat RealFrac RelativeSeek Prelude System.IO> openFile ".granule" ReadMode ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): nameModule system $dShow_a1QJ Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 14:50:45 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 14:50:45 -0000 Subject: [GHC] #16367: Panic when trying to openFile In-Reply-To: <044.8e2cb7e79ae10a79b9287a5e4158d759@haskell.org> References: <044.8e2cb7e79ae10a79b9287a5e4158d759@haskell.org> Message-ID: <059.ec621be8fe8ca28968a779a33437c528@haskell.org> #16367: Panic when trying to openFile ----------------------------------+-------------------------------------- Reporter: vilem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by vilem): Also getting this with 8.4.4 {{{ ~ ✔︎ ghci GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/vl200/.ghci Prelude> import System.IO Prelude System.IO> openFile ".granule" ReadWriteMode ghc: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-apple-darwin): nameModule system $dShow_a1QU Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Prelude System.IO> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 14:58:08 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 14:58:08 -0000 Subject: [GHC] #16367: Panic when trying to openFile with -fdefer-type-errors (was: Panic when trying to openFile) In-Reply-To: <044.8e2cb7e79ae10a79b9287a5e4158d759@haskell.org> References: <044.8e2cb7e79ae10a79b9287a5e4158d759@haskell.org> Message-ID: <059.246963535ad581fb54da2272a3dbac46@haskell.org> #16367: Panic when trying to openFile with -fdefer-type-errors ----------------------------------+-------------------------------------- Reporter: vilem | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.4 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by vilem): * version: 8.4.3 => 8.4.4 Old description: > {{{ > $ stack repl > > Note: No local targets specified, so a plain ghci will be started with no > package hiding or package options. > > If you want to use package hiding and options, then you can try one > of the following: > > * If you want to start a different project configuration than > /Users/vl200/.stack/global-project/stack.yaml, then you can use stack > init to create a new > stack.yaml for the packages in the current directory. > > * If you want to use the project configuration at > /Users/vl200/.stack/global-project/stack.yaml, then you can add to its > 'packages' field. > > Configuring GHCi with the following packages: > GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /Users/vl200/.ghci > Loaded GHCi configuration from > /private/var/folders/km/1g5b7h891674vhv9z1g4d9cw0000gn/T/haskell-stack- > ghci/2a3bbd58/ghci-script > Prelude> import System.IO > Prelude System.IO> openFile ".g > .granule .gitignore .ghc .ghci .gitconfig > Prelude System.IO> openFile ".granule" Re > Read ReadMode ReadS ReadWriteMode Real > RealFloat RealFrac RelativeSeek > Prelude System.IO> openFile ".granule" ReadMode > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.3 for x86_64-apple-darwin): > nameModule > system $dShow_a1QJ > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in > ghc:Outputable > pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name > > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug}}} New description: {{{ ~ ✔︎ ghci GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/vl200/.ghci Prelude> :set -fdefer-type-errors Prelude> import System.IO Prelude System.IO> openFile ".granule" ReadWriteMode ghc: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-apple-darwin): nameModule system $dShow_a1QU Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} But works fine when I don't :set that option. {{{ ~ ✔︎ ghci GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/vl200/.ghci Prelude> import System.IO Prelude System.IO> openFile ".granule" ReadWriteMode {handle: .granule} Prelude System.IO> }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 15:04:53 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 15:04:53 -0000 Subject: [GHC] #15463: "Serious" validation failures on i686 In-Reply-To: <048.69c70a3c6d4c72255c91639c0649f11f@haskell.org> References: <048.69c70a3c6d4c72255c91639c0649f11f@haskell.org> Message-ID: <063.858129e04c97b8438e7141608a7c6c3f@haskell.org> #15463: "Serious" validation failures on i686 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: T3171, | heapprof001 Blocked By: | Blocking: Related Tickets: #15382, #15383 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate Comment: Closing this in favor of #15383 and #15382. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 16:33:44 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 16:33:44 -0000 Subject: [GHC] #16208: map/coerce does not fire with all newtypes In-Reply-To: <047.6e6dd4b904ee0227174b737189ff29c7@haskell.org> References: <047.6e6dd4b904ee0227174b737189ff29c7@haskell.org> Message-ID: <062.d6688775cc722a8ee0e62e46e30928d2@haskell.org> #16208: map/coerce does not fire with all newtypes -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/453 -------------------------------------+------------------------------------- Changes (by monoidal): * differential: https://gitlab.haskell.org/ghc/ghc/merge_requests/377 => https://gitlab.haskell.org/ghc/ghc/merge_requests/453 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 16:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 16:51:02 -0000 Subject: [GHC] #16368: Boot GHC's libffi installation path leaks into stage1 build Message-ID: <044.38913480b2d39b938b9ca61108202c99@haskell.org> #16368: Boot GHC's libffi installation path leaks into stage1 build -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Starting yesterday, I'm having problems building GHC from a `nix-shell --pure https://github.com/alpmestan/ghc.nix/archive/master.tar.gz`. Build comes to a halt after/while configuring the RTS, because it can't find libffi.h in a global nix store installation that I can't find anywhere in my `env`. That nix-store path certainly exists and has an installation of `libffi`, but without an include path (probably since recently, haven't had problems before). After some debugging, I figured out that this path leaks in through `ghc- cabal` crawling through the Package DB of the host GHC. These are the libraries it finds out about this way (dumped by inserting `putStrLn (unlines (forDeps Installed.includeDirs))` in line 388 of `utils/ghc- cabal/Main.hs`: {{{ /nix/store/7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/base-4.12.0.0/include /nix/store/5c9pfgazxid22ik3smh8zi805cp1i03y-gmp-6.1.2-dev/include /nix/store/7874h075nf8yikvr47642xqrwqwyv99s-ghc-8.6.3/lib/ghc-8.6.3 /integer-gmp-1.0.2.0/include /nix/store/7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/include /nix/store/karxq4hlfmfj0c3yk4wv5mfaz06p70k8-libffi-3.2.1/include }}} They are then passed on to `DEP_INCLUDE_DIRS_SINGLE_QUOTED` and wreak havoc from there. Which of these paths are vital? The `libffi` path at least seems to shadow the local tarballs for me. This concerns Hadrian and the Make-based build system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 17:16:17 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 17:16:17 -0000 Subject: [GHC] #16368: Boot GHC's libffi installation path leaks into stage1 build In-Reply-To: <044.38913480b2d39b938b9ca61108202c99@haskell.org> References: <044.38913480b2d39b938b9ca61108202c99@haskell.org> Message-ID: <059.a850281c6c7311887e3e325a5f105cf3@haskell.org> #16368: Boot GHC's libffi installation path leaks into stage1 build -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: bgamari (added) Comment: The `libffi` bit seems to be pulled in from `rts`, which itself isn't mentioned as include dir: {{{ {sourcePackageId = PackageIdentifier {pkgName = PackageName "rts", pkgVersion = mkVersion [1,0]}, sourceLibName = LMainLibName, installedComponentId_ = ComponentId "", installedUnitId = UnitId "rts", instantiatedWith = [], compatPackageKey = "rts", license = Left (License (ELicense (ELicenseId BSD_3_Clause) Nothing)), copyright = "", maintainer = "glasgow-haskell-users at haskell.org", author = "", stability = "", homepage = "", pkgUrl = "", synopsis = "", description = "", category = "", abiHash = AbiHash "", indefinite = False, exposed = True, exposedModules = [], hiddenModules = [], trusted = False, importDirs = [], libraryDirs = ["/nix/store/7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/rts","/nix/store/karxq4hlfmfj0c3yk4wv5mfaz06p70k8-libffi-3.2.1/lib"], libraryDynDirs = [], dataDir = "", hsLibraries = ["HSrts"], extraLibraries = ["m","rt","dl","ffi","pthread"], extraGHCiLibraries = [], includeDirs = ["/nix/store/7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/include","/nix/store/karxq4hlfmfj0c3yk4wv5mfaz06p70k8-libffi-3.2.1/include"], includes = ["Stg.h"], depends = [], abiDepends = [], ccOptions = [], cxxOptions = [], ldOptions = [], frameworkDirs = [], frameworks = [], haddockInterfaces = [], haddockHTMLs = [], pkgRoot = Just "/nix/store /23ndnrb11m3k7zh4p84vjmdgand0p45b-ghc-8.6.3-with-packages/lib/ghc-8.6.3", libVisibility = LibraryVisibilityPrivate} }}} I could probably fix this by the following patch: {{{#!diff diff --git a/utils/ghc-cabal/Main.hs b/utils/ghc-cabal/Main.hs index 8b776499fd..f4a2313194 100644 --- a/utils/ghc-cabal/Main.hs +++ b/utils/ghc-cabal/Main.hs @@ -338,14 +338,22 @@ generate directory distdir config_args [(_,[rts])] -> PackageIndex.insert rts{ Installed.ldOptions = [], - Installed.libraryDirs = filter (not . ("gcc-lib" `isSuffixOf`)) (Installed.libraryDirs rts)} index - -- GHC <= 6.12 had $topdir/gcc-lib in their - -- library-dirs for the rts package, which causes - -- problems when we try to use the in-tree mingw, - -- due to accidentally picking up the incompatible - -- libraries there. So we filter out gcc-lib from - -- the RTS's library-dirs here. + Installed.libraryDirs = filter_dirs (Installed.libraryDirs rts), + Installed.includeDirs = filter_dirs (Installed.includeDirs rts) + } index _ -> error "No (or multiple) ghc rts package is registered!!" + filter_dirs = filter (\dir -> not (or [is_gcc_lib dir, is_libffi dir])) + -- GHC <= 6.12 had $topdir/gcc-lib in their + -- library-dirs for the rts package, which causes + -- problems when we try to use the in-tree mingw, + -- due to accidentally picking up the incompatible + -- libraries there. So we filter out gcc-lib from + -- the RTS's library-dirs here. + is_gcc_lib = ("gcc-lib" `isSuffixOf`) + -- In Trac #16368, we noticed that libffi paths + -- from the boot GHC shadow the local libffi tarballs + -- in a similar manner. + is_libffi = ("libffi" `isInfixOf`) dep_ids = map snd (externalPackageDeps lbi) deps = map display dep_ids }}} Are there any other packages in the above list that look from to you? bgamari, perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 17:38:08 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 17:38:08 -0000 Subject: [GHC] #16368: Boot GHC's libffi installation path leaks into stage1 build In-Reply-To: <044.38913480b2d39b938b9ca61108202c99@haskell.org> References: <044.38913480b2d39b938b9ca61108202c99@haskell.org> Message-ID: <059.8e74f2348e584fe8cd0c39d7ba1446b4@haskell.org> #16368: Boot GHC's libffi installation path leaks into stage1 build -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > Starting yesterday, I'm having problems building GHC from a `nix-shell > --pure https://github.com/alpmestan/ghc.nix/archive/master.tar.gz`. > > Build comes to a halt after/while configuring the RTS, because it can't > find libffi.h in a global nix store installation that I can't find > anywhere in my `env`. That nix-store path certainly exists and has an > installation of `libffi`, but without an include path (probably since > recently, haven't had problems before). > > After some debugging, I figured out that this path leaks in through `ghc- > cabal` crawling through the Package DB of the host GHC. These are the > libraries it finds out about this way (dumped by inserting `putStrLn > (unlines (forDeps Installed.includeDirs))` in line 388 of `utils/ghc- > cabal/Main.hs`: > > {{{ > /nix/store/7874h075nf8yikvr47642xqrwqwyv99s- > ghc-8.6.3/lib/ghc-8.6.3/base-4.12.0.0/include > /nix/store/5c9pfgazxid22ik3smh8zi805cp1i03y-gmp-6.1.2-dev/include > /nix/store/7874h075nf8yikvr47642xqrwqwyv99s-ghc-8.6.3/lib/ghc-8.6.3 > /integer-gmp-1.0.2.0/include > /nix/store/7874h075nf8yikvr47642xqrwqwyv99s- > ghc-8.6.3/lib/ghc-8.6.3/include > /nix/store/karxq4hlfmfj0c3yk4wv5mfaz06p70k8-libffi-3.2.1/include > }}} > > They are then passed on to `DEP_INCLUDE_DIRS_SINGLE_QUOTED` and wreak > havoc from there. > > Which of these paths are vital? The `libffi` path at least seems to > shadow the local tarballs for me. This concerns Hadrian and the Make- > based build system. New description: Starting yesterday, I'm having problems building GHC from a `nix-shell --pure https://github.com/alpmestan/ghc.nix/archive/master.tar.gz`. Build comes to a halt after/while configuring the RTS, because it can't find libffi.h in a global nix store installation that I can't find anywhere in my `env`. That nix-store path certainly exists and has an installation of `libffi`, but without an include path (probably since recently, haven't had problems before). After some debugging, I figured out that this path leaks in through `ghc- cabal` crawling through the Package DB of the host GHC. These are the libraries it finds out about this way (dumped by inserting `putStrLn (unlines (forDeps Installed.includeDirs))` in line 388 of `utils/ghc- cabal/Main.hs`: {{{ /nix/store/7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/base-4.12.0.0/include /nix/store/5c9pfgazxid22ik3smh8zi805cp1i03y-gmp-6.1.2-dev/include /nix/store/7874h075nf8yikvr47642xqrwqwyv99s-ghc-8.6.3/lib/ghc-8.6.3 /integer-gmp-1.0.2.0/include /nix/store/7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/include /nix/store/karxq4hlfmfj0c3yk4wv5mfaz06p70k8-libffi-3.2.1/include }}} They are then passed on to `DEP_INCLUDE_DIRS_SINGLE_QUOTED` and wreak havoc from there. Which of these paths are vital? The `libffi` path at least seems to shadow the local tarballs for me. This concerns Hadrian and the Make-based build system. For completeness, this is the error I'm eventually seeing: {{{ FFI.hsc:9:10: fatal error: ffi.h: No such file or directory compilation terminated. compiling _build/stage0/libraries/ghci/build/GHCi/FFI_hsc_make.c failed (exit code 1) command was: /nix/store/8zfm4i1aw4c3l5n6ay311ds6l8vd9983-gcc- wrapper-7.4.0/bin/cc -c _build/stage0/libraries/ghci/build/GHCi/FFI_hsc_make.c -o _build/stage0/libraries/ghci/build/GHCi/FFI_hsc_make.o -I/nix/store/891h83mar65k138156v41kzryc9ij0v3-ghc-build- environment/include -I_build/generated -I_build/stage0/libraries/ghci/build -I/nix/store/891h83mar65k138156v41kzryc9ij0v3-ghc-build- environment/include -I/nix/store/7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/unix-2.7.2.2/include -I/nix/store /7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/time-1.8.0.2/include -I/nix/store /7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/bytestring-0.10.8.2/include -I/nix/store /7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/base-4.12.0.0/include -I/nix/store /5c9pfgazxid22ik3smh8zi805cp1i03y-gmp-6.1.2-dev/include -I/nix/store /7874h075nf8yikvr47642xqrwqwyv99s-ghc-8.6.3/lib/ghc-8.6.3/integer- gmp-1.0.2.0/include -I/nix/store/7874h075nf8yikvr47642xqrwqwyv99s- ghc-8.6.3/lib/ghc-8.6.3/include -I/nix/store/karxq4hlfmfj0c3yk4wv5mfaz06p70k8-libffi-3.2.1/include -Wall -Werror=unused-but-set-variable -Wno-error=inline -include _build/stage0/libraries/ghci/build/autogen/cabal_macros.h -Dx86_64_HOST_ARCH=1 -Dlinux_HOST_OS=1 -D__GLASGOW_HASKELL__=806 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 17:45:04 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 17:45:04 -0000 Subject: [GHC] #16363: Modular constant folding In-Reply-To: <045.a4a4cac9ce41785be0aa7ca965d6a043@haskell.org> References: <045.a4a4cac9ce41785be0aa7ca965d6a043@haskell.org> Message-ID: <060.2dad989465ed25a239484bfd3d194fdf@haskell.org> #16363: Modular constant folding -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > The following code (taken from #16329): > > {{{#!hs > func :: Int -> IO Int > func n = foldM step 0 xs > where > xs = map (n+) [1,2,3] > step acc x = > case x `mod` 3 of > 0 -> pure acc > 1 -> pure $ acc + 1 > 2 -> pure $ acc + 2 > > func' n = foldl step 0 xs > where > xs = map (n+) [1,2,3] > step acc x = > case x `mod` 3 of > 0 -> acc > 1 -> acc + 1 > 2 -> acc + 2 > }}} > > is simplified to the following core code: > > {{{#!hs > func n = > case n + 1 `mod` 3 of > 0 -> case n + 2 `mod` 3 of > 0 -> case n + 3 `mod` 3 of > 0 -> pure 0 > 1 -> pure 1 > 2 -> pure 2 > 1 -> case n + 3 `mod` 3 of > 0 -> pure 1 > 1 -> pure 2 > 2 -> pure 3 > 2 -> case n + 3 `mod` 3 of > 0 -> pure 2 > 1 -> pure 3 > 2 -> pure 4 > 1 -> case n + 2 `mod` 3 of > 0 -> case n + 3 `mod` 3 of > 0 -> pure 1 > 1 -> pure 2 > 2 -> pure 3 > 1 -> case n + 3 `mod` 3 of > 0 -> pure 2 > 1 -> pure 3 > 2 -> pure 4 > 2 -> case n + 3 `mod` 3 of > 0 -> pure 3 > 1 -> pure 4 > 2 -> pure 5 > 2 -> case n + 2 `mod` 3 of > 0 -> case n + 3 `mod` 3 of > 0 -> pure 2 > 1 -> pure 3 > 2 -> pure 4 > 1 -> case n + 3 `mod` 3 of > 0 -> pure 3 > 1 -> pure 4 > 2 -> pure 5 > 2 -> case n + 3 `mod` 3 of > 0 -> pure 4 > 1 -> pure 5 > 2 -> pure 6 > > func' n = > join j2 w2 = > join j1 w1 = > case n + 3 `mod` 3 of > 0 -> w1 > 1 -> w1 + 1 > 2 -> w1 + 2 > in case n + 2 `mod` 3 of > 0 -> jump j1 w2 > 1 -> jump j1 (w2 + 1) > 2 -> jump j1 (w2 + 2) > in case n + 1 `mod` 3 of > 0 -> jump j2 0 > 1 -> jump j2 1 > 2 -> jump j2 2 > }}} > > Case-folding with modular arithmetic should remove the nesting. > > (patch coming) New description: The following code (taken from #16329): {{{#!hs func :: Int -> IO Int func n = foldM step 0 xs where xs = map (n+) [1,2,3] step acc x = case x `mod` 3 of 0 -> pure acc 1 -> pure $ acc + 1 2 -> pure $ acc + 2 func' n = foldl step 0 xs where xs = map (n+) [1,2,3] step acc x = case x `mod` 3 of 0 -> acc 1 -> acc + 1 2 -> acc + 2 }}} is simplified to the following core code: {{{#!hs func n = case n + 1 `mod` 3 of 0 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 0 1 -> pure 1 2 -> pure 2 1 -> case n + 3 `mod` 3 of 0 -> pure 1 1 -> pure 2 2 -> pure 3 2 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 1 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 1 1 -> pure 2 2 -> pure 3 1 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 2 -> case n + 3 `mod` 3 of 0 -> pure 3 1 -> pure 4 2 -> pure 5 2 -> case n + 2 `mod` 3 of 0 -> case n + 3 `mod` 3 of 0 -> pure 2 1 -> pure 3 2 -> pure 4 1 -> case n + 3 `mod` 3 of 0 -> pure 3 1 -> pure 4 2 -> pure 5 2 -> case n + 3 `mod` 3 of 0 -> pure 4 1 -> pure 5 2 -> pure 6 func' n = join j2 w2 = join j1 w1 = case n + 3 `mod` 3 of 0 -> w1 1 -> w1 + 1 2 -> w1 + 2 in case n + 2 `mod` 3 of 0 -> jump j1 w2 1 -> jump j1 (w2 + 1) 2 -> jump j1 (w2 + 2) in case n + 1 `mod` 3 of 0 -> jump j2 0 1 -> jump j2 1 2 -> jump j2 2 }}} Case-folding with modular arithmetic should remove the nesting. (patch coming) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 20:05:29 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 20:05:29 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.d79153bad89626afa572261720086e00@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): The problem with mc is that we can get assembly with CPP directives in it: {{{ 8:52 PM AndreasK> bgamari: our generated assembly contains CPP directives? 8:55 PM no, but a TH splice may have added an assembler source file that does }}} We could (depending on the backend used) invoke gcc on the generated assembly just for CPP and the pass the result on to as/llvm-mc depending on the backend. {{{ AndreasK> bgamari: We could pipe assembly through the gcc CPP, and then pipe the result through as/llvm-mc depending on backend though right? 9:00 PM AndreasK, yes 9:00 PM we already have support for invoking the preprocessor 9:00 PM so really this is likely just a matter of plumbing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 26 20:07:33 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 26 Feb 2019 20:07:33 -0000 Subject: [GHC] #16354: LLVM Backend generates invalid assembly. In-Reply-To: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> References: <047.faeafddad31355af7eb71c7cbcc9d079@haskell.org> Message-ID: <062.d36973bdb6043fae8eba201a278581f5@haskell.org> #16354: LLVM Backend generates invalid assembly. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (LLVM) | Version: 8.9 Resolution: | Keywords: CodeGen Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: upstream => new Comment: Given that LLVM will likely keep things specific to their assembler when it suits them I don't think we can count on this being resolved through upstream changes. So I'm reopening this. Just needs someone to dive into the plumbing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 12:32:51 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 12:32:51 -0000 Subject: [GHC] #16369: Implement testing of stage1 in ./validate --hadrian Message-ID: <048.d819d3467016f58604eba31e11eee83e@haskell.org> #16369: Implement testing of stage1 in ./validate --hadrian -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: task | Status: new Priority: high | Milestone: Component: Build System | Version: 8.7 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While `master` doesn't support `./validate --hadrian` yet, most of that patch is ready in [https://gitlab.haskell.org/ghc/ghc/merge_requests/326 !326] and will be split up in a few MRs to make review & landing easier. However, it doesn't yet implement testing of the stage 1 compiler, just stage 2. This ticket serves as a reminder to implement testing of stage 1 with hadrian in the validate script. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 15:32:03 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 15:32:03 -0000 Subject: [GHC] #16334: Named wildcards in kinds In-Reply-To: <048.1c12b4f97b648562a3f1fdca2d35171a@haskell.org> References: <048.1c12b4f97b648562a3f1fdca2d35171a@haskell.org> Message-ID: <063.c0b3fefe4e68c84e9a99d80df63030e2@haskell.org> #16334: Named wildcards in kinds -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.4.4 checker) | Keywords: Resolution: fixed | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T16334 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/361 -------------------------------------+------------------------------------- Changes (by int-index): * status: patch => closed * testcase: => T16334 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 15:33:21 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 15:33:21 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.ef20ac18e5231b6fb89adf250e1030a1@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 15:34:07 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 15:34:07 -0000 Subject: [GHC] #16334: Named wildcards in kinds In-Reply-To: <048.1c12b4f97b648562a3f1fdca2d35171a@haskell.org> References: <048.1c12b4f97b648562a3f1fdca2d35171a@haskell.org> Message-ID: <063.ba3da737812eb6356ff39c0e6bcf2de1@haskell.org> #16334: Named wildcards in kinds -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.4.4 checker) | Keywords: Resolution: fixed | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T16334 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/361 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 15:34:25 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 15:34:25 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.c0bac87243bfa965727dc66db441a55b@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/361 -------------------------------------+------------------------------------- Changes (by int-index): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/361 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 15:40:05 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 15:40:05 -0000 Subject: [GHC] #16315: Pattern synonym implicit existential quantification In-Reply-To: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> References: <048.4464c2a5f3e5b58b1c8cf0f7bb1b3827@haskell.org> Message-ID: <063.8cfdddc91057e0e32903475f3cb773e9@haskell.org> #16315: Pattern synonym implicit existential quantification -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_compile/T14498 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/361 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => patsyn/should_compile/T14498 * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:04:33 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:04:33 -0000 Subject: [GHC] #16356: Unexpected type application in default declaration In-Reply-To: <048.490e0ffbb02cb85e19f1ed70f4403000@haskell.org> References: <048.490e0ffbb02cb85e19f1ed70f4403000@haskell.org> Message-ID: <063.831d9f966ddbe73550fa68cfcb2bd252@haskell.org> #16356: Unexpected type application in default declaration -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 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 RyanGlScott): Upon further thought, I downplayed the amount of effort required to make this work in comment:1. [https://gitlab.haskell.org/ghc/ghc/blob/2e8f664957dc3763dc4375894b8dc4d046d2e95b/compiler/typecheck/TcTyClsDecls.hs#L1401-1419 This code] in `TcTyClsDecls.tcDefaultAssocDecl` is problematic: {{{#!hs tcDefaultAssocDecl fam_tc [dL->L loc (FamEqn { feqn_tycon = L _ tc_name , feqn_pats = hs_tvs , feqn_rhs = hs_rhs_ty })] | HsQTvs { hsq_ext = HsQTvsRn { hsq_implicit = imp_vars} , hsq_explicit = exp_vars } <- hs_tvs = -- fam_arity = length (tyConVisibleTyVars fam_tc) -- -- Arity check ; checkTc (exp_vars `lengthIs` fam_arity) (wrongNumberOfParmsErr fam_arity) }}} Unless the number of `exp_vars` is exactly the number of visible arguments that the type family expects, then `wrongNumberOfParmsErr` will throw an error. Unfortunately, it turns out that `exp_vars` //includes// visible kind arguments! In other words, if you have this: {{{#!hs class FAssocDefaultClass k where type FAssocDefault :: k -> Type type FAssocDefault @k = B @k }}} Then `exp_vars = [k]` and `fam_arity = 0`, which means that GHC will mistakenly reject `FAssocDefault` under the guise that it supplies too many arguments. ----- Why, then, does this problem not occur for ordinary type family equations? It turns out that it's because GHC stores the ASTs for each form of declaration in subtly different ways. [https://gitlab.haskell.org/ghc/ghc/blob/2e8f664957dc3763dc4375894b8dc4d046d2e95b/compiler/hsSyn/HsDecls.hs#L1618-1619 This] is how GHC represents ordinary type family equations: {{{#!hs type FamInstEqn pass rhs = HsImplicitBndrs pass (FamEqn pass (HsTyPats pass) rhs) }}} And [https://gitlab.haskell.org/ghc/ghc/blob/2e8f664957dc3763dc4375894b8dc4d046d2e95b/compiler/hsSyn/HsDecls.hs#L1581 this] is how GHC represents associated type family defaults: {{{#!hs type TyFamDefltEqn pass = FamEqn pass (LHsQTyVars pass) (LHsType pass) }}} The important bit here is the second argument to `FamEqn`, which represents the patterns in the type family equation. In `FamInstEqn`s, the patterns are `HsTyPats`, which distinguish between ordinary arguments and visible kind arguments. In `TyFamDefltEqn`, however, the patterns are `LHsQTyVars`. AFAICT, `LHsQTyVars` do not make any sort of distinction between ordinary arguments and visible kind arguments, instead only caring about explicitly vs. implicitly quantified variables. ----- How, then, should we change things to allow VKAs in type family defaults? One option is to try switching out `LHsQTyVars` for `HsTyPats` in `TyFamDefltEqn`. I'm not clear as to why we're using `LHsQTyVars` in the first place, however, so it's possible that there actually is a good reason for its existence here. If so, another alternative would be to somehow augment `LHsQTyVars` with informative about which of its arguments are VKAs or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:13:32 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:13:32 -0000 Subject: [GHC] #16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs. In-Reply-To: <045.8eb38d70bd471e68bc3fb492881a0e06@haskell.org> References: <045.8eb38d70bd471e68bc3fb492881a0e06@haskell.org> Message-ID: <060.2dbbe0944b2572013f7d44751a7d225d@haskell.org> #16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs. -------------------------------------+------------------------------------- Reporter: hanrai | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | getCurrentDirectory Blocked By: | Blocking: Related Tickets: #14963, #16080 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #16080 => #14963, #16080 Comment: Here is how to reproduce this: {{{ $ /opt/ghc/8.4.4/bin/ghci -fdefer-type-errors GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import System.Directory λ> getCurrentDirectory ghc: panic! (the 'impossible' happened) (GHC version 8.4.4 for x86_64-unknown-linux): nameModule system $dShow_a2lk Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name }}} Given that this is not reproducible with GHC 8.6, this is almost assuredly a duplicate of #14963, so I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:14:19 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:14:19 -0000 Subject: [GHC] #16367: Panic when trying to openFile with -fdefer-type-errors In-Reply-To: <044.8e2cb7e79ae10a79b9287a5e4158d759@haskell.org> References: <044.8e2cb7e79ae10a79b9287a5e4158d759@haskell.org> Message-ID: <059.24b63312d14f983672548d234f63f693@haskell.org> #16367: Panic when trying to openFile with -fdefer-type-errors ----------------------------------+-------------------------------------- Reporter: vilem | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.4.4 Resolution: duplicate | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #14963 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14963 Comment: Thanks for the bug report. This is a duplicate of #14963, so closing. It's worth noting that this issue no longer occurs in GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:14:32 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:14:32 -0000 Subject: [GHC] #16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs. In-Reply-To: <045.8eb38d70bd471e68bc3fb492881a0e06@haskell.org> References: <045.8eb38d70bd471e68bc3fb492881a0e06@haskell.org> Message-ID: <060.88c6631d4c45233d88378432b777f533@haskell.org> #16088: The 'impossible' happened when I was trying to use getCurrentDirectory in repl in spacemacs. -------------------------------------+------------------------------------- Reporter: hanrai | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: | getCurrentDirectory Blocked By: | Blocking: Related Tickets: #14963, #16080 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:14:51 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:14:51 -0000 Subject: [GHC] #16080: runTestTT from ghci caused a panic. In-Reply-To: <053.34b4d518efefb7683003b02513dac18d@haskell.org> References: <053.34b4d518efefb7683003b02513dac18d@haskell.org> Message-ID: <068.6da12666953952fc30546206d7291c90@haskell.org> #16080: runTestTT from ghci caused a panic. -------------------------------------+------------------------------------- Reporter: emacstheviking | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #14963, #16088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: #16088 => #14963, #16088 Comment: Thanks for the bug report. This is a duplicate of #14963, so closing. It's worth noting that this issue no longer occurs in GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:15:06 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:15:06 -0000 Subject: [GHC] #15755: randomRIO panic on (GHC version 8.4.3 for x86_64-apple-darwin) In-Reply-To: <043.d99d803d2e9b59ef17275c0dcbc2174a@haskell.org> References: <043.d99d803d2e9b59ef17275c0dcbc2174a@haskell.org> Message-ID: <058.8b17826c455c30dceb39a799effa2847@haskell.org> #15755: randomRIO panic on (GHC version 8.4.3 for x86_64-apple-darwin) -------------------------------------+------------------------------------- Reporter: cmal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: duplicate | Keywords: randomRIO Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => duplicate * related: => #14963 Comment: Thanks for the bug report. This is a duplicate of #14963, so closing. It's worth noting that this issue no longer occurs in GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:24:14 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:24:14 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.be9fc1c2cd77ec7f3d77023e0667ce89@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | VisibleDependentQuantification Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType => TypeInType, VisibleDependentQuantification Comment: Visible dependent quantification provides another workaround for this issue: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} module Foo where import Data.Kind data A :: Type -> Type data B a :: A a -> Type type C = (B :: forall a -> A a -> Type) }}} This workaround is mildly more tolerable, since it doesn't rely on `ImpredicativeTypes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:26:06 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:26:06 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.7955bb630ae782fb330076c7ab831400@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType, | VisibleDependentQuantification Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType => TypeInType, VisibleDependentQuantification Comment: Here is how to trigger the same issue using visible dependent quantification: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind type family F a data Ex (x :: forall a -> F a -> Type) }}} {{{ GHCi, version 8.9.20190227: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:10:1: error: • Couldn't match type ‘F a’ with ‘F a0’ Expected type: F a -> * Actual type: F a0 -> * NB: ‘F’ is a non-injective type family The type variable ‘a0’ is ambiguous • In the ambiguity check for the kind annotation on the type variable ‘x’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the data type declaration for ‘Ex’ | 10 | data Ex (x :: forall a -> F a -> Type) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:26:32 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:26:32 -0000 Subject: [GHC] #15658: strange inferred kind with TypeInType In-Reply-To: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> References: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> Message-ID: <059.f8d7feb3eaea3e8fca7e624f532dee7d@haskell.org> #15658: strange inferred kind with TypeInType -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: TypeInType, | GHCProposal, | VisibleDependentQuantification Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #16326 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/378 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeInType, GHCProposal => TypeInType, GHCProposal, VisibleDependentQuantification -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:27:15 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:27:15 -0000 Subject: [GHC] #15869: Discrepancy between seemingly equivalent type synonym and type family In-Reply-To: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> References: <050.680b0785c27e4d6b7900b0b3355c0c2c@haskell.org> Message-ID: <065.a39987924ec56fe23f577829a056bf58@haskell.org> #15869: Discrepancy between seemingly equivalent type synonym and type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.2 checker) | Keywords: TypeFamilies, Resolution: | TypeInType, | VisibleDependentQuantification Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: TypeFamilies, TypeInType => TypeFamilies, TypeInType, VisibleDependentQuantification -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:28:02 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:28:02 -0000 Subject: [GHC] #16326: Implement visible dependent quantification In-Reply-To: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> References: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> Message-ID: <065.4f9331dbe920cac6f3f65be1d010b7b7@haskell.org> #16326: Implement visible dependent quantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: GHCProposal, | VisibleDependentQuantification Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15658 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/378 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: GHCProposal => GHCProposal, VisibleDependentQuantification -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:45:41 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:45:41 -0000 Subject: [GHC] #16370: Hadrian: test T3807 failure Message-ID: <045.e450a30493d0d646dc7fd35562073ab1@haskell.org> #16370: Hadrian: test T3807 failure -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building with hadrian, test T3807 fails with a linker error. The test's Makefile attempts to link with the RTS: {{{ # testsuite/tests/dynlibs/Makefile : 12 '$(TEST_HC)' $(filter-out -rtsopts,$(TEST_HC_OPTS)) -v0 --make -dynamic -fPIC -shared T3807Export.hs T3807-export.c -o T3807test.so -lHSrts- ghc`'$(TEST_HC)' $(TEST_HC_OPTS) --numeric-version` }}} In particular, this will result in the following linker option that causes the failure (assuming ghc version 8.9.0): {{{ -lHSrts-ghc8.9.0 }}} In Hadrian, unlike in make, the RTS library file includes the (dummy) version number, so the required linker option would actually be: {{{ -lHSrts-1.0-ghc8.9.0 }}} While it's possible to try and match makes behavior by removing the dummy version from the file names (I've started on that [https://gitlab.haskell.org/DavidEichmann/ghc/commit/f1106d1302e8d4f42778e3df19725fb9c767bccf here]), a further complication arises. Hadrian tries to copy relevant library files using cabal-install's `cabal copy` command. Cabal expects the "1.0" version number to be present and so will fail. In summary, the naming conventions between Hadrian and Cabal would conflict if Hadrian dropped the "1.0" version number for the RTS library files. Some ideas on how to resolve this: 1. Drop the RTS version number in Hadrian and patch Cabal as well. * Cabal may need a special case for the RTS. * Or is there a better alternative? 2. Keep the RTS version number, but create syslinks of the library files without the RTS version number to allow backwards compatibility. 3. Something else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:46:42 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:46:42 -0000 Subject: [GHC] #16371: GHC should be more forgiving with visible dependent quantification in visible type applications Message-ID: <050.6c98426f3f9acd5c8e54047edf9246ee@haskell.org> #16371: GHC should be more forgiving with visible dependent quantification in visible type applications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.9 (Type checker) | Keywords: | Operating System: Unknown/Multiple VisibleDependentQuantification | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC HEAD currently rejects the following code: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} module Bug where import Data.Kind import Data.Proxy f :: forall k a. Proxy a f = Proxy g :: forall (a :: forall x -> x -> Type). Proxy a g = f @(forall x -> x -> Type) @a }}} {{{ GHCi, version 8.9.20190227: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:14:6: error: • Illegal visible, dependent quantification in the type of a term: forall x -> x -> * (GHC does not yet support this) • In the type signature: g :: forall (a :: forall x -> x -> Type). Proxy a | 14 | g :: forall (a :: forall x -> x -> Type). Proxy a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But GHC is being too conservative here. `forall x -> x -> *` //isn't// the type of a term here, but rather the kind of a type variable, and it's perfectly admissible to use visible dependent quantification in such a scenario. The immediate reason that this happens is because of this code: {{{#!hs vdqAllowed (TypeAppCtxt {}) = False }}} Unfortunately, fixing this bug isn't as simply as changing `False` to `True`. If you do that, then GHC becomes //too// forgiving and allows things like this: {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeApplications #-} lol :: forall a. a lol = undefined t2 = lol @(forall a -> a -> a) }}} Here, visible dependent quantification is leaking into the type of a term, which we definitely don't want to happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 27 16:52:18 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 27 Feb 2019 16:52:18 -0000 Subject: [GHC] #16370: Hadrian: test T3807 failure In-Reply-To: <045.e450a30493d0d646dc7fd35562073ab1@haskell.org> References: <045.e450a30493d0d646dc7fd35562073ab1@haskell.org> Message-ID: <060.1005c64cece119bfad9014bbe63983fb@haskell.org> #16370: Hadrian: test T3807 failure -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * owner: (none) => davide * cc: alpmestan, snowleopard, angerman, bgamari (added) Old description: > When building with hadrian, test T3807 fails with a linker error. The > test's Makefile attempts to link with the RTS: > > {{{ > # testsuite/tests/dynlibs/Makefile : 12 > '$(TEST_HC)' $(filter-out -rtsopts,$(TEST_HC_OPTS)) -v0 --make -dynamic > -fPIC -shared T3807Export.hs T3807-export.c -o T3807test.so -lHSrts- > ghc`'$(TEST_HC)' $(TEST_HC_OPTS) --numeric-version` > }}} > > In particular, this will result in the following linker option that > causes the failure (assuming ghc version 8.9.0): > > {{{ > -lHSrts-ghc8.9.0 > }}} > > In Hadrian, unlike in make, the RTS library file includes the (dummy) > version number, so the required linker option would actually be: > > {{{ > -lHSrts-1.0-ghc8.9.0 > }}} > > While it's possible to try and match makes behavior by removing the dummy > version from the file names (I've started on that > [https://gitlab.haskell.org/DavidEichmann/ghc/commit/f1106d1302e8d4f42778e3df19725fb9c767bccf > here]), a further complication arises. Hadrian tries to copy relevant > library files using cabal-install's `cabal copy` command. Cabal expects > the "1.0" version number to be present and so will fail. In summary, the > naming conventions between Hadrian and Cabal would conflict if Hadrian > dropped the "1.0" version number for the RTS library files. > > Some ideas on how to resolve this: > > 1. Drop the RTS version number in Hadrian and patch Cabal as well. > * Cabal may need a special case for the RTS. > * Or is there a better alternative? > 2. Keep the RTS version number, but create syslinks of the library files > without the RTS version number to allow backwards compatibility. > 3. Something else? New description: When building with hadrian, test T3807 fails with a linker error. The test's Makefile attempts to link with the RTS: {{{ # testsuite/tests/dynlibs/Makefile : 12 '$(TEST_HC)' $(filter-out -rtsopts,$(TEST_HC_OPTS)) -v0 --make -dynamic -fPIC -shared T3807Export.hs T3807-export.c -o T3807test.so -lHSrts- ghc`'$(TEST_HC)' $(TEST_HC_OPTS) --numeric-version` }}} In particular, this will result in the following linker option that causes the failure (assuming ghc version 8.9.0): {{{ -lHSrts-ghc8.9.0 }}} In Hadrian, unlike in make, the RTS library file includes the (dummy) version number, so the required linker option would actually be: {{{ -lHSrts-1.0-ghc8.9.0 }}} While it's possible to try and match makes behavior by removing the dummy version from the file names (I've started on that [https://gitlab.haskell.org/DavidEichmann/ghc/commit/f1106d1302e8d4f42778e3df19725fb9c767bccf here]), a further complication arises. Hadrian tries to copy relevant library files using cabal-install's `cabal copy` command. Cabal expects the "1.0" version number to be present and so will fail. In summary, the naming conventions between Hadrian and Cabal would conflict if Hadrian dropped the "1.0" version number for the RTS library files. The correct way to resolve this is unclear. 2 Ideas are: 1. Drop the RTS version number in Hadrian and patch Cabal as well. * Cabal may need a special case for the RTS. * Or is there a better alternative? 2. Keep the RTS version number, but create syslinks of the library files without the RTS version number to allow backwards compatibility with code that links with the rts. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 28 09:28:11 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Feb 2019 09:28:11 -0000 Subject: [GHC] #16372: GHC can't constant fold even basic power (^) applications for Int (and others?) Message-ID: <047.b8f340588e4c20e11e7f8a77364e7386@haskell.org> #16372: GHC can't constant fold even basic power (^) applications for Int (and others?) -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- {{{#!hs [nix-shell:/tmp]$ ghc -O2 -fforce-recomp -ddump-simpl S.hs 2>&1 | tail [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 50 20}] foo = case GHC.Real.$wf1 2# 1# of ww2_a2zt { __DEFAULT -> GHC.Types.I# ww2_a2zt } [nix-shell:/tmp]$ cat S.hs module S (fuck) where foo :: Int foo = (2 :: Int) ^ (1 :: Int) }}} This seems like a fairly strange thing to not optimise when constants are known on both sides. I'm complaining about Int for this particular ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 28 09:28:23 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Feb 2019 09:28:23 -0000 Subject: [GHC] #16372: GHC can't constant fold even basic power (^) applications for Int (and others?) In-Reply-To: <047.b8f340588e4c20e11e7f8a77364e7386@haskell.org> References: <047.b8f340588e4c20e11e7f8a77364e7386@haskell.org> Message-ID: <062.221bd1cec890611bc5db13f9881d9144@haskell.org> #16372: GHC can't constant fold even basic power (^) applications for Int (and others?) -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Fuuzetsu: Old description: > {{{#!hs > [nix-shell:/tmp]$ ghc -O2 -fforce-recomp -ddump-simpl S.hs 2>&1 | tail > [GblId, > Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, > WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 50 20}] > foo > = case GHC.Real.$wf1 2# 1# of ww2_a2zt { __DEFAULT -> > GHC.Types.I# ww2_a2zt > } > > [nix-shell:/tmp]$ cat S.hs > module S (fuck) where > foo :: Int > foo = (2 :: Int) ^ (1 :: Int) > }}} > > This seems like a fairly strange thing to not optimise when constants are > known on both sides. I'm complaining about Int for this particular > ticket. New description: {{{#!hs [nix-shell:/tmp]$ ghc -O2 -fforce-recomp -ddump-simpl S.hs 2>&1 | tail [GblId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 50 20}] foo = case GHC.Real.$wf1 2# 1# of ww2_a2zt { __DEFAULT -> GHC.Types.I# ww2_a2zt } [nix-shell:/tmp]$ cat S.hs module S (foo) where foo :: Int foo = (2 :: Int) ^ (1 :: Int) }}} This seems like a fairly strange thing to not optimise when constants are known on both sides. I'm complaining about Int for this particular ticket. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 28 10:51:04 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Feb 2019 10:51:04 -0000 Subject: [GHC] #9121: Presence of dyn_o files not checked upon recompilation In-Reply-To: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> References: <051.ef4d284e4c39d225b3b91119dd74ee0d@haskell.org> Message-ID: <066.912edb00a4ba445f77ffeab2ffffbce1@haskell.org> #9121: Presence of dyn_o files not checked upon recompilation -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * cc: adamse (added) Comment: Still an issue in 8.6.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 28 12:06:19 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Feb 2019 12:06:19 -0000 Subject: [GHC] #16372: GHC can't constant fold even basic power (^) applications for Int (and others?) In-Reply-To: <047.b8f340588e4c20e11e7f8a77364e7386@haskell.org> References: <047.b8f340588e4c20e11e7f8a77364e7386@haskell.org> Message-ID: <062.f6606836b649dba6de1a767cd5a93483@haskell.org> #16372: GHC can't constant fold even basic power (^) applications for Int (and others?) -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): For the record, currently `(^)` is defined as: {{{#!hs -- | raise a number to a non-negative integral power {-# SPECIALISE [1] (^) :: Integer -> Integer -> Integer, Integer -> Int -> Integer, Int -> Int -> Int #-} {-# INLINABLE [1] (^) #-} -- See Note [Inlining (^)] (^) :: (Num a, Integral b) => a -> b -> a x0 ^ y0 | y0 < 0 = errorWithoutStackTrace "Negative exponent" | y0 == 0 = 1 | otherwise = f x0 y0 where -- f : x0 ^ y0 = x ^ y f x y | even y = f (x * x) (y `quot` 2) | y == 1 = x | otherwise = g (x * x) (y `quot` 2) x -- See Note [Half of y - 1] -- g : x0 ^ y0 = (x ^ y) * z g x y z | even y = g (x * x) (y `quot` 2) z | y == 1 = x * z | otherwise = g (x * x) (y `quot` 2) (x * z) -- See Note [Half of y - 1] {- Note [Half of y - 1] ~~~~~~~~~~~~~~~~~~~~~ Since y is guaranteed to be odd and positive here, half of y - 1 can be computed as y `quot` 2, optimising subtraction away. -} }}} To perform constant folding, it would be better to have primitives such as: {{{#!hs ipowInt :: Int# -> Int# -> Int# ipowWord :: Word# -> Word# -> Word# }}} that we can match on in Core. Then we could add `(^)` as a method of `Num a`, change its type to be `(^) :: a -> a -> a` and use the appropriate primitives (or fall back to the generic implementation otherwise). Exactly like we do for other primitives. Changing the type of `(^)` is a breaking change but it shouldn't harm much. It needs the approval of the CLC though. ------ By the way, the generic implementation isn't very efficient for Int/Word. The following one that I've just adapted from [1] performs at least twice as fast in my tests: {{{#!hs ipowInt :: Int -> Int -> Int ipowInt x y | y < 0 = errorWithoutStackTrace "Negative exponent" | otherwise = go 1 x y where go r b e = let e1 = e .&. 1 r' = r * (b * e1 + (e1 `xor` 1)) -- branchless e' = e `unsafeShiftR` 1 in case e' of 0 -> r' _ -> go r' (b*b) e' }}} This is another pretty compelling argument in favor of performing the change mentioned above. [1] https://stackoverflow.com/questions/101439/the-most-efficient-way-to- implement-an-integer-based-power-function-powint-int -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 28 12:26:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Feb 2019 12:26:38 -0000 Subject: [GHC] #16355: Save CI performance metrics on windows jobs In-Reply-To: <045.1794e27115c4a9992691995dd1b87764@haskell.org> References: <045.1794e27115c4a9992691995dd1b87764@haskell.org> Message-ID: <060.0a3571e2f757a9379c2af22d0f73858d@haskell.org> #16355: Save CI performance metrics on windows jobs -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.3 Integration | Keywords: git notes ci Resolution: | performance test 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 davide): * owner: bgamari => davide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 28 18:01:52 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Feb 2019 18:01:52 -0000 Subject: [GHC] #14109: GHC matches -- as a varsym when lexing a qvarsym In-Reply-To: <044.68208d60fba75e18bd381d8d54ed301c@haskell.org> References: <044.68208d60fba75e18bd381d8d54ed301c@haskell.org> Message-ID: <059.0076ea43c5bba6d1583529d7a570b1ef@haskell.org> #14109: GHC matches -- as a varsym when lexing a qvarsym -------------------------------------+------------------------------------- Reporter: glguy | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * cc: harpocrates (added) Comment: Causes problems in Haddock too, see https://github.com/haskell/haddock/issues/952. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 28 19:28:32 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Feb 2019 19:28:32 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.caee30f0089ff4b4e632383c410b7e4f@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752, #12506, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Changes (by inaki): * cc: inaki (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 28 23:39:34 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 28 Feb 2019 23:39:34 -0000 Subject: [GHC] #16373: Strings from symbolVal not simplified at compile time Message-ID: <045.5599dcbccff04e6f72d9e11ffc41df36@haskell.org> #16373: Strings from symbolVal not simplified at compile time -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (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: -------------------------------------+------------------------------------- Compiling {{{#!hs {-# LANGUAGE DataKinds, TypeApplications #-} module Test where import GHC.TypeLits import Data.Proxy testAA :: Bool testAA = symbolVal @"A" Proxy == symbolVal @"A" Proxy testAB :: Bool testAB = symbolVal @"A" Proxy == symbolVal @"B" Proxy testAB' :: Bool testAB' = symbolVal @"A" Proxy == symbolVal @"B" Proxy }}} with {{{ ghc -O -ddump-simpl -dsuppress-all Test.hs }}} yields: {{{ -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} testAB'2 testAB'2 = "B"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} testAB'1 testAB'1 = unpackCString# testAB'2 -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} testAA2 testAA2 = "A"# -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} testAA1 testAA1 = unpackCString# testAA2 -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} testAB' testAB' = eqString testAA1 testAB'1 -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} testAB testAB = testAB' -- RHS size: {terms: 3, types: 0, coercions: 0, joins: 0/0} testAA testAA = eqString testAA1 testAA1 }}} Furthermore, removing the type signatures for ''either'' testAB or testAB' makes ''both'' simplify to False! I would expect all three definitions to simplify to True or False, independently of the presence of type signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler